Platform Modules & Blueprint Packs

Platform Modules

The Architect Panel exposes every subsystem the platform has — around 250 tiles across 25 sections. Platform Modules lets you switch off the ones a given application will never use.

Where to find it

Architect Panel → Configuration:

• Platform Modules — which subsystems are on for this application

The problem it solves

ERP alone is 70 tiles across five sections. On an application that will never touch ERP, eLearning or casework, the panel stops being a way of finding things and becomes something to scroll past.

That is not only irritating. An administrator who cannot find the six screens they need among two hundred they do not is an administrator who will ask you instead of looking — and a panel nobody navigates confidently is one where configuration mistakes happen.

What switching off does

It hides the module's tiles. It is a visibility control for the panel, not a licence or a data operation — turning a module off does not delete anything, and turning it back on returns the tiles with the configuration intact.

That makes it safe to experiment with: if you hide something you later need, switch it back.

Deciding what to switch off

Be honest about what the application is for. A repairs system does not need eLearning. A training platform does not need stock or EDI. A small internal register needs almost none of it.

Start by switching off whole areas you are certain about, rather than trying to trim within an area — the point is fewer sections, not fewer tiles per section.

Do this early

The best time is when an application is first configured, before anybody has learned to navigate around the noise. Doing it later is still worthwhile but you will hear about it from people who had memorised where things were.

Worked example

A council builds a licensing application. ERP, eLearning, Subscriptions, eCommerce and Mobile Apps are all switched off, taking the panel from 25 sections to twelve. The administrators are two licensing officers with no platform background, and the difference between twelve sections and twenty-five is the difference between them configuring it themselves and raising a ticket.

Recommendations

• Switch off at build time, before handover.
• Turn off whole areas, not individual tiles.
• Review after six months — needs change, and re-enabling costs nothing.
• Tell the administrators it is reversible, or somebody will avoid it in case they break something.

Blueprint Packs

A blueprint pack is a large, curated change set that turns a bare tenant into a working configuration — datastores, forms, views, permissions, workflows and the rest — for a recognisable way of working.

Where to find it

Architect Panel → Configuration:

• Blueprint Packs — available packs, and what has been installed

Architect Panel → Data:

• AI Builder — the alternative when nothing fits
• Sample Data — filling the result so it can be judged

What a pack is, and is not

Packs are human-authored and curated, not generated. Somebody who understood the domain decided what the datastores should be, how they relate, what the workflow is and who should see what.

That is the difference between a pack and starting from a description. A pack embodies decisions somebody has already got right; the AI Builder helps you make those decisions yourself.

Compile, lint, install, upgrade

A pack is compiled and linted before it installs, so a pack that would conflict with what is already there is caught rather than half-applied. Packs can also be upgraded, so improvements to a pack can reach a tenant that installed an earlier version.

When to use one

• A new tenant doing something recognisable — a pack gets you to a working system in an afternoon.
• A standard offering you deliver repeatedly, where every customer should start from the same tested base.

Where what you are building is genuinely unusual, a pack is the wrong starting point — you will spend longer removing what does not fit than you would have spent building it.

Install into an empty tenant

Packs are designed to configure a bare tenant. Installing into a tenant that already has a working configuration is where conflicts arise. If you must, install into a fresh tenant first and look at what it creates before deciding.

Adjust after installing

A pack is a starting point, not a finished system. Expect to rename things to your language, add the two fields your organisation needs, and adjust permissions to your structure. Everything a pack creates is ordinary configuration you can edit.

Worked example

A new customer needs complaints handling. A pack installs the case datastore, stages, obligations for the statutory clock, correspondence capture and a reporting dashboard. Two days of adjustment — their terminology, their escalation route, their published response targets — produces a system that would have taken weeks from nothing.

Recommendations

• Install into a fresh tenant and review before committing.
• Generate sample data straight after installing so you can judge it properly.
• Rename to your language early, before people learn the pack's terms.
• Note which pack and version you installed — it matters when upgrading.