14 of 187 pages

Organisation Hub

Organisation Portal

14 pages · scroll straight through

Organisation Portal Overview

The Organisation Portal is the central administration layer above individual workspaces. It gives Organisation Admins a unified view of all workspaces, organisation-wide settings, billing, security policy, and cross-workspace reporting.

Organisation Admin required. Access to the Organisation Portal requires the Organisation Admin role. Standard workspace members and workspace owners cannot access portal administration pages.

What the Organisation Portal covers

Section	Purpose
Hub	Organisation overview, workspace listing, and quick actions
Structure	Departments, divisions, and workspace grouping hierarchy
Billing & Account	Subscription management, invoice history, seat allocation
Security	SSO (SAML/OIDC), SCIM 2.0, MFA, session limits, step-up auth, IP allowlisting, audit retention
Audit Log	Organisation-wide security events with CSV, JSON, and SIEM export
Branding	Organisation logo and colour scheme applied across all workspaces
Workspace Templates	Pre-configured workspace setups that new workspaces inherit
Reports	Cross-workspace aggregate reporting and delivery health
Support	Raise and track support requests at organisation level
Notifications	Organisation-wide notification settings and distribution lists

Accessing the Organisation Portal

Select Organisation from the workspace switcher in the top-left. If your account has the Organisation Admin role, you will land on the Organisation Hub. Contact your organisation's super-admin if you need access.

Organisation Hub

The Hub is the landing page for Organisation Admins — an at-a-glance view of workspace health, seat usage, recent admin activity, and quick links to frequently used admin tasks.

Hub sections

Organisation Summary — Name, plan tier, contract renewal date, and total seat allocation at a glance.

Workspace Overview — All workspaces in the organisation, with last active date, member count, and delivery health indicator. Click any workspace to navigate directly to it (as an admin).

Seat Usage — Allocated vs. used seats across the organisation. Highlights workspaces approaching seat limits.

Recent Admin Activity — Log of recent organisation-level admin actions (member changes, security setting updates, template changes).

Quick Actions — One-click access to: Invite Member, Create Workspace, Update Billing, Review Security Alerts.

Workspace health indicators

Each workspace card on the Hub shows a health indicator (Green / Amber / Red) based on: last activity date, completion rate, security policy compliance, and AI governance status (for Enterprise workspaces). Click a workspace card to see the detail breakdown.

Organisation Structure

Define your organisation's hierarchy of departments, divisions, and product areas — and map workspaces to them. Enables structure-aware reporting and policy inheritance.

Building your structure

Click Add Division to create top-level organisational units (e.g. Technology, Operations, Finance). Within each division, add departments. Departments are the lowest structural level — workspaces are assigned to departments.

Assigning workspaces

Drag workspaces onto department cards, or click a workspace's overflow menu and choose Assign to Department. A workspace can belong to only one department. Unassigned workspaces appear in the "Unassigned" bucket.

Why structure matters

Reporting: Organisation Reports can aggregate data by department, division, or the full organisation.
Policy inheritance: Security policies and workspace templates can be scoped to a division or department and inherited by all workspaces within it.
Billing: Cost allocation reports can split usage by department for internal chargeback.

Department owners

Assign a Department Owner to each department. Department owners receive delivery health notifications for their workspaces and can see aggregate reports for their department without full Organisation Admin access.

Billing & Account

Where your Organisation's plan is bought and managed: the subscription, the seats and who is using them, the invoices, and the billing details those invoices use.

Every paid plan is the Organisation's. One subscription, priced per person, covers every workspace and studio in the Organisation. Card details are entered on Stripe's own pages and never reach us.

Subscribing

A new Organisation is awaiting its subscription: until a plan is paid for, this is the only page that answers. Choose Business or Enterprise, monthly or a year in advance, and the number of seats, then pay by card. The Organisation opens as soon as the payment is confirmed, and its other pages open with it. There is no trial on either plan: the Free plan, which needs no Organisation, is how you try the product. The Pricing page has the current prices.

Seats and people

