Organise workspace access with Centres
Centres are workspace departments that give administrators fine-grained control over who can see and edit which records and modules. Each centre has its own Viewer and Editor members, object-type ownership and module-sharing policies. When a workspace is activated, access is governed entirely by centre grants rather than the legacy workspace-wide model. > **Deployment status:** The full Centres enforcement stack — all 148 server-side functions, Firestore rules, guarded Storage rules and the Inbox index — was successfully deployed to production on 11 October 2026 (sources: [enforcement run](https://github.com/willradley-rcf/radley-hub/actions/runs/38116597134), [activation/preparation run](https://github.com/willradley-rcf/radley-hub/actions/runs/38121306749), PRs [#864](https://github.com/willradley-rcf/radley-hub/pull/864)–[#871](https://github.com/willradley-rcf/radley-hub/pull/871), merged 10–11 October 2026). Both production Hub hosts return HTTP 200; unauthenticated record-read and staff-file requests are correctly denied with HTTP 401. Existing workspaces retain their current workspace-wide access until an administrator completes the explicit readiness review and activates the workspace. No records, roles or permissions change automatically. ## What a centre controls Each centre can own one or more object types and modules. A member's effective access is the combination of every centre they belong to: - **Viewers** can read records of owned types and use owned modules. - **Editors** can also perform supported operational actions — creating, updating and completing work — on records they have an edit grant for. - Configuration, schema changes, deletion and explicit publishing require workspace administration, even after activation. Owners and administrators retain oversight across all centres. ## Set up Centres Centres are configured in **Settings → Centres**. ### Create a centre 1. Open **Settings → Centres**. 2. Select **New centre**. 3. Give the centre a clear, descriptive name (for example, *Sales*, *Operations* or *Customer Success*). 4. Save. ### Add members 1. Open the centre. 2. Under **Members**, select **Add member**. 3. Choose a workspace member and assign them a role: - **Viewer** — read access to this centre's owned records and modules. - **Editor** — read and operational edit access. 4. Save. A member can belong to multiple centres. Their access in each context is the combined grants from all the centres they are a member of. ### Assign object-type ownership Every active object type (including retired types) in the workspace must be assigned to an owning centre before activation is available. 1. Open the centre. 2. Under **Object types**, select the types this centre should own. 3. Save. If two centres share responsibility for an object type, configure sharing so members of both centres can access it. ### Assign module ownership Modules such as Finance, Marketing, Forms and Inbox can also be owned and shared between centres. 1. Open the centre. 2. Under **Modules**, select the modules this centre should own. 3. Save. ## Select an active centre Once centres exist in your workspace, a **centre selector** appears below the workspace selector in the sidebar. Selecting a centre narrows your working view to the records and modules accessible to that centre. This is a view preference — it does not change what you are authorised to access. Your active centre selection is saved per workspace and remembered between sessions. Administrators and owners see all records regardless of the selected centre. > **Navigation stability:** The sidebar centre selector uses a stable memoised filter, and the recent-pages effect is keyed by the active page ID. This prevents the React update-depth error and stale navigation stalls that were observed during the initial release; both are fixed as of PR [#869](https://github.com/willradley-rcf/radley-hub/pull/869) (merged 10 October 2026). ## The readiness review Before a workspace can be activated, Settings → Centres shows a **readiness review** that checks: - Every object type has an active owning centre. - Every enabled supported module has an owning centre. - All members have been assigned to at least one centre. - No malformed authority or unresolved historical file references exist. The review also lists the impact on external sharing and the number of background tasks that will need to be rechecked after activation. ## Activate a workspace Activation is available only after the readiness review passes. To begin: 1. Open **Settings → Centres**. 2. Select **Access review**. 3. Review the member and external-sharing impact summary. 4. Confirm the authority digest. 5. Select **Activate**. After activation: - Access switches from the legacy workspace-wide model to centre-governed access. - Standard members can only read types and use modules assigned to their centres. - Background adapters that do not yet support centre execution are paused and must be reconfigured. - Existing workspace, type and record identifiers, URLs and billing are unchanged. > **Before activating a production workspace**, confirm with your Hub administrator that the 148-function enforcement deployment, Firestore rules, Storage rules and Inbox index have all reached a verified READY state. The enforcement deployment completed successfully on 11 October 2026, so this prerequisite is met for workspaces on the current production build. Activation cannot be reversed without Hub administrator involvement. ## How enforcement works after activation Once a workspace is activated, Centres enforcement applies across every surface: | Surface | Enforcement | |---|---| | Records, search, relationships and activity | Object-type policy and record ancestry checked on the server. Stale client results are discarded. | | Mutations, imports and Hub connector | Centre grants, ancestry and supported operations checked inside Firestore write transactions. | | Finance, budgets, forecasts, KPIs and reports | Module access and all required source records checked. Inaccessible dependencies make a figure unavailable rather than returning a partial total. | | Forms, quizzes and staff chat | Module grants alone do not reveal linked responses or conversations. Current parents and ancestry are required. | | Inbox and interactive AI | Linked conversations require all recorded sources to be accessible. Interactive AI reads only authorised evidence. | | Files | Record and library file gateways authorise byte access. Private Storage SDK paths cannot bypass them. File gateways run at concurrency 1 to match the fractional CPU quota policy. | | Client revocation | Access-revision changes remount or invalidate protected subscriptions and state. Temporary object URLs are revoked. | ## Historical files and previews Before activation, Hub prepares historical file previews and private record images. Ambiguous or externally shared historical files block preparation until resolved. The preparation step is available in **Settings → Centres** under **Background preparation**. File preparation does not move or republish any customer-facing content. It makes private file access compatible with gateway-authorised delivery after activation. ## Background tasks and agents Background tasks, automations, agents and scheduled jobs that run under a centre scope require an approved background scope configuration. Unsupported background adapters are paused after activation rather than continuing with legacy access. To configure background scopes: 1. Open **Settings → Centres**. 2. Select **Background scope**. 3. Review the listed background adapters and grant the required centre execution scope for each. 4. Save. ## Invitations after activation When inviting a new workspace member, their centre roles are applied atomically on acceptance. A workspace member's pending invitation assignments are removed if a centre they were assigned to is archived before they accept. ## Legacy access Workspaces that have not been activated continue to use the existing workspace-wide permission model. No configuration changes are required and no existing access is affected unless an administrator begins the activation process. Unsupported historical Finance and AI results remain unavailable to standard members after activation, even if those results were accessible under the legacy model. ## Common questions **Can a member belong to more than one centre?** Yes. A member's effective access is the union of all the centre grants they hold. Selecting a specific active centre in the sidebar filters the view but does not restrict what they are authorised to access. **Can I archive a centre?** Yes, but archiving requires that all owned object types and modules are reassigned to another centre first. Archiving removes all member grants from the archived centre and removes any pending invitation assignments. **Does activation change record URLs or workspace billing?** No. Existing workspace, object type and record identifiers, record URLs and workspace billing are all preserved. **What happens to public publishing and customer portal access?** Public publishing and customer portal access are governed by their own separate controls and are not affected by centre activation. **Who can manage Centres?** Only workspace owners and administrators can create, rename, archive and configure centres, assign members, and activate the workspace. **Is the enforcement infrastructure ready to use?** Yes. The full enforcement stack was verified in production on 11 October 2026: all 148 server-side exports confirmed, Firestore and Storage rules deployed, Inbox index READY, and both production Hub hosts verified at HTTP 200. Individual workspace activation remains an explicit administrator decision and has not been performed on any production workspace.