User Guide

Everything you need to know to request, approve, and manage access in AccessOps.

Getting Started

AccessOps ships with three demo users, each representing a different system role. On the login page, use the quick-login buttons to switch between them — no need to type credentials.

UserEmailRoleCapabilities
Alicealice@example.comADMINFull system access. Can manage users, roles, approve requests, and view audit logs.
Bobbob@example.comAPPROVERCan review and approve/deny pending access requests. Views audit log.
Charliecharlie@example.comUSERStandard user. Can submit access requests and track their status.
Tip: All demo users share the same password: password123

Requesting Access

Any authenticated user can request access to a role. Here's how it works:

1

Navigate to New Request

Go to My Requests and click New Request, or navigate directly to /requests/new.

2

Select a Role

Pick from the available roles. Each role shows how many approval steps are required. More sensitive roles need more approvals.

3

Provide Justification

Write a business justification explaining why you need this access. This is visible to all approvers in the chain.

4

Submit & Wait

When you submit, two things happen simultaneously: the request and approval steps are created in the database, and a durable DBOS workflow begins orchestrating the approval chain. Track status on your My Requests page.

What happens behind the scenes?

When you click Submit, the API handler calls dbos.RunWorkflow(ApprovalWorkflow) which starts a crash-proof workflow. This workflow will persist through any number of server restarts — it can wait days for each approver without consuming server resources. See the Architecture page for the full story.

Approving Requests

Users with the APPROVER or ADMIN role can review and act on pending access requests.

1

Check Pending Approvals

The Approvals page shows all approval steps assigned to you. Each card shows the requester, requested role, and their justification.

2

Approve or Deny

Click Approve or Deny. You can add a comment explaining your decision. This comment is recorded in the audit log.

3

Multi-Step Chains

Some roles require multiple approvals (e.g., both Bob and Alice must approve). The workflow advances through each step in order. If any step is denied, the entire request is denied immediately. If a step times out after 7 days, it's auto-escalated.

Approver ownership

Only the assigned approver for a given step can act on it. The API enforces this — even if you're an admin, you can only approve steps assigned to you. This ensures proper separation of duties.

Admin Panel

The Admin page (ADMIN only) provides system-wide management capabilities organized into tabs:

Users

View all users in the system with their roles and status.

Roles

Manage available roles. Create new roles and set how many approval steps they require.

All Requests

System-wide view of every access request and its current status, regardless of requester.

Audit Log

The Audit Log (APPROVER and ADMIN) provides a complete, immutable record of every access-related action in the system. Every operation — from request creation to automated expiry — is logged as a durable workflow step, meaning even audit entries survive crashes.

Event Types

EventDescription
ACCESS_REQUEST_CREATEDA user submitted a new access request
APPROVAL_GRANTEDAn approver approved an approval step
APPROVAL_DENIEDAn approver denied a request
ACCESS_PROVISIONEDRole was provisioned after full approval
ACCESS_AUTO_EXPIREDScheduled workflow revoked an expired role
WEEKLY_ACCESS_REVIEWScheduled compliance report was generated

Use the filters at the top to narrow by action type, date range, or actor. Expand any row to see the full event payload, including workflow IDs that link back to DBOS execution history.

Quick Walkthrough

Try the full flow end-to-end:

  1. 1 Login as Charlie (USER) and submit an access request for the "editor" role.
  2. 2 Login as Bob (APPROVER) and approve the pending request.
  3. 3 Login as Alice (ADMIN) and approve the second approval step.
  4. 4 The provisioning saga runs automatically — the role is assigned and the external system is provisioned.
  5. 5 Check the Audit Log to see the complete trail of every action.
Fun fact: Between steps 1 and 4, the DBOS approval workflow is sitting in a durable Recv call. The server could restart 50 times and the workflow would pick up exactly where it left off.