Seats — the number of people your subscription pays for. Add seats at any time; you are charged only for the rest of the current period.

People — the distinct people across every workspace and studio in the Organisation. Somebody in two workspaces and a studio counts once.

Every seat taken — the next person cannot join, be invited in, or be provisioned by SCIM or single sign-on until you add a seat. Nobody already in is affected.

Over the Free limits — the page lists each workspace with more than 20 people and each studio with more than one, because those are what a move to Free would hold read-only.

Price changes

If a published price is going to rise, the Organisation's owner is emailed at least 30 days before. The new price applies from your next billing period after that date, never part-way through a period you have paid for, and the page shows the change beside the plan it concerns.

Cancelling, and coming back

Cancel from this page at any time. The subscription runs to the end of the period you have paid for; you can restart the renewal before then. When it ends the Organisation is archived: nothing is deleted, its workspaces and studios return to the Free limits, and anything over a limit is read-only until it is brought within it. Subscribing again reinstates the same Organisation as it was.

While an Organisation is archived nothing can be added to it, but anything it holds can be taken away. This page lists the stored credentials, SCIM, and the linked workspaces and studios, with a removal for each. Administrators and invitations are removed on User Management, and the Audit Log can still be read and exported.

Negotiated contracts

A larger estate can agree its own rate with us on Enterprise, with a minimum term, billed by invoice. The contract panel is then read-only, because the seats, the rate and the term are the agreement reached with our team and are applied on our side.

Rate and contract value — the agreed amount per person and the resulting total per period, before VAT. An agreed rate is not affected by a change to the published prices.

Minimum term — the contract cannot be cancelled before it ends.

Payment terms — how many days an invoice has before it falls due, shown as "Net 30" and similar.

Renewal date — when the next period begins.

Purchase order number

Set your PO under Invoice details. It is printed on every invoice raised for the subscription, and saving a new one applies it to future invoices immediately. Most finance teams will not settle an invoice that does not quote a valid PO, so keep it current when a new PO is issued.

Invoices

Every invoice raised for the subscription is listed with its issue date, due date, PO reference, status and total. Invoices carry our company name, registered address and VAT registration number alongside your organisation's billing details and VAT number.

Billing details

Invoice email — the finance mailbox invoices are sent to. This is deliberately separate from the person who set up the organisation.

Invoice address — the postal address printed on the invoice.

VAT number — your tax registration. For an EU organisation this determines whether the invoice is issued under the reverse charge.

Editing these changes future invoices only. Invoices already issued keep the details they were raised with, because an issued invoice is a financial record. If someone else changes the details while you are editing them, your save is refused and the form shows what is stored, so nothing is overwritten unseen.

Want a negotiated contract? The page offers to open an account thread so you can discuss seats, term and payment terms with our team.

Organisation Security

Configure enterprise identity and access for all member workspaces: SAML/OIDC SSO, SCIM 2.0 provisioning, TOTP MFA, session limits, step-up authentication, and audit retention.

Organisation Admin only. Policies set here apply to every workspace in the organisation and cannot be weakened by workspace admins. IdP credentials are stored in Amazon Cognito — never in the browser.

Single Sign-On (SSO)

Enable Enforce SSO and choose SAML 2.0 or OpenID Connect. Enter your IdP metadata URL (SAML) or issuer URL + client ID (OIDC). Users sign in from the login page with their organisation ID and the Sign in with SSO button.

Optional Auto-Provision adds federated users as Developer members on all org-linked workspaces on first login.

Only the organisation’s owner can configure the provider: it decides who can sign in as this organisation’s members, including administrators.

Public documentation: Enterprise Identity & Access · Security architecture

SCIM 2.0 provisioning

Click Enable SCIM to generate a bearer token (shown once). Configure your IdP provisioner with:

Base URL: /scim/v2
Authentication: Bearer token
Groups: Developer, Admin, Stakeholder, OrgAdmin (maps to workspace personas and org admin)

Rotate the token periodically. De-provisioning disables the Cognito account and removes memberships.

