Builder Guide
Build with ActiveWorkplace
Add and configure the recursive work module without creating a second record or permission system.
ActiveWorkplace gives an app a shared work surface around any permitted Record. The pinned Record and everything connected to it remain in their existing modules; the workplace adds coordination, responsibility, Pulse, attention, and history.
Add the block
- Open the app and page in the Developer Console page editor.
- Add
module.active-workplacefrom First Class Modules. - Place the page in the existing menus for the User Types that should see it.
- Configure bounded defaults, preview as representative users, and publish the normal exact app version.
Configuration
| Setting | Safe starting point | Effect |
|---|---|---|
| Allowed root module keys | Empty, or a short intended list | Filters which visible Record types the pin picker offers. It is product behavior, not authorization. |
| Maximum depth | 2 | How many relation hops a snapshot follows; supported range is 1–5. |
| Maximum nodes | 100 | Hard graph bound; supported range is 2–200. |
| Stale after | 3 days | Minutes without meaningful activity before Stale. |
| Warning before stale | 12 hours | How early the workplace becomes At Risk. |
| Participant types | User, GoClaw, Workflow | Which eligible participant pickers the block shows. |
| Default GoClaws | None initially | Eligible agents automatically added as non-acting watchers; server AI-read checks still apply. |
| Comments | Enabled | Shows the meaningful workplace update form. |
| Playback | Enabled | Allows retained historical inspection in read-only mode. |
Block settings are never an authorization token. The browser can request a root, scope, or participant, but reviewed stored procedures re-derive the tenant/app/user envelope and refuse anything outside it.
Design the Record graph first
Use a small vocabulary of meaningful typed relationships. ActiveWorkplace traverses existing RecordRelations; it does not infer a private parallel graph. Cycles are supported, but broad, vague relations can make a workplace noisy even when the hard bounds protect performance.
Choose Pulse rules by work type
A support case may become stale after hours, while a contract review or opportunity may need days. Waiting suspends normal progress expectations until its date/reason is satisfied; Dormant is deliberate inactivity; Resolved closes the coordinated work. A deterministic worker evaluates timing and related Record updates without sending business data to a model.
GoClaw and workflow defaults
Default assignment is a convenience only. The selected GoClaw must be active and its backing user must independently have CanAiReadRecords for the root. Keep material actions under human approval until their action-specific policy is proven. Published workflows remain limited to their existing definitions and permissions.
A good first launch uses people plus one read-only GoClaw watcher. Add deterministic actions only after the team trusts the Pulse and activity evidence.
Acceptance test
- Pin one permitted root and confirm retry opens the same active workplace.
- Create a cycle and confirm the graph remains bounded.
- Relate a Record from another location and confirm it and its edges are absent.
- Try an AI-read-denied GoClaw and confirm assignment is refused.
- Advance Waiting into At Risk/Stale and confirm one Inbox item is touched on retry.
- Open playback, change the tester’s current location permission, and confirm the retained Record disappears or playback is denied.
- Confirm playback contains no write, workflow, GoClaw, participant, status, comment, refresh, or destructive controls.
Do not place a customer secret, bearer token, database name, connection string, or copied business payload in workplace configuration. ActiveWorkplace needs Record identities and normal platform references only.