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:

1. Standardize folder structure
2. Define metadata
3. Separate project vs document data
4. Organize views
5. Start automation
6. Build dashboards
7. Integrate systems
8. 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.

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.

Designing a Metadata-Driven SharePoint Project Library with Automated Document Set Structure.

1. Why Start with Metadata (Not Folders)

Most SharePoint project libraries fail for one reason:

They start with folders instead of metadata.

Folders solve navigation.
Metadata solves governance.

For a scalable project portfolio library, the structure must be driven by:

• Project ID
• Project Year
• Portfolio Category
• Project Type
• Project Status
• Client
• Risk Level
• Stage Gate

This allows:

• View filtering (Active, Closed, Government, By Year)
• Reporting
• Automation
• Lifecycle management
• Future Power BI integration

Folders alone cannot do that.

---

2. Core Architecture

Site

Tanolis Projects

Library

Projects

Content Type

Document Set (for each project container)

---

3. Core Metadata Design

Create these site columns:

Column	Type
Project ID	Single line of text
Project Year	Choice
Portfolio Category	Choice
Project Type	Choice
Project Status	Choice
Client	Single line
Risk Level	Choice
Stage Gate	Choice
Start Date	Date
Target End Date	Date

Attach these columns to the Document Set content type, not individual files.

This ensures:

• Each project container carries structured metadata
• Views operate on project-level attributes
• Documents inherit metadata if configured

---

4. Why Document Set (Not Just Folder)

A Document Set is:

• A special content type
• A container with metadata
• A logical project object

It behaves like a folder but supports:

• Custom metadata
• Welcome page
• Shared columns
• Governance workflows

A normal folder cannot do that.

---

5. Required SharePoint Configuration

Enable Document Sets

Site Settings → Site Collection Features
Activate Document Sets

Then:

Library Settings → Advanced Settings
✔ Allow management of content types

Add Document Set to the library.

---

6. The Problem: Auto-Creating Subfolders Inside Each New Project

Goal:

When I create:

2026-003_ClientZ_NewApp

Power Automate should automatically create:

01-Contract Governance
02-Planning Design
03-Execution Delivery
04-Financials
05-Admin Closeout

Inside that Document Set.

No duplicate containers.
No root-level folder creation.
No accidental “Shared Documents” folder nesting.

---

7. The Correct Trigger (Important)

Use:

When a file is created (properties only)

Why?

Because:

• A Document Set inside a document library is treated as a file/folder object.
• “When an item is created” is for SharePoint lists.
• Using the wrong trigger causes null content type errors and template failures.

Lock this in.

---

8. The Final Working Flow Design

Step 1 – Trigger

When a file is created (properties only)
Library: Projects

---

Step 2 – Condition

Check:

Content Type
is equal to
Document Set

No expressions.
No startsWith.
No ContentTypeId hacks.

Keep it clean.

---

Step 3 – Initialize Folder Array

Initialize variable:

Type: Array

[
"01-Contract Governance",
"02-Planning Design",
"03-Execution Delivery",
"04-Financials",
"05-Admin Closeout"
]

---

Step 4 – Apply to Each

Loop through the folder array.

Inside the loop:

Create new folder.

---

9. The Critical Folder Path Expression

This is where most implementations fail.

Correct expression:

concat(triggerOutputs()?['body/{Path}'], triggerOutputs()?['body/{FilenameWithExtension}'], '/', item())

Why this works:

From trigger output:

{Path} = Shared Documents/
{FilenameWithExtension} = foo set

Final path becomes:

Shared Documents/foo set/01-Contract Governance

Which means:

Folders are created inside the Document Set container — not in the root.

---

10. Common Mistakes (And Why They Fail)

❌ Using only Filename

concat(triggerOutputs()?['body/{FilenameWithExtension}'],'/',item())

Result:
Creates duplicate root folder or wrong nesting.

---

❌ Using ContentTypeId startsWith

Leads to:

startsWith expects string but got null

Because wrong trigger context.

---

❌ Using “When an item is created”

Causes:

• Null content type
• Condition failures
• Inconsistent behavior

---

11. Handling Race Conditions

Sometimes folder creation hangs because:

The Document Set is not fully provisioned when the flow runs.

Solution:

Add a small Delay (5 seconds minimum on consumption plan).

Or use retry policy.

---

12. Optional Enhancements

You can extend this design to:

• Auto-assign permissions based on Portfolio Category
• Notify PM when project is created
• Trigger approval workflow at Stage Gate change
• Auto-create Teams channel per project
• Sync metadata to Dataverse

---

13. Architectural Pattern Summary

What you built is:

✔ Metadata-first design
✔ Document Set container model
✔ Automated structural provisioning
✔ Governance-ready foundation

This scales to:

• 10 projects
• 100 projects
• 1,000 projects

Without structural drift.

---

14. Final Design Philosophy

Folders are operational.
Metadata is strategic.

Document Sets give you both.

Power Automate enforces consistency.