The OrgAdmin group makes organisation administrators only while the token in use was issued by the organisation’s owner. Administrators can release studios, so who becomes one is the owner’s decision: a token another administrator issued keeps users and personas in step but makes no administrator, and the refused attempt is on the security trail. The SCIM card says which kind of token is in use.

Administrators and their authority over studios

An organisation administrator can write and activate guardrail policies, read the exceptions register, place a legal hold on a studio’s work, and release a studio from the organisation. Because of that, who becomes an administrator — and what can make one — is the organisation owner’s decision by every route.

Action	Who
Add an administrator, or send an invitation to become one	The owner only. An invitation is accepted only if the organisation’s current owner sent it, and only by the account it was sent to
Remove an administrator	The owner, or the administrator themselves
Configure the single sign-on provider	The owner only
Issue, rotate or disable the SCIM token	The owner only. Any administrator can see whether SCIM is on

Your identity provider manages the administrators it made. Taking someone out of the OrgAdmin group, or pushing a group that leaves them out, removes the administrator role only from a person SCIM itself made an administrator. Someone the owner appointed, or who accepted the owner’s invitation, stays until the owner or that person removes them.

De-provisioning or deactivating a user removes their administrator role whoever appointed them — except the organisation’s owner. Reactivating the user does not give it back, and a deactivated user is never made an administrator.

If the owner appoints someone SCIM made an administrator, that person becomes the owner’s appointment: a later group change no longer removes them.

Workspace Admin through the group is set only for administrators SCIM made. The owner’s appointments keep whatever workspace roles they have.

A token another administrator issued before this rule keeps working: it cannot make an administrator, but de-provisioning through it still removes one. The SCIM card says whether the token in use is the owner’s, with Rotate beside it for the owner.

A one-person organisation is unaffected: its owner is its only administrator. Who may do what across guardrails, exceptions and passports is set out in Who May Do What.

Multi-Factor Authentication

Enable Require MFA to mandate authenticator-app TOTP for all members. Users enrol at Account → MFA (/account/mfa). The API returns MFA_REQUIRED when policy is active but the session lacks an MFA claim.

Step-up authentication & session limits

Step-up window (minutes) — Destructive actions (delete workspace, RBAC matrix changes, org admin removal) require a recent sign-in within this window. Users confirm it is them in a dialog over the page they are on, with their password and then their authenticator code when they have one.

Maximum session length (hours) — Users must sign in again after this period (enforced via Cognito auth_time).

Audit log retention (days) — Default 365. Organisation and workspace audit rows expire via DynamoDB TTL after this period.

IP allowlisting

Add CIDR ranges when Enforce IP allowlist is enabled. Workspace and organisation API routes evaluate the client source IP on every request; violations return 403 IP_RESTRICTED.

Workspace override permissions

Control whether workspace admins may add supplementary IP rules, configure local SSO, or downgrade MFA below the organisation baseline. Keep MFA downgrade disabled unless security governance explicitly approves it.

Platform abuse protection (MDTS-operated)

Independent of organisation policy, the platform enforces:

Per-IP rate limits on sign-in, registration, password reset, and workspace join
256 KB request body cap on mutating API routes
JSON Schema validation on authentication request bodies
Maximum 10 workspaces per user account (creation cap)
API Gateway stage throttling for platform-wide back-pressure

Managed AWS WAF on CloudFront is planned when a contract or abuse metrics justify its standing cost (a monthly fee per Web ACL and per managed rule group, charged even with no traffic). See Security architecture and System status.

Organisation Audit Log

Search, filter, and export security events across your organisation — login activity, SSO, SCIM provisioning, policy changes, and SIEM exports.

What is recorded

Events are written to an append-only audit table (separate from workspace delivery audit). Typical entity types include security, orgSecurity, and orgSso. Examples:

Login success and failure, SSO login, logout
MFA challenge and enrolment
SCIM user provision and de-provision
Organisation security policy changes
SIEM export actions

Exporting

