Tanolis SharePoint Architecture — Compliance & Package Management (Phase 1)

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-SEQ

Example:

TANOLIS-SWAM-2026-001

6. 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=Text

This 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

Designing a Modern Finance Library in SharePoint (2026)

Introduction

As organizations move toward data-driven systems, SharePoint is no longer just a document storage platform—it is increasingly used as a lightweight data platform. A well-designed Finance Library in SharePoint can serve as the foundation for tracking invoices, payments, and financial records in a structured, scalable way.

This article outlines a modern approach to designing a Finance Library schema that aligns with best practices in 2026 and supports future system evolution (e.g., migration to SQL, Dataverse, or SaaS platforms).

The Core Principle: Treat Finance as Data, Not Files

Traditional approaches rely on folders like:

/Project A/Invoices/
/Project A/Receipts/

This model breaks down as data grows.

A modern approach treats:

SharePoint Library = Transaction table
Metadata = Structured columns
Files = Supporting attachments

This shift enables filtering, automation, reporting, and scalability.

Architecture Overview

A clean SharePoint-based financial system should include:

Project Register (SharePoint List)
The master dataset containing all projects (ProjectId as primary key)
Project Financials (Document Library)
A secure library that stores all financial transactions and related documents

Finance Library Schema

1. Project (Lookup) — Required

Type: Lookup to Project Register
Purpose: Links each financial record to a project

2. Document Type — Required

Choice column:

Invoice
Payment Receipt
Expense
Quote
Purchase Order
Adjustment

This defines the type of financial transaction.

3. Invoice ID

Type: Single line of text
Example: INV-2026-001

Used for tracking and reconciliation.

4. Transaction Date — Required

Type: Date

Represents when the financial activity occurred.

5. Amount — Required

Type: Currency

Core financial value for reporting.

6. Lifecycle Status — Required

Choice column:

Draft
Submitted
Approved
Paid
Rejected

This supports workflow tracking and dashboards.

7. Client (Optional)

Type: Lookup or text

Useful for multi-client environments.

8. Category (Optional)

Choice column:

Revenue
Expense

Helps separate inflow vs outflow.

9. Fiscal Year

Type: Choice or calculated

Supports reporting and grouping.

10. Notes / Description

Type: Multiple lines of text

Stores context or additional details.

Recommended Views

Views replace folders and provide dynamic organization.

All Financial Records

Sorted by Transaction Date (descending)

Invoices

Filter: Document Type = Invoice

Unpaid Invoices

Filter:
- Document Type = Invoice
- Status ≠ Paid

By Project

Group by Project

Current Year

Filter: Fiscal Year = current year

Needs Attention

Filter:
- Status = Draft OR Rejected

Security Design

Financial data typically requires restricted access.

Recommended approach:

Assign Finance team access at the library level
Avoid item-level permissions unless absolutely necessary
Keep security boundaries aligned with libraries

This ensures simplicity, performance, and maintainability.

Automation Opportunities

To improve usability and consistency:

Automatically set Fiscal Year based on Transaction Date
Validate Invoice ID format
Default Document Type during upload
Trigger notifications for “Submitted” or “Approved” status

These can be implemented using Power Automate.

Why This Design Works

This schema provides:

Scalability — Handles thousands of records without relying on folders
Consistency — Standardized metadata across all transactions
Automation readiness — Easily integrates with workflows and APIs
Analytics support — Works seamlessly with Power BI and reporting tools

Alignment with Future Systems

This design mirrors a typical financial data model:

SharePoint Concept	Future System Equivalent
Document Library	Transactions Table
Project Lookup	Foreign Key
Document Type	Transaction Type
Amount	Amount Field
Status	Workflow State

This makes future migration to platforms like SQL Server, Dataverse, or a custom SaaS solution significantly easier.

Conclusion

A well-structured Finance Library in SharePoint transforms document storage into a functional financial system. By focusing on metadata, clean schema design, and proper separation of concerns, you can build a solution that is not only effective today but also ready for future growth.

The key takeaway:

Do not organize financial data with folders—design it as a system.

Document Set vs. Corporate Record in SharePoint

When to use each, and why it matters

As I matured my SharePoint architecture for Tanolis, I experimented with two different approaches:

Document Sets (container-based model)
Corporate Record (content type–based model)

Both are powerful.
But they solve different problems.

Understanding the difference is what turns SharePoint from “file storage” into a structured operating system.

1️⃣ Document Set Approach

(Container-Based Model)

What is a Document Set?

A Document Set is like a smart folder.

It allows you to group multiple related documents together under one container and apply shared metadata to the entire group.

Think of it as:

A project folder with intelligence.

When Should You Use Document Sets?

Use Document Sets when you need:

A project container
A client container
A case file
A contract package
A proposal bundle
A structured execution space

In plain English:

