Admin controls¶
Everything here lives in the Portal (mostly under Settings) and most of it is admin-gated once role-based access is on. These are the levers you reach for occasionally, not every day.
Users & permissions¶
Role-based access (RBAC) controls who can see and do what in the Portal.
- Access is keyed on the signed-in operator's identity (via your identity provider).
- A bootstrap admin is always granted admin regardless of the in-app store — this is the lockout safety net when you first turn enforcement on. Seed at least one before enabling.
- Once enabled, manage everyone else in-app: Settings → Users & permissions. Non-admin roles (e.g. a reviewer who can approve but not change settings) hide admin-only surfaces and are enforced on the server, not just in the UI.
Turn it on without locking yourself out
Seed the bootstrap admin first, verify you can still sign in and see the admin surfaces, then enable enforcement. Confirm an unauthenticated request is rejected so you know sign-in is actually required.
Notifications¶
Post a card to a channel (e.g. Teams) when a plan is ready to review and when an execution finishes.
- Settings → Notifications: paste the channel webhook URL, choose which events fire, save, and send a test.
- Off by default. The webhook URL is stored as a secret reference, never in plain text.
Planning guidance¶
Guidance shapes how the AI plans — standards it should uphold, conventions to follow, per-client specifics.
- Org template (Tier 1) applies to every client.
- Per-client override (Tier 2) layers on top for one client only.
Editing the built-in default requires a reset to go live
The live org template is the version stored by the platform. If the built-in default changes (for example after a platform update), it does not reach the AI until you apply it: Settings → guidance → Reset to platform default. If a guidance change doesn't seem to be taking effect, this is almost always why.
Ticket controls¶
| Control | What it does |
|---|---|
| Reset / Start over | Returns a ticket to a clean, re-plannable state. Mutates nothing that already ran — the audit trail is preserved. Refused while an execution is in flight. |
| Retry | Re-runs the failed operations of an execution job after you've fixed an external cause. |
| Dismiss | Hides a ticket from the board without changing its records — a reversible board-tidy, distinct from Reset. |
Tenant lifecycle¶
Clients can be moved through lifecycle states without deleting anything:
- Archive / Suspend hides a client's tickets from the active board and stops new work for them.
- Restore brings them back.
This keeps the board focused on active clients while retaining history.
Intake and PSA controls¶
- Pause intake stops new tickets being ingested while you work through a backlog or investigate an issue.
- Pull from PSA fetches tickets on demand rather than waiting for the next scheduled sync — useful right after connecting a PSA or when driving a specific ticket.
- The connector tracks a cursor so scheduled pulls only fetch what's new; an on-demand pull is available when you need to re-fetch.
Board purge¶
A purge clears the working board (tickets, plans, executions shown in the Portal). Use it deliberately — it's how you return a test or demo environment to a clean state. It's an admin action; treat it as destructive to the board view, and confirm before running it.