Export CSV / JSON — Download filtered results (up to 10,000 rows) for spreadsheets or archival.

Export for SIEM — Writes a JSON bundle to encrypted storage and opens a presigned download URL valid for 24 hours. Use for Splunk, Microsoft Sentinel, or similar tooling.

Retention

Retention follows the Audit log retention (days) setting on Organisation Security (default 365). Workspace-level overrides may apply to workspace-scoped audit only.

Procurement and trust materials: Enterprise trust centre · Vendor pack

Guardrail Policies

A guardrail policy is the floor your organisation puts under every linked AI Product Studio: the Definition of Ready and Done items each work package must carry, the rules a release must meet, and whether two different people must decide. Studios can tighten it; they cannot loosen it.

Enterprise. Creating, editing and activating a policy needs an Enterprise contract. Everything else keeps working without one — reading policies, retiring one, the exceptions register, and the policy already applied to your studios’ work packages — so a lapsed contract never strands work in flight.

Draft, activate, version

Open Organisation → Guardrail Policies. A policy is a draft you can edit. Activate freezes it as the next numbered version, and from then on every new work package in every linked studio is created under that version. One policy is active at a time.

A version never changes. Editing an active policy edits its draft; activating again makes the next version.

Work packages keep the version they were created under. A new version does not rewrite existing packages. A studio’s owner can move one package onto the current version from its Passport, before it is dispatched; doing so invalidates its gate evidence.

Retiring removes the floor for new work packages and is the organisation owner’s. A retired policy cannot be activated again; its versions stay, because passports cite them.

Editing, activating and retiring ask you to sign in again, and every change is in the organisation audit log, item by item.

Write your first policy, step by step

Create your reviewer roles first. Under Organisation reviewer roles on the Guardrail Policies page, add the roles your items will name — for example Security lead and Peer reviewer. An item’s human side names one of these, or any human in the loop.
Start a draft and add a few items. Five to ten is a sensible first policy. For each: whether it belongs to the Definition of Ready or the Definition of Done, its agent reviewer, its human reviewer role, and the controls it is evidence for.
Decide how much a studio may add.Tighten allowed lets a studio add a reviewer or a control to the item; Locked lets it add nothing. No studio can remove or weaken an item either way.
Set the release rules you need, and leave the rest off.
Set the exception rules: whether exceptions are allowed, the most days an item may stay under exception in all, and which roles may grant one.
Leave separation of duties and four-eyes on change off unless you have the people for them. Both can be turned on later.
Activate. You are asked to sign in again. The draft is frozen as version 1.
Check Coverage. Each linked studio must say which of its own roles answers for each of yours, on its Human Roles page. Until it does, that role is held by nobody there and its items cannot be approved. Coverage shows which studios have not.

Nothing changes for work already under way. Work packages that exist keep the rules they were created under. Only work packages created after activation carry the new version.

How the items then behave in a studio — the gates, the evidence and the passport — is in the Studio guide, starting at Start Here: Guardrails to Passport.

Items

Each item is a Definition of Ready or Definition of Done check, always required, with an agent reviewer, a human reviewer, or both, and the controls it is evidence for. In a linked studio the organisation’s items appear first on every new work package, marked with a lock and the version they come from.

Tighten allowed — a studio may add a reviewer or a control to the item on a work package.

Locked — a studio may add nothing to it.

Never — a studio cannot remove an organisation item, reword it, make it optional, or take a reviewer or a control off it.

Organisation reviewer roles

An item’s human side names one of your organisation’s reviewer roles, or any human in the loop. Each studio maps your roles to its own on its Human Roles page. A role a studio has not mapped is held by nobody there, so its items cannot be approved until the studio maps it.

Must be a named role. A studio may answer one of your roles with “any human in the loop”, which lets every member there approve. Switch this on for a role to forbid that. It is off by default, it is the organisation owner’s to change, and it applies at once — a studio already answering the role that way cannot approve that role’s items or releases until it names a role.

Release rules

