Platform Modules & Blueprint Packs

Platform Modules

Platform Modules switches whole areas of the platform off for an installation, so the Architect Panel shows the sections an application actually uses. Use it when an application will never touch ERP, eLearning, casework or commerce and their tiles are only getting in the way.

Where to find it

Architect Panel → Configuration:

• Platform Modules — turn whole areas of the platform on or off for this installation

What switching a module off does

• Its tiles leave the Architect Panel. Any section left with no tiles disappears with them.
• Its own consoles refuse to open. Reached any other way (a bookmark, an Admin Panel item), the screen shows an amber notice: "Module is switched off on this installation. Turn it back on under Platform Modules."

It does not delete anything, stop a scheduled task, close the API, hide a pane on a record screen or change what the AI Builder proposes. Records and configuration are untouched, and switching the module back on returns everything as it was.

Two modules are different. Business Intelligence and Mobile Apps reuse the subsystem's own master switch, so turning them off stops the feature itself (the BI engine; device enrolment and the device API), not just the tiles. Their cards carry a blue note saying so.

The modules

• Enterprise Resource Planning: companies and setup, ledger, procurement, stock and production, assets, projects and time, pricing, EDI and accounting feeds.
• CRM & Service: journeys, campaigns, pipelines, calls, satisfaction and the knowledge base.
• Casework & Records: classification, retention and disposal, assessment instruments, submissions and public meetings.
• Documents & Signatures: the document store, compilations, redaction, generated templates and e-signature.
• eLearning: courses, packages, enrolment, assignment and learner records.
• Messaging: SMS, WhatsApp, GOV.UK Notify, letters and inbound messages. E-mail is core and is not affected.
• Business Intelligence: Explore, BI dashboards and the Report Builder.
• Commerce: cart, products, vendors, wishlists, subscription packages and payment collection.
• Mobile Apps: the mobile canvas, app builds and enrolled devices.
• AI: the AI gateway, its run log and usage console, the AI Builder and TypeSafe Jev decisions.
• External Data Sources: external-system drivers, sync history and the writeback queue.

An installation running a vertical product may show further cards for that product's own modules. A screen shared by two modules (the worklist belongs to both CRM and casework) stays available while either of them is on.

Reading a card

Each card shows the module's name and description, how many Architect Panel items it owns on this installation, how many admin screens it gates, and the name of the setting behind the toggle. A card reading "Not installed on this instance" means that module's tables were never created here, so there is nothing to hide. The line under the cards counts the items that belong to no module: pages, forms, security, data and the other core screens are always shown.

Switching a module off or on

1. Open Platform Modules.
2. Click the toggle on the module's card. The status under it reads "Saving...", then "Off - reload the panel to see it" (or "On - ...").
3. Reload the Architect Panel. The module's tiles and any emptied sections are gone (or back).

The switch is stored as a site option, so it also appears in the Platform Modules group on the Site Options screen; the two always agree. The Platform Modules tile itself is never hidden, whatever you switch off, so every change can be undone from the same screen.

Who it affects

The switches are per installation, not per tenant. On a multi-tenant installation, switching ERP off hides it for every tenant's architects. When a single-tenant application is created through the sign-up wizard, the wizard switches off the modules its chosen template does not need (AI always stays on); on a multi-tenant installation it changes nothing.

What goes wrong

• "Could not save" under a toggle: the write failed and the toggle has been put back to its real state. Try again; if it persists, the hosting administrator should check that the setting exists in the site configuration file.
• A tile you expected to vanish is still there: it belongs to no module (it is core), or the screen is shared with a module that is still on.
• Somebody hits the amber notice: the module they need is off. Switch it back on; nothing was lost.

Worked example

A council builds a licensing application on a dedicated installation. In Platform Modules the architect switches off Enterprise Resource Planning, eLearning, Commerce, Mobile Apps and External Data Sources, and reloads the panel: every ERP section disappears and the panel is down to the sections the licensing team uses. Six months later the council wants to take licence fees online. The architect switches Commerce back on and the cart and payment tiles return with nothing to reconfigure.

Recommendations

• Switch off at build time, before handover, so administrators learn the short panel.
• Think twice about BI and Mobile Apps: those two switches stop the feature, not just the tiles.
• Remember it is installation-wide on a multi-tenant system.
• Tell administrators it is reversible, so nobody avoids it for fear of losing data.

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.