Use Document Sets when you are managing work that produces many related documents.

Example

Project: “City of New Orleans – Data Modernization”

Inside the Document Set:

Contract
SOW
Architecture diagrams
Invoices
Meeting notes
Change requests

All grouped under one structured container.

Benefits of Document Sets

✅ 1. Everything stays together

You don’t lose related documents across folders.

✅ 2. Shared metadata

You set metadata once (Client, Project Code, Status) and it applies to everything inside.

✅ 3. Automatic folder provisioning

You can auto-create subfolders like:

01 – Contract
02 – Design
03 – Execution

✅ 4. Great for operational work

Perfect for delivery environments.

What Document Sets Are NOT Good For

They are not ideal for:

Corporate governance
Certifications
Tax filings
Policies
Compliance tracking

Because those are individual records, not grouped work artifacts.

2️⃣ Corporate Record Approach

(Content Type–Based Model)

What is a Corporate Record?

A Corporate Record is a structured document type.

Instead of grouping documents into containers, each document is treated as a governed record with required metadata.

Think of it as:

A database entry that happens to be a document.

When Should You Use Corporate Record Content Types?

Use this model for:

Articles of Organization
Operating Agreement
SWaM Certification
SAM Registration
Insurance Certificates
Tax filings
Policies
Resolutions

In plain English:

Use Corporate Record when the document itself is the official record.

Example

SWaM Certification

Metadata:

Record Status = Active
Expiration Date = Dec 2, 2030
Authority = DSBSD
Responsible Owner = Shahzad

This is a single governed record.

It doesn’t need a folder.
It needs structure and tracking.

Benefits of Corporate Record Model

✅ 1. Clean governance

Every document has required metadata like:

Status
Expiration date
Owner

✅ 2. Easy compliance dashboard

You can filter:

Expiring in 90 days
Active certifications
Archived records

✅ 3. Audit-ready

When SBA, SWaM, or a prime contractor asks for documents:
You can filter and export instantly.

✅ 4. Cleaner architecture

No unnecessary containers.
Just structured records.

Side-by-Side Comparison

Use Case	Document Set	Corporate Record
Project delivery	✅ Yes	❌ No
Client engagement container	✅ Yes	❌ No
Governance documents	❌ No	✅ Yes
Compliance tracking	❌ No	✅ Yes
Tax filings	❌ No	✅ Yes
Proposal bundles	✅ Yes	Sometimes
Expiration monitoring	Not ideal	Excellent

Simple Mental Model

If you are managing work, use a Document Set.
If you are managing official records, use Corporate Record.

Work = container
Record = structured document

Why Separation Matters

Mixing both models inside the same library causes:

Extra columns
Schema confusion
Broken views
Hard-to-maintain governance

Separating them gives you:

A Corporate Core layer
A Projects / Execution layer
A clean architecture

This mirrors real enterprise design.

My Final Architecture Pattern

Corporate Side (Governance Layer)

Uses:
Corporate Record base content type
Derived types:

Governance Record
Policy Document
Compliance Record
Tax Filing
Proposal Record

No Document Sets here.

Projects Side (Execution Layer)

Uses:
Document Set as Project Container

With:

Client
Project Status
Contract Value
Structured subfolders

Why This Matters Long-Term

This separation:

Prepares Tanolis for audits
Makes renewals impossible to miss
Keeps compliance structured
Creates reusable architecture for future clients
Mirrors SaaS-style domain separation

You’re essentially applying:

Clean architecture principles inside SharePoint.

Final Plain English Summary

Use Document Set when you need a smart project folder.

Use Corporate Record when you need a governed, trackable official document.

They are both powerful.

But they solve different problems.

Understanding that difference is what turns SharePoint into a platform instead of storage.

How Metadata-Driven SharePoint Libraries Enable Future SaaS Automation

Most teams use SharePoint as a file storage system. Folders get created, documents get uploaded, and over time structure becomes messy. Search becomes harder, reporting becomes manual, and automation becomes nearly impossible.

The turning point comes when you stop thinking in folders and start thinking in metadata.

A metadata-driven SharePoint library doesn’t just store files — it stores structured information about your business operations. That structure is what enables automation and future SaaS capabilities.

Here’s how.

Folders Organize Storage. Metadata Organizes Meaning.

Folders answer:

Where is the file stored?

Metadata answers:

What is this file, who owns it, and how is it used?

For example, instead of:

Projects
 └── ClientA
      └── Contract.pdf

you get:

Document	Project ID	Client	Type	Status
Contract.pdf	2026-0001	ClientA	Contract	Signed

Now SharePoint understands the document, not just its location.

Why Metadata Matters for Automation

Automation tools don’t understand folder names. They understand data.

Example automations enabled by metadata:

Automatic Document Routing

If:

Document Type = Invoice

Then:

