1. Overview
This document defines the initial architecture for managing compliance records in SharePoint using a metadata-driven and relationship-based model.
The goal is to:
- Avoid folder-based organization
- Enable cross-library document relationships
- Build a scalable foundation aligned with future SaaS development
This phase focuses on data structure and usability, without automation or Power Apps.
2. Core Design Principles
2.1 Metadata-Driven Architecture
Documents are classified using structured metadata rather than folders.
2.2 Separation of Concerns
- Data Layer → IDs, relationships
- UI Layer → links, navigation
2.3 No Duplication
Documents remain in their original libraries and are referenced, not copied.
2.4 SaaS Alignment
Design uses:
- ID-based relationships
- Cross-entity linking
- Portable structure (future Dataverse/SQL)
3. Library Structure
The system uses multiple specialized libraries:
Compliance Documents
- SWaM Certification
- Licenses and regulatory records
Tax & Legal
- EIN Letter
- Tax filings
- Legal documents
Financial
- Invoices
- Financial records
Corporate Governance
- Organizational documents
All libraries inherit from a base content type:
Corporate Record
4. Metadata Model
4.1 Key Metadata Fields
| Field | Purpose |
|---|---|
| Governance Type | Why the document exists |
| Record Category | Functional classification |
| Record Phase | Lifecycle stage |
| Record Status | Current state |
| Agency | Issuing authority |
| Effective Date | Start date |
| Expiration Date | End date |
| Responsible Owner | Ownership |
4.2 Record Category Standardization
Used across all libraries:
- Identity → EIN, formation docs
- Filing → Tax filings, reports
- Registration → Certifications (e.g., SWaM)
- Reference → Supporting documents
5. Package Relationship Model
5.1 Concept
A Package represents a logical grouping of documents related to a compliance record.
Example:
SWaM Certification Package includes:
- SWaM Certificate (Primary)
- EIN Letter
- Tax Filings
- Supporting documents
5.2 Implementation (Record Package Items List)
A separate list is used to store relationships:
List Name: Record Package Items
Each row represents a relationship.
5.3 Key Columns
| Column | Purpose |
| PackageId | Unique package identifier |
| PrimaryRecordId | ID of main record |
| PrimaryRecordLibrary | Source library of main record |
| RelatedItemId | ID of related document |
| RelatedItemLibrary | Source library of related document |
| RelatedItemUrl | Link to document |
| PackageRole | Primary / Supporting |
| PackageStatus | Draft / Final |
5.4 PackageId Format
TENANT-TYPE-YEAR-SEQExample:
TANOLIS-SWAM-2026-0016. Example: SWaM Compliance Package
Primary Record
- SWaM Certification (Compliance Library)
Supporting Records
- EIN Letter (Tax & Legal)
- Tax Filing 2023
- Tax Filing 2022
- Tax Filing 2021
7. Views for Package Visualization
7.1 By Package View
- Group by: PackageId
- Shows all related records together
7.2 By Primary Record View
- Filter: PrimaryRecordId
- Groups packages per compliance record
8. Navigation (PackageInfo Column)
A hyperlink column is used in Compliance library:
PackageInfo
This links to a filtered view of the package:
/Lists/Record Package Items/AllItems.aspx
?FilterField1=PackageId
&FilterValue1=TANOLIS-SWAM-2026-001
&FilterType1=TextThis allows users to:
- Open a compliance record
- Click PackageInfo
- View all related documents instantly
9. Important Design Decisions
9.1 Separate PackageId and PackageInfo
| Column | Role |
| PackageId | Data / relationship key |
| PackageInfo | UI / navigation |
This ensures:
- Reliable filtering
- Power Apps compatibility
- Future SaaS migration
9.2 Use SharePoint IDs
- No custom ID columns created
- Built-in ID used for relationships
- Combined with library name for uniqueness
10. Current Capabilities
The system now supports:
- Cross-library document grouping
- Metadata-driven classification
- Package-based navigation
- No duplication of files
- Scalable relational model
11. Limitations (Intentional for Phase 1)
- PackageId manually created
- PackageInfo manually maintained
- No automation
- No custom UI
- Filtering relies on SharePoint views
12. Next Phase (Not Implemented Yet)
Future enhancements:
- Power Apps UI (package builder and viewer)
- Automatic PackageId generation
- Auto-linking of PackageInfo
- Validation and governance workflows
- Migration to Dataverse / API layer
13. Summary
This architecture replaces traditional folder-based document management with:
- Metadata-driven classification
- Relationship-based grouping
- Lightweight navigation layer
It provides a strong foundation for evolving into a:
SaaS-based compliance and records management platform
Add to favorites
