Administrator guide

The workspace at /ws/* uses role permissions for each management action. Owners and admins can manage the organization. A catalog_admin manages catalogs, a member_admin manages members, managers and approval groups, and an auditor views observability, audit logs and reports. Only owners and admins can change settings or revoke issued items.

Owners and admins assign roles. An admin cannot assign the owner role, and the last owner cannot be demoted. Connecting Slack synchronizes member information.

Catalog (request types)

A catalog item combines four things: a form, an approval route, post-approval execution, and cost. This is where the design work happens.

Create and edit items under “Catalog” in the workspace. Configure form fields, approval steps (manager, group, or individual; place several in the same step for parallel approval), execution, and cost
Choosing a category (account / access / saas / expense / other) groups the item on the portal Home by category
An approval step can be conditional. Number fields support > >= < <=; select fields support == and in. For example, add approval by directors only when amount > 50000. Keep at least one unconditional step
Conditions are evaluated once from the submitted values when the request is created. A false step is omitted from that request’s route, and a missing optional value makes its condition false
The route is fixed when a request is created. Later catalog or organization changes do not alter requests already in progress
Repeated generic requests or stamps for the same task are a signal to create a dedicated catalog item

Members and approval groups

On “Members,” set each member’s manager and manage approval groups such as it-admins. Groups are used both in catalog approval routes and as assignees for execution tasks.

Inviting members

Even without Slack, you can invite people by email from “Invite members” on the “Members” screen (several addresses, one per line). Invitees receive a Web sign-in link by email, and you can set their manager and approval groups before their first sign-in.

An address that is already registered is not created twice
Use “Disable” on a row for people who have left: they can no longer sign in and are excluded from approver candidates, while approval steps already in progress are kept
The “Slack” column on each row shows whether the person is linked to a Slack account

Execution connections (automation)

Approved work runs automatically for connected systems, including Google Workspace account creation and AWS Identity Center access assignment. Work without a connection or API is sent to the responsible group as a runbook task, and its completion evidence is retained in the ledger. You can add connections later. Use the execution breakdown in observability to decide which system to connect next.

Ledger and revocation

“Ledger” /ws/ledger lists everything issued, including owner, monthly cost, expiration, and the supporting approval
The list switches between active / expiring (within 7 days) / revoked segments. Selecting a row opens the issued-item record on the right (subject, grant, justification, approver, monthly cost, revocation method)
Revocation: Revoke an item that is no longer needed from the record’s action bar. A reason is required, the subject is notified, and an audit record is appended
For an expiring item, the subject receives notice three days before expiration. At expiration, automatic revocation runs for connected systems; otherwise, a runbook task is created
Export CSV files directly for access reviews and inventory checks

Dashboard and audit

“Observability” /ws/dashboard shows request volume, approval lead time (p50/p95), queues, and cost trends. For an audit, export the audit log as CSV for a selected period. Every approval, execution, revocation and configuration change is appended to the audit log. Records are only ever added. Nothing is rewritten or deleted, so nobody has to wonder during an audit whether a row was edited after the fact.

Slack integration

Slack is an optional integration. Connecting it delivers approval cards, reminders, and completion notices as Slack DMs and enables stamps from chat (L0) and declarations (L1). The state is shown on the “Slack integration” card under “Settings” in the workspace.

Install the Bot: Create a Slack app with the required scopes (posting messages, reading reactions, user information, user groups, and commands) and install it into the workspace. Set the bot token (SLACK_BOT_TOKEN), the app token (SLACK_APP_TOKEN), the signing secret, and the client ID/secret for Sign in with Slack as environment variables, then restart the Bot and the Web app
Synchronize: The Bot imports the workspace when it starts; “Sync now” under “Settings” runs the same import on demand. The import reads Slack members and user groups and links existing members whose email matches to their Slack accounts (audit event user.linked_slack). People without a match are created as new members
Verify: The card under “Settings” shows the workspace name, when it was connected, and the last synchronization. Check the Slack column on “Members,” and ask people to run /actagate setup @manager if needed

After connecting, notifications switch to Slack DMs automatically (members with only an email address keep receiving email).

Single sign-on connections

Owners and admins can add OIDC or SAML 2.0 connections on the security settings page at /ws/settings/security. Save a connection as a draft, run its test in the same admin browser session, then activate it.

For SAML, paste the IdP metadata XML or upload a file. Register the displayed SP metadata and ACS URLs with the IdP. IdP-initiated login is disabled by default. After changing authentication settings such as certificates, test and activate the connection again. Consolidate existing users on the members page.

Verify domains, then configure JIT and enforcement

Add a domain under Domain verification at /ws/settings/security. Publish the displayed TXT record name _actagate-challenge.<domain> and value actagate-domain-verification=<token> in DNS, then select Verify. All domains in an organization share one token. Verification runs only when requested and times out after five seconds. TXT chunks within each record are joined before comparison. A domain can be verified by only one organization.

Set routing domains for each connection and enable just-in-time provisioning (JIT) if needed. JIT is off by default and always creates the member role. Email-first routing and JIT use only domains assigned to the connection and verified by its organization. Removing a domain verification stops its use for routing and JIT. A failed recheck retains an earlier successful verification.

To require SSO, an active connection must exist and the administrator must be signed in through that connection. Testing a connection or adding a login method does not meet this condition. Enforcement blocks email links and Slack logins. Only owners (owner) retain email links as an emergency exit. If the IdP fails or settings are incorrect, use this exit to sign in and turn off enforcement. Existing sessions remain valid.

While enforcement is on, the last active connection cannot be disabled or reset to draft by changing authentication settings. Turn off enforcement first. Email responses are identical for registered and unregistered addresses. Under enforcement, email sign-in links are sent only to owners; routed domains go to the IdP regardless of registration.

Only owners (owner) can merge users when the source, target, or resulting role is admin (admin). Email, external identities, and Slack IDs become login methods for the target user. If a merge makes the requester and approver the same person, that person cannot approve the request.

While SSO enforcement is on, users cannot remove their last usable SSO login method. An identity for a disabled connection does not count as an alternative. Owners retain email as an emergency exit.

While SSO enforcement is on, invitation emails link to the login page. They do not include a token for signing in by email.