Move to Finance workflow
Trigger billing automation
Notify accounting

No folder scanning required.

Contract Expiration Alerts

If:

Expiration Date = 2026-03-31

Then:

Notify team 30 days earlier
Start renewal workflow automatically

Folders alone cannot do this.

Cross-Project Reporting

With metadata:

Show all Active projects with High risk
Show all invoices pending payment
Show all contracts expiring this quarter

Without metadata, reporting requires manual effort.

Metadata Enables SaaS Product Thinking

This is where SharePoint work starts looking like SaaS architecture.

Your SaaS product later will need:

Projects
Documents
Contracts
Billing
Compliance tracking
Deliverables
Work logs

Each of these is metadata-driven.

In other words:

SharePoint metadata model = future product data model

Your document structure becomes a prototype for your SaaS logic.

Document Sets: Project Containers

Using Document Sets adds structure:

Project
 ├── Contracts
 ├── Finance
 ├── Delivery
 └── Admin

Project metadata lives at the container level, while documents inherit project context but keep their own lifecycle metadata.

This creates a natural separation:

Level	Owns
Project	Client, status, risk, dates
Document	Type, owner, version, expiration

This mirrors SaaS project systems.

Automation Comes Later — Structure Comes First

A common mistake is trying to automate before structure exists.

Correct sequence:

Standardize folder structure
Define metadata
Separate project vs document data
Organize views
Start automation
Build dashboards
Integrate systems
Productize workflows

Automation works only when data is structured.

Long-Term Benefits

A metadata-driven library enables:

Faster search
Clean reporting
Automated workflows
Compliance tracking
Financial oversight
Project dashboards
SaaS-ready data models

And most importantly:

Less manual effort as operations scale.

Final Takeaway

The moment your document system understands business context, not just file paths, automation becomes possible.

Metadata turns SharePoint from file storage into an operational platform.

And once operations are structured, productization becomes achievable.

Building a Scalable SharePoint Project Workspace — Lessons from Today’s Setup

Today I finalized a major restructuring of my SharePoint project workspace, moving from an improvised document layout to a scalable, metadata-driven structure suitable for consulting, subcontracting, and future SaaS delivery work.

The goal was simple: build a project system that will still work five years from now without constant redesign.

Here’s what happened and what I learned.

Starting Point: Folder Chaos vs Structure

Like many teams, documents were growing organically:

Contracts in one place
HR documents somewhere else
Weekly reports in another folder
Financial and timesheet data mixed with operations

This works for small teams, but quickly breaks once projects multiply.

So I standardized the structure.

Standardized Project Folder Model

Each project now follows the same lifecycle structure:

01 — Contract & Governance

Everything that legally establishes and governs the project.

Examples:

Prime contracts
Subcontracts
Amendments
NDAs
Compliance documents

02 — Planning & Design

Pre-execution project preparation.

Examples:

Proposals
Staffing plans
Architecture/design documents
Project plans

03 — Execution & Delivery

Core delivery and operational work.

Examples:

Technical work
Weekly reports
Deliverables
Work logs

04 — Financials

Billing and financial tracking.

Examples:

Invoices
Timesheets
Banking records
Expenses
Tax documentation

05 — Admin & Closeout

Administrative and HR matters.

Examples:

Training certificates
Onboarding docs
Compliance forms
Remote work agreements
Closeout documentation

The Big Lesson: Metadata Beats Folders

The real breakthrough today wasn’t just folder structure.

It was realizing:

Folders organize storage. Metadata organizes understanding.

By using SharePoint metadata:

Project-level data lives on the Document Set
Document-level data stays on each document
Views show combined data cleanly
Documents remain individually searchable
Automation becomes possible later

So now:

Project metadata appears at project level
Document metadata remains editable per document
Views can filter, group, and report without moving files

Folders give structure; metadata gives intelligence.

Key Fix That Unblocked Everything

At one point, Document Set configuration kept failing.

The solution:

Delete and recreate the document library cleanly.
Re-add content types and metadata correctly.
Configure Document Sets before heavy customization.

Sometimes resetting is faster than debugging corruption.

Templates and Proposals Standardization

I also organized:

Templates Library

Contains reusable assets:

Capability statement
Invoice templates
NDA/MSA templates
Proposal templates
Standard project structure guide

Proposals Library

Organized by lifecycle stage:

Active
Submitted
Won
Lost

Metadata will later allow reporting without relying on folders alone.

Why This Matters Long-Term

This structure now supports:

Consulting projects
Government subcontracting
Multi-client work
Future SaaS delivery operations
Automation workflows
Reporting dashboards

Most importantly, it removes daily friction.

Final Takeaway

The biggest realization:

Good document structure isn’t about today’s convenience — it’s about future scalability.

A clean SharePoint structure saves time, reduces confusion, and supports automation later.

And today, the foundation is finally in place.