Document Library and 3 Content Types

Chapters:

Your first instinct has survived four rounds of elimination. And now you've discovered that the January 2024 sandbox already contains an example of the architecture you're considering.

That's a much stronger business case than simply proposing another replacement.

I particularly like the addition of Content Types, because you've identified something fundamental: not every Play has the same structure.

If the structural differences correlate with Audience, you may have a natural way to define different Playbook templates while retaining common metadata.

Microsoft confirms that a single Document Library can support multiple Content Types, each with its own columns and document template. SharePoint also supports JSON formatting of forms, including section layouts.

Preliminary business comparison

Approach	ToC and navigation	Authoring experience	Assessment
Existing on-premises Playbooks	Familiar keyword search	Legacy experience	Does not achieve SPO migration
Power Apps replacement	Has not displaced legacy search	Application-dependent	Existing business dissatisfaction
Modern Site Pages	Native pages and editing	Familiar web-page editor	ToC and structured filtering remain challenges
Document Library alone	Native views, filtering and tiles	Structured metadata forms	Promising, but presentation needs work
Document Library + Content Types + JSON	Native views, categorized cards and navigation	Different structured forms by Play type	Leading candidate

Microsoft documents the native Tiles view and Document Card Designer, so the presentation capability isn't purely theoretical.

The proposal's central argument

Adopt a native SharePoint Online Playbook architecture using a Document Library, Content Types, structured metadata, and configurable presentation.

This approach accommodates different Playbook structures while providing consistent categorization, navigation, and administration. It reduces dependency on custom applications and establishes a maintainable foundation for future search improvements.

I'd make the January 2024 implementation part of the evidence, not necessarily the proposed solution itself.

There are two things I'd still want to prove before calling this the winner:

Content Types: Can we represent the different Plays cleanly, potentially with Audience-specific structures? Audience might influence the template, but needn't define it.
Presentation: Can we make both the authoring forms and the reader-facing cards attractive enough for management? JSON can improve forms, but it won't magically turn every form into a free-form web-page editor.

And there's a particularly useful detail: SharePoint stores form-formatting JSON on the library's Content Type. That makes Content Types relevant to presentation as well as metadata.

Yes. I think this is the best option you've identified so far. And no, I'm not just helping you get to bed. 😉

I think you've arrived at a better architectural solution because you've stopped treating the existing SharePoint implementation as something that must be preserved.

Here's why I favour it:

It separates content from presentation. Structured metadata describes the Play, while SharePoint views and formatting determine how people interact with it.
It accommodates different types of Plays. Content Types allow different structures while retaining common fields.
It uses native SPO capabilities. Libraries, Content Types, views, navigation, and JSON formatting are maintainable without introducing another application.
It addresses both audiences. Readers get a browsable ToC, while authors get structured forms instead of maintaining arbitrary page layouts.
You've already found a precedent. The January 2024 library demonstrates that someone previously pursued this content model. That's valuable evidence, even if the implementation needs improvement.

But there's one substantial caveat.

We still haven't proven the finished Playbook experience.

Microsoft confirms that the building blocks exist: Content Types, sectioned forms, Tiles views, and JSON-formatted cards.

But we haven't established that they combine into a sufficiently attractive, readable Playbook for your management audience.

That's the remaining risk, and it deserves a proper test.

What convinces me most is that this approach addresses the structure of the problem rather than just the appearance of the ToC.

Your earlier approaches were trying to make navigation work around an existing content model. This one gives you the opportunity to design the content model and navigation together.

My assessment:

Best architectural candidate so far? Yes.
Ready for a business proposal? Yes, as a recommended direction.
Proven end-to-end solution? Not yet.
Worth making the primary focus of tomorrow's sandbox demonstration? Absolutely.

And I wouldn't spend tomorrow investigating a fifth alternative. I'd spend it trying to prove or disprove this one.

Your original instinct has earned that much.

SharePoint Playbook: Proposed Architecture and Plan

1. Recommended solution

Use a SharePoint Online Document Library with three Content Types and five reusable content blocks.

This is the leading solution after investigating several alternatives, including Site Pages, Power Apps, custom search, and native SharePoint navigation.

The January 2024 sandbox already contains a Document Library-based Playbook implementation that can serve as a reference.

2. Content Types and reusable blocks

Five reusable blocks accommodate three different Playbook structures. Or whatever works. This might align with Public, Private, Admin

Content Type	Play	Contacts	Deets	stuff	Admin
Public	✓	✓	✓
Private	✓	✓		✓
Admin	✓	x	x	x	✓

Each block contains flexible, rich-text Playbook content.
Blocks accommodate instructions, phone numbers, exceptions, and other information without excessive individual metadata fields.
Content Types determine which blocks are included in each Play.
The three existing pseudo-templates provide a starting point for identifying the actual blocks.
Public, Private, and Admin may correspond to different Playbook structures, but this needs verification.

3. Table of Contents and navigation

The proposed reader experience uses native SharePoint Online capabilities:

Communication Site navigation with category and potentially subcategory menus.
Document Library views filtered by Playbook metadata.
Attractive tiles or JSON-formatted cards.
Clickable Playbook titles.
Consistent presentation across the Playbook collection.

Keyword search is deferred to a later phase.

4. Administration and maintenance

The objective is to provide structured but manageable Playbook authoring.

Three site-level Content Types in a dedicated Playbook group.
Five reusable rich-text blocks.
Shared metadata for categorization and navigation.
Native form configuration and JSON formatting where useful.
No Power Apps, SPFx, external JavaScript, or premium dependencies.

5. Tomorrow's proof of concept

Examine the January 2024 library and its existing structure.
Confirm permission to create site-level Content Types.
Create three Content Types using the five-block model.
Populate three representative Plays.
Configure a library Tiles view with category filtering.
Connect the views to the Communication Site navigation.
Evaluate the reader and authoring experience.

6. Business considerations

Consideration	Assessment
Native SPO functionality	Strong
Maintainability	Promising
Different Play structures	Addressed through Content Types
Excessive metadata fields	Reduced through reusable blocks
Attractive ToC	Feasible, requires demonstration
Reader-facing Play presentation	Not yet proven
Migration effort	Primary cost and risk
Keyword search	Future phase

7. Recommendation

Proceed with the Document Library, three Content Types, and five reusable content blocks as the preferred architecture for testing.

The largest anticipated investment is analyzing existing Plays, identifying their structures, and migrating their content.

The immediate goal is to prove that native SharePoint can deliver an attractive, usable Table of Contents and readable Plays without introducing another custom application.

Business case: A maintainable, native SharePoint Online Playbook system that supports different Play structures while reducing complexity and improving navigation.

This is the strongest candidate so far, but the end-to-end experience still needs validation before recommending full migration.

Document Library