Require CI success — every work package’s pull request head must have passing CI, read from GitHub at approval and again at release. A failure, an unfinished check, no checks at all or a result that cannot be read all refuse.

Required reviewer roles — organisation roles the release approver must hold.

DPIA for AI-built releases — always required by the platform; a policy cannot relax it.

Separation of duties

By default a policy leaves this to each studio. It can instead require that two different people decide the two sides of a gate, or the two sides of each item as well. A policy can require separation; it can never switch off a studio’s own.

Four-eyes on changes to the policy itself is a separate option, off by default: with it on, a person who edited the policy since it was last activated cannot be the one to activate it. A lone owner who turns it on can only leave it by retiring the policy — the page says so next to the option.

Exceptions

A policy says whether a studio may take an exception to one of its items, how long an item may stay under exception, and which of your roles may grant one. An exception to an organisation item always has an expiry, and once it runs out the item is unmet again. Every exception appears in the Exceptions Register.

The limit is in all, from the first exception. The number of days is the item’s total time under exception on a work package, counted from the first exception to it. A renewal does not start it afresh, and nor does an exception granted again after the package changed. When it is used up the item must be met.

Named roles bind everyone in the studio, its owner included. With roles named, only someone who holds one may grant, renew or waive — or override the reviewer agents on a gate holding one of your items. A studio owner who holds none cannot. A role nobody holds refuses; it never falls back to the owner.

Two things to know. Each studio’s owner decides who holds a role in their studio, so an owner can hold the role themselves — the register says so when they grant. And activating a new version of the policy starts a new count for work packages moved onto it; the register marks an exception whose time limit was restarted that way.

Coverage

The Coverage table shows which linked studios apply which version, which of your roles each has not mapped, which it answers with any human in the loop, and any studio whose link is no longer sound. Who holds your roles here shows, for each studio, the studio role each of your roles is mapped to, how many people hold it, and whether the studio’s owner is one of them. You do not choose those people — each studio maps its own — but you can see who it chose.

Studios and the organisation link

A studio cannot unlink itself. Once a studio belongs to an organisation, nobody in the studio can remove or change that — whatever their role, and whether or not a policy is active.

Releasing a studio is done from the organisation, by its owner or any of its administrators, from the Coverage table, with a fresh sign-in and a written reason kept in the audit log of both the studio and the organisation. An administrator cannot release a studio they own themselves — another administrator, or the organisation’s owner, does. The studio leaves the organisation and its structure; new work packages there get no organisation items; work packages already created keep the version they were born under.

A studio whose owner has left the organisation is not sent the policy, and its new work packages are on hold rather than created without your items. Add the owner back, or release the studio.

Only the owner makes an administrator. Because any administrator can release a studio, only the organisation’s owner adds one, sends an invitation (and an invitation is accepted only if the current owner sent it), or issues the SCIM token whose OrgAdmin group may grant the role. Removing another administrator is the owner’s too; an administrator can remove themselves. Every way of becoming one is in the organisation audit log.

Studios with no organisation

Nothing here applies to them. A studio that belongs to no organisation keeps its own checklists, its evidence ledger, its passports and its exceptions, and nothing in it needs two people.

Exceptions Register

The Exceptions Register shows, in one place, where your organisation’s controls were set aside: every waived checklist item and every override of the reviewer agents on a gate in your studios, with who granted it, under which authority, why, and when it runs out.

What it lists

Open Organisation → Exceptions Register. Each row is one exception on one work package’s gate, in one of three states:

In force — the item counts as waived.

Expired — its time ran out. The item is unmet, and the work package cannot take its next step or be released until the exception is renewed in its studio or the item is met.

Voided — a material change to the work package, a new decision on the item or a renewal cut it short.

An exception that expired and was since renewed or decided is history, not a problem; the register counts those separately, so the Expired count is what still needs someone.

What each row tells you

Organisation item — the item came from your guardrail policy, so the policy’s exception rules applied.

Expiry — an exception to one of your own items always expires, within the days the policy allows — counted in all, from the first exception to that item on the work package. The register shows when that time started. A studio’s own item may have no expiry.

