IT · Access requests
RelayIT operationsAccess requests checked against role rules before anyone clicks approve
Most access requests are routine, and most of the effort goes into checking who should have what. This playbook sets up a Relay that checks role rules, prepares the Okta change and waits for a manager to approve it.
Valnora & Elric team5 min read
- Format
- Playbook
- Steps
- 6
- Solution
- Relay
- Parts used
- 5
At 9:10 on a Tuesday, a sales operations analyst posts in #it-help: "Can I get read access to Salesforce reports and the forecasting board?" Someone on the IT team has to find out who they are, what their role allows, which Okta group grants it, and who should approve. The change itself takes thirty seconds. The checking takes the rest of the morning.
This playbook moves the checking to a Relay, an AI coworker in Agent Serve, and keeps the decision with a manager. Requests come from Slack or Jira Service Management, are checked against written role rules, and the Okta change runs once, after approval, with a record of every step.
Step 1: Write the role rules down
Create an Access rules table in Tables. One row per role and group:
- Role, as it appears in your HR system or Okta profile.
- Allowed group, the Okta group that grants the access.
- Approver, usually the line manager, or the app owner for sensitive groups.
- Sensitive, yes or no. Admin roles, finance systems and production access are yes.
Add your access policy to the Knowledge Base as well, including what is never granted on request. The table answers "does this role get this group"; the policy answers the questions the table does not.
Step 2: Collect requests in one table
Build an intake workflow in the workflow builder with a Webhook trigger. Point a Jira Service Management automation at it for new access tickets, and a Slack workflow form for people who ask in a channel. The workflow writes one row per request to an Access requests table with the requester, what they asked for in their own words, the reason, the ticket link and a status of new.
Step 3: Set up the access coordinator Relay
From a request in Slack to an audited Okta change
Workflow · Intake
- 01Request arrivesA Jira Service Management automation or a Slack form sends the request to the workflow’s Webhook trigger.
- 02Access requests tableOne row per request: who, which app or group, why, ticket link, status.
Relay · Access coordinator
- 03Watch new rowsWatches the access requests table every minute for rows marked new.
- 04Check role rulesReads the role access table and the requester’s current Okta groups to see if the request fits.
- 05Manager approvesThe prepared Okta change waits as a proposal. The manager sees the exact change and approves or declines.
- 06Close the requestAn allowlisted workflow updates the row, comments on the ticket and replies in Slack.
Create the Relay from the specialization closest to the job, or from a blank one, and give it:
- Trigger: watch the Access requests table, checked every minute.
- Integrations on its allowlist: Okta, to look up the requester and their current groups and to change group membership.
- Workflow on its allowlist: Close access request, which updates the row, comments on the ticket and replies in Slack.
- Autonomy: Assist. Reads run, writes wait for approval.
For each new row, the Relay reads the requester's Okta profile and groups, maps the plain-language request to a group using the rules table, and checks the role. If everything fits, it prepares the change. If the group is sensitive, it names the app owner as approver. If nothing fits, it prepares nothing and writes a note for the IT queue.
Step 4: A manager approves the exact change
What the solution produces
Proposal waiting for approval (illustrative)
Record- Request
- REQ-1182 · from #it-help · Jira ticket ITSM-5520
- Requester
- Sales operations analyst, joined 3 weeks ago
- Asked for
- "Read access to Salesforce reports and the forecasting board"
- Rule matched
- Role "Sales operations analyst" may hold group sales-reporting-read. Approver: line manager.
- Current groups
- all-staff, sales-ops. Not in sales-reporting-read.
- Proposed change
- Okta: add user to group sales-reporting-read
- Call class
- Write · waits for approval under Assist
- Expires
- In 24 hours if nobody decides
Reply in the Slack thread after approval (illustrative)
MessageDone: you have been added to sales-reporting-read in Okta. Salesforce reports should appear the next time you sign in.
Approved by your manager at 10:42. Ticket ITSM-5520 has been updated and closed.
Adding a user to an Okta group is a write, so under Assist it waits as a proposal. The approver sees the request, the rule that matched, the current groups and the exact change. Approval covers that payload only. If nobody decides within 24 hours, the approval expires and the Relay flags the request rather than retrying quietly.
Removals deserve the same care. Destructive calls always wait for approval, whatever the autonomy setting, unless delegated limits cover them, so check how your Okta removals are classed before you widen the Relay's job.
Step 5: Run once, close the loop
Once approved, the Okta call runs exactly once. The Relay then runs the Close access request workflow, which marks the row done, comments on the Jira ticket and replies in the Slack thread. Because the Relay does not write table rows itself, the status change always comes from a deployed workflow with its own run log.
Step 6: Keep the record
Controls and governance
Approvals before action
Relays never send email or book meetings without an approval, under any autonomy setting. An approval covers the exact payload the reviewer saw and expires if nobody decides.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
SSO and SCIM
Sign in through your identity provider with SAML 2.0 or OIDC, and provision people with SCIM.
Deployed versions
Workflows run from a deployed version, so a change is reviewed before it reaches production runs.
More on how Agent Serve handles access, data and audit on the security page.
Every proposal, approval, decline and executed call goes to the workspace audit log, which admins can export. That record answers the question auditors ask most: who approved this access, when, and against which rule. It also feeds the periodic review described in user access reviews.
If something looks wrong, the kill switch pauses the Relay at once. The daily summary lists requests handled, waiting and declined, so the IT lead sees the queue without opening each ticket.
Questions teams ask
Can the Relay grant access without approval?
Not under Assist, which is the setting this playbook uses: every write waits for a person. Under Operate, writes run on their own, which is why many IT teams keep access changes on Assist. Removals and anything treated as destructive always wait for approval unless you set delegated limits.
What happens to requests that do not fit a rule?
The Relay does not prepare a change. It writes a short note for the IT queue saying which rule is missing or why the request falls outside it, and a person handles it.
Does this replace access reviews?
No. It controls how access is granted. Periodic reviews of who still holds what are a separate job, covered in the guide to user access reviews.