Time limit restarted — shown when an item was under exception under an earlier version of the policy and the count began again under a newer one. It is a prompt to look, not a finding: where the register could not match the item itself, the label may sit on a different item of the same gate.

Granted by — the person, and how they were entitled: a studio owner or reviewer, or — where the policy names approver roles — a member of one of them, and only a member. Where the studio’s own owner holds the role the register says so, because the owner also decides who holds roles in their studio. Also approved the other side means one person granted the exception and approved the item’s other side.

It lists studios’ own items too. The register shows exceptions on a studio’s own checklist items as well as on yours, with the name of the person who granted each and their justification. Studios are told this in their own documentation.

Reading a large organisation

The register is read from each studio’s gates a part at a time, so it cannot drift from them. The page keeps reading until it has every studio and says how far it has got; Read the rest of the register carries on when it stops.

A studio that has left the organisation, or whose owner is not a member of it, is listed but not read: its gates are not the organisation’s to see.

Acting on it

The register is read-only. An exception is renewed, or its item met, in the studio that owns the work package. Whether exceptions are allowed at all, how long an item may stay under exception in all, and who may grant one are set on the guardrail policy. Reading the register needs no Enterprise contract.

Sampling and Holds

Three things an organisation needs once its studios deliver with agents: a second look at a share of completed work, a way to hold records for a legal matter, and a stated retention period for evidence.

Sample reviews

On Organisation → Guardrails, a policy can name a share of completed work packages and an organisation reviewer role. When a work package born under that policy version completes, the server decides whether it is one of the sampled ones. A member of the named role — as the package’s studio maps it to one of its own named reviewer roles — then records what they found: Confirmed, or a Concern with a note.

A sample review never blocks. A pending sample or a concern does not stop a work package being released or deployed. It is shown on Organisation → Sampling and Holds, on the package’s passport and on its release, so that someone follows it up.

How the server chooses — once, when the package completes, from values the server itself made and keeps with the package. A studio cannot predict the choice, choose it, or have it made again; and anyone who can read the package can recompute it. The page says how many packages were selected out of how many the policy looked at.

Who gives the verdict — only a member of the named role. Being the studio’s owner or a reviewer is not enough. A studio of one can map itself into the role and finish its own samples; the verdict then says the reviewer also completed the package.

Nobody can decide — if a studio has not mapped the role to a named role with members, or answers it with any human in the loop, nobody there can record a verdict and the sample stays pending. The list says so.

A concern — can later be confirmed as resolved, with a note saying how. The concern stays on the record.

Legal holds

A legal hold on a work package or a release stops its records being deleted: the artefact itself, its studio, the pages of a held work package, the DPIA a held release names, the intent a held work package belongs to and the repository connection its commits came from. Each of those is refused while the hold is in force, naming the hold. It stops nothing else — work, approval, release and deployment go on as usual.

Who places one — a studio’s owner, from the work package or the release; or the organisation’s owner or an administrator, from Sampling and Holds, by naming the studio and the artefact’s reference (for example WP-12 or REL-3). A written reason is required. The artefact’s evidence ledger and its passport record that a hold was placed, when and by whom, and never the reason.

Who sees the reason — a reason the organisation wrote is shown to the organisation’s administrators only: the studio’s owner and members see that the hold is in force, who placed it and when, and it is kept off the studio’s audit log. A reason a studio’s owner wrote is shown to that owner, to whoever may read the studio’s audit log, and to the organisation’s administrators.

What a hold does not do — it does not lengthen the audit log’s own retention: audit entries about the held artefact still expire when your audit retention runs out. If a matter will outlast that, export the audit log.

Who lifts one — a hold the organisation placed is lifted by the organisation, never by the studio. A hold a studio’s owner placed can be lifted by that owner or by the organisation.

Releasing a studio — a studio cannot be released from the organisation while the organisation holds one of its artefacts. Lift the organisation’s holds first.

Evidence retention

The organisation’s owner can declare the minimum number of days the organisation keeps evidence for. It can never be shorter than the organisation’s audit retention. Declaring a period, or lengthening one, needs the Enterprise contract; shortening or withdrawing one does not.

It is a declaration, not a deletion schedule. Nothing deletes evidence today. The evidence ledger and issued passports are kept for as long as the service holds them, whatever is declared, and also after a studio is deleted. The declaration is recorded, audited and shown to your studios.

Reading a large organisation

The lists are read from each studio a part at a time, so they cannot drift from the records. A studio that has left the organisation, or whose owner is not a member of it, is listed but not read. Reading this page, and placing or lifting a hold, need no Enterprise contract.

Organisation Branding

Set organisation-level branding that cascades to all workspaces — logo, primary colour, and appearance theme — ensuring consistent brand presentation across your entire organisation.

Logo

Upload your organisation logo (PNG or SVG, recommended 200×60px). The logo appears in the sidebar header of all workspaces. Individual workspaces can optionally display their own workspace name beneath the organisation logo.

Colour scheme

Set a primary colour that is applied to buttons, active navigation items, and links across all workspaces. This overrides any workspace-level colour selection. Use the colour picker or enter a hex value.

Theme preset

Choose an appearance preset (Professional, Minimalistic, Ocean, etc.) to apply as the default theme for all workspaces. Workspace administrators can still allow members to override their personal theme, unless you enable Lock Theme.

Lock Theme

Enable Lock Theme to prevent individual workspaces or members from changing the theme. This is useful for organisations that want strict brand consistency across all product delivery teams.

Email templates

Upload a logo and set a primary colour for Workbench notification emails sent from your organisation. Emails use your branding rather than the generic Productivity Workbench theme.

Workspace Templates

Create reusable workspace configurations that new workspaces inherit on creation — pre-populated with your standard hierarchy, Definition of Done checklists, sprint settings, team roles, and working conventions.

What a template contains

Hierarchy Level — Default hierarchy (Vision→Epic→Feature→Story or just Feature→Story, etc.) for new workspaces.

Definition of Done — Organisation-standard DoD checklists for Features and Stories. New workspaces start with these and can extend (but not delete) them.

Definition of Ready — Standard DoR checklists.

Sprint Settings — Default sprint length, working days, velocity target, and storypointing scale.

Feature Sizes — Standard T-shirt size definitions (S/M/L/XL/XXL) with point range guidance.

RBAC Defaults — Default role assignments for standard personas (Product Owner, Scrum Master, Developer).

Bolt-Ons — Pre-activate selected bolt-ons for all new workspaces from this template.

Creating a template

Click New Template. Give it a name and description. Configure each section. Save. You can create multiple templates for different team types (e.g. "Feature Team", "Platform Team", "Discovery Workstream").

Applying templates

When a new workspace is created, the workspace creator selects a template from the organisation's template library. Templates can also be retroactively applied to existing workspaces (Diff view shows what would change before applying).

Organisation Reports

Cross-workspace aggregate reporting for Organisation Admins — delivery health, team productivity, AI effectiveness, and feature completion trends across all workspaces in the organisation.

Available reports

Delivery Health — Sprint completion rate, story throughput, and cycle time trends aggregated across all workspaces. Highlights workspaces with declining velocity or increasing cycle times.

Feature Completion — Features in progress, completed, and not started across the organisation. Shows which workspaces are making most progress against their roadmaps.

Team Utilisation — Story point capacity vs. allocation across teams. Identifies under- and over-allocated workspaces.

AI Effectiveness (Enterprise) — Aggregate AI usage, acceptance rates, and outcome achievement across all workspaces and Studios.

Governance Compliance (Enterprise) — DPIA completion status, policy exception counts, and Review Theatre verdict distributions across Studios.

Cost Allocation — AI agent run costs and seat usage broken down by workspace and department for internal chargeback reporting.

Filtering

Filter all reports by department, division, workspace, date range, or team member role. Reports remember your last filter selection.

Scheduled distribution

Configure reports to be emailed as PDF to a distribution list on a weekly or monthly schedule. Useful for Steering Committee packs and quarterly planning reviews.

Support

Raise and track support requests for your organisation — billing queries, technical issues, access problems, and feature requests — all in one place.

Raising a support ticket

Click New Ticket. Select a category (Billing, Technical, Access, Feature Request, Governance / Compliance). Describe the issue clearly, including the affected workspace(s), any error messages, and steps to reproduce. Attach screenshots where helpful.

Support tiers & SLAs

Plan	Support channel	Response SLA	Priority routing
Free	Community forum only	Best effort	No
Business	Tickets + email	2 business days	No
Enterprise	Tickets, email + phone	4 hours (P1); 1 day (P2)	Yes — named CSM

Priority levels

P1 — Critical: Organisation-wide outage or data access failure. 24/7 response for Enterprise.
P2 — High: Key feature unavailable, affecting multiple users. Business-hours response.
P3 — Normal: Single-user issue, question, or non-urgent bug.
P4 — Low: Feature request, documentation feedback, cosmetic issue.

Enterprise: Customer Success Manager

Enterprise organisations have a named Customer Success Manager. Your CSM's contact details appear at the top of the Support page. Use them for strategic guidance, onboarding, and escalations above P2.

Organisation Notifications

Configure organisation-wide notification settings — which events generate notifications, who receives them, and through which channels.

Notification categories

Security Alerts — Failed login attempts, IP restriction violations, new device logins, SSO configuration changes.

Billing Events — Payment failures, approaching seat limits, invoice generated, plan renewal upcoming.

Governance Events (Enterprise) — DPIA expiry approaching, policy exception approved, AI agent run anomaly detected.

Workspace Health — Workspace inactivity alerts (no sprint activity in 30+ days), delivery health status changes.

Admin Activity — Member role changes, workspace template updates, security setting changes.

Distribution lists

Create distribution lists (e.g. "Security Team", "Finance", "Engineering Leadership") and assign them to notification categories. Members on a list receive notifications regardless of whether they have Organisation Admin access — useful for routing billing alerts to Finance and security alerts to your CISO.

Channels

In-app: Notification bell in the Organisation Portal header.
Email: Sent to distribution list members. Configure digest frequency (immediate, daily, weekly).
Webhook: POST to a configured URL for integration with Slack, Teams, PagerDuty, or custom tooling.

Build v0.3.2 · deployed 2026-10-19T23:52:31Z

🏢 Organisation Portal

Organisation Portal Overview

What the Organisation Portal covers

Accessing the Organisation Portal

Organisation Hub

Hub sections

Workspace health indicators

Organisation Structure

Building your structure

Assigning workspaces

Why structure matters

Department owners

Billing & Account

Subscribing

Seats and people

Price changes

Cancelling, and coming back

Negotiated contracts

Purchase order number

Invoices

Billing details

Organisation Security

Single Sign-On (SSO)

SCIM 2.0 provisioning

Administrators and their authority over studios

Multi-Factor Authentication

Step-up authentication & session limits

IP allowlisting

Workspace override permissions

Platform abuse protection (MDTS-operated)

Organisation Audit Log

What is recorded

Exporting

Retention

Guardrail Policies

Draft, activate, version

Write your first policy, step by step

Items

Organisation reviewer roles

Release rules

Separation of duties

Exceptions

Coverage

Studios and the organisation link

Studios with no organisation

Exceptions Register

What it lists

What each row tells you

Reading a large organisation

Acting on it

Sampling and Holds

Sample reviews

Legal holds

Evidence retention

Reading a large organisation

Organisation Branding

Logo

Colour scheme

Theme preset

Lock Theme

Email templates

Workspace Templates

What a template contains

Creating a template

Applying templates

Organisation Reports

Available reports

Filtering

Scheduled distribution

Support

Raising a support ticket

Support tiers & SLAs

Priority levels

Enterprise: Customer Success Manager

Organisation Notifications

Notification categories

Distribution lists

Channels

Organisation Portal