Video chapters
- 0:00 Welcome
- 0:09 Overview: how an access request works
- 0:52 Part 1 · Ask for access — Asking for access: explained
- 1:15 Ask from the lock screen
- 1:47 Two more requests
- 2:11 My requests and withdrawing: explained
- 2:25 Track and withdraw
- 2:54 Part 2 · Decide: approve, or hand it on — The owner's queue
- 3:16 Granting through a role or group: explained
- 3:42 Approve through the Support team group
- 4:04 Reassign and escalate: explained
- 4:21 Hand it to Morgan
- 4:37 Part 3 · Escalate and decline — Morgan escalates
- 5:01 Declining with a note: explained
- 5:12 Avery declines Billing
- 5:53 Part 4 · The outcome and the trail — The outcome: explained
- 6:14 Sam's answers and new access
- 7:03 The trail and where access lives
- 7:29 Wrap-up
Written guide
Written course script · documented draft · Independent account tests pending
Overview
Prepare
Use an ordinary training requester and an authorized reviewer in separate browser profiles. Have an existing custom role/group that grants the intended training screen, plus a disposable workflow item for non-access decisions. Never use Owner to prove ordinary access restrictions or grant broad privileges just to make the example pass.
1. Submit a request from its actual context
As the requester, open a screen that the account cannot access but the organization's policy allows it to request. In Ask for access, enter a concise reason and choose Request access. Read the returned result rather than assuming every denial opens a request.
- Request sent. establishes a pending request.
- You already asked for this. identifies an existing pending request; inspect it instead of duplicating it.
- A denied response can say the operation cannot be requested.
- Nothing stands in the way — reload to try again. means retry the original screen after reloading, not wait for a new approval.
The UI promises tray/email notification, but email receipt depends on actual configured delivery. Verify the controlled inbox separately; a pending row is not email proof.
2. Navigate the four approval views
Open Approvals. Its four views are Waiting on you, My requests, Notices and Decided. The full screen uses the same tray information as the bell, with space to inspect details. Select the request by its title, requester and submission time; expand its row or use Review for an access request.
Read the specific requested path and app. A shared title can exist in different products. Keep organization and requester identity visible when moving between accounts. The tab/task can appear in the address bar, but opening a task link does not grant permission to decide it.
The historical queue contains a workflow approval, “Tutorial Automated kickoff sample.” It is not an access-grant request. Use the title, requester and time to identify your own item rather than assuming every approval grants application access.
Select the chevron beside the task title to expand it. The note, reassignment and decision actions are then visible. The access-request Grant through selector described next appears only for the corresponding access-request type; it is not missing from this workflow task.
3. Grant access through the correct role or group
In the expanded access request, inspect its reason and Screen. Under Grant through, choose the intended role or group from the matching options. These options are filtered for menu coverage; they are not arbitrary one-off permissions.
- Confirm the requested Screen, app and requester before selecting a grant.
- Under Grant through, select the intended existing role or group that covers that screen. For an access request, Approve remains disabled without a grant. Do not choose a broad administrator role merely to unblock the button.
- Enter a useful decision note and choose Approve once. Wait while the action is busy.
- Open Decided, find the same request and inspect its outcome.
- In the requester’s separate session, refresh the originally requested screen and test the intended action. Keep this independent check separate from the reviewer’s success notice.
The picker excludes special roles such as Owner, system, customer, guest and AI identities. Do not interpret their absence as a broken list. Menu coverage also does not guarantee every record action: the chosen role still needs the appropriate record/collection permissions for the actual work.
If no role/group includes the screen, open Role & Permission, configure a suitable custom role's menu and required actions, save and reopen it. Return to Approvals and reload/reopen the review so its options are fetched again. A roles/groups load failure has a retry state; it is not proof no suitable grant exists.
4. Verify the requester receives the intended capability
In the requester profile, inspect the granted assignment. Refresh identity through a fresh sign-in or supported session refresh, reopen the requested screen and perform a harmless authorized action on the training record. Reopen the record to check persistence. Test an action the grant should not allow.
If access is still missing, inspect the actual grant, route/app, refreshed identity and collection rules. Do not approve a second broader request to hide a broken first grant. Approval status and useful effective access are separate checks.
5. Decline and explain the decision
Use a separate controlled request. Expand it, add a short note explaining why the request is declined or what must change, then choose Decline. Inspect Decided, the requester's My requests and its notice. Repeat the original operation as the requester to establish that no unwanted access was granted.
Non-access tasks can expose quick Approve and Decline buttons in the collapsed queue. Expand first when a note or more context is needed. An access task uses Review because it needs the grant choice.
6. Reassign to another reviewer
Expand a pending controlled task. In Hand to someone else (email) enter the authorized reviewer's actual account email. Multiple addresses are comma-separated in the client. Choose Reassign, then open the other reviewer's independent session and inspect its queue and task ownership.
The button's simple email check is not proof that an entered person exists or is eligible. Read the server result and confirm the actual assignee. On failure, correct the target rather than repeatedly forwarding an invalid address.
7. Escalate according to the workflow's configured behavior
Use a task whose stage has an actual escalation definition. Inspect that definition in Workflow before the demonstration. Return to the expanded approval and choose Escalate. The control runs the stage's escalation now instead of waiting for its timer.
Show the resulting assignment/state and next reviewer. If the stage has no applicable escalation, teach the returned outcome; do not promise that Escalate always forwards to an administrator.
Workflow design belongs in its own module, but this course must show the concrete configuration and effect used by this action.
8. Withdraw an unused request and inspect history
As the requester, open My requests, find the correct pending request and choose Withdraw. Refresh and inspect its cancelled state. As the reviewer, check that the same request no longer waits for a decision. Withdrawal is available for pending personal access requests; it does not undo an already granted role.
Open Decided and inspect who decided, when, status, note and saved grant where present. Follow a task link to inspect that exact request even when it is not in the current waiting list. The linked card may show Still waiting on… without decision controls when the account cannot decide it.
9. Read notices and handle concurrent decisions
Open Notices. Click an unread decision/assignment notice to mark it read and open its task. Access-change notices can mark read without opening a task. Use Mark all read only when the listed notices have been reviewed; it changes read state, not approval state.
If another reviewer already decided or the requester withdrew, an attempted decision can return a conflict. The queue handles that as a stale pending item and reloads. Inspect Decided before trying again. A failed fetch is different from Nothing is waiting on you; use the displayed retry/Refresh route and preserve the actual error.
Limitations and checks
Reviewed current components/approval/app.tsx, waiting-on-you.tsx, request-access.tsx, my-notices.tsx. Live proof remains for request policies, filtered grant correctness, independent acceptance/denial, reassignment, configured escalation, withdrawal conflicts, email delivery and resulting application operations. The course does not infer completion of an AI employee task merely from an approval: inspect the exact subsequent task/result in the AI Employees course.
BusinessMade Approvals: Access Requests, Decisions and History — supporting guide
BusinessMade entry: Admin → Approvals (/admin/approvals).
This queue is for the shared approval records. Payroll readiness, leave approval and time-sheet review can have their own module controls; do not substitute this queue for those domain-specific decisions.
Scope: This BusinessMade route uses the shared component whose complete procedures follow. Use the BusinessMade menu and organization throughout. Shared references are implementation evidence, not instructions to switch products. These written steps have not been replayed as a new BusinessMade live walkthrough.
Written course script · documented draft · Independent account tests pending
Understand the records and results
Explanatory diagram, not an application screenshot. An approval label alone does not establish that the requested operation is now allowed. It explains the distinctions used in the steps below; it does not establish a completed live workflow.
Overview
Approvals brings together requests waiting on you, requests you submitted and the decisions already made. We'll review an access request, choose the role or group that grants it, and check the result as the requester. We'll also decline, withdraw, reassign and escalate controlled requests so you know which action fits each situation.
Prepare
Use an ordinary training requester and an authorized reviewer in separate browser profiles. Have an existing custom role/group that grants the intended training screen, plus a disposable workflow item for non-access decisions. Never use Owner to prove ordinary access restrictions or grant broad privileges just to make the example pass.
Before you begin: two identities, one request
Sign in to BusinessMade as the requester and note the organization name and the exact screen being requested. Use a separate browser profile for the reviewer so changing accounts does not silently replace the requester session. The reviewer needs access to Admin → Approvals and authority over the selected request. If your organization has no suitable custom role or group, create and check one through Admin → Roles & permissions before attempting the grant.
The three checks are different: a pending request establishes that the request exists; a decided request establishes what the reviewer approved; successful access from the requester's account establishes the practical result. Keep the request identity through all three. An empty reviewer queue may mean this reviewer was not assigned, not that the request disappeared.
Illustration gap: a matching BusinessMade Admin Approvals capture is not available in the retained evidence. Staff portal leave/expense approval screens are a different workflow and are intentionally not substituted. Request creation, grant selection and requester readback still need an independent live walkthrough.
1. Submit a request from its actual context
As the requester, open a screen that the account cannot access but the organization's policy allows it to request. In Ask for access, enter a concise reason and choose Request access. Read the returned result rather than assuming every denial opens a request.
- Request sent. establishes a pending request.
- You already asked for this. identifies an existing pending request; inspect it instead of duplicating it.
- A denied response can say the operation cannot be requested.
- Nothing stands in the way — reload to try again. means retry the original screen after reloading, not wait for a new approval.
I'll ask for this screen from the access message itself. The response names who is waiting to decide. Now we'll open that same request as the reviewer.
The UI promises tray/email notification, but email receipt depends on actual configured delivery. Verify the controlled inbox separately; a pending row is not email proof.
2. Navigate the four approval views
Open Approvals. Show Waiting on you, My requests, Notices and Decided. The full screen uses the same tray information as the bell, with space to inspect details. Select the request by its title, requester and submission time; expand its row or use Review for an access request.
Waiting on you is your decision queue. My requests follows what you asked for. Notices communicates changes, and Decided lets you inspect the outcome afterward.
Read the specific requested path and app. A shared title can exist in different products. Keep organization and requester identity visible when moving between accounts. The tab/task can appear in the address bar, but opening a task link does not grant permission to decide it.
3. Grant access through the correct role or group
In the expanded access request, inspect its reason and Screen. Under Grant through, choose the intended role or group from the matching options. These options are filtered for menu coverage; they are not arbitrary one-off permissions.
Enter an optional note describing the decision, then choose Approve once. Wait for the result and refresh the relevant view. Reopen the decided request to read the grant and decision.
This group includes the screen being requested. I'll grant through that group so the access can later be reviewed and removed through the same assignment.
The picker excludes special roles such as Owner, system, customer, guest and AI identities. Do not interpret their absence as a broken list. Menu coverage also does not guarantee every record action: the chosen role still needs the appropriate record/collection permissions for the actual work.
If no role/group includes the screen, open Role & Permission, configure a suitable custom role's menu and required actions, save and reopen it. Return to Approvals and reload/reopen the review so its options are fetched again. A roles/groups load failure has a retry state; it is not proof no suitable grant exists.
4. Verify the requester receives the intended capability
Concept diagram, not a screenshot or a completed-action record. History proves the decision was recorded; the original task proves its actual effect.
In the requester profile, inspect the granted assignment. Refresh identity through a fresh sign-in or supported session refresh, reopen the requested screen and perform a harmless authorized action on the training record. Reopen the record to check persistence. Test an action the grant should not allow.
The decision is saved. Now we're checking the result with the requester—not the reviewer—and confirming it enables the intended work without assuming broader access.
If access is still missing, inspect the actual grant, route/app, refreshed identity and collection rules. Do not approve a second broader request to hide a broken first grant. Approval status and useful effective access are separate checks.
5. Decline and explain the decision
Use a separate controlled request. Expand it, add a short note explaining why the request is declined or what must change, then choose Decline. Inspect Decided, the requester's My requests and its notice. Repeat the original operation as the requester to establish that no unwanted access was granted.
Non-access tasks can expose quick Approve and Decline buttons in the collapsed queue. Expand first when a note or more context is needed. An access task uses Review because it needs the grant choice.
A decline should leave the requester with a clear answer. We'll verify the saved reason and the unchanged access rather than treating the disappeared queue row as enough.
6. Reassign to another reviewer
Expand a pending controlled task. In Hand to someone else (email) enter the authorized reviewer's actual account email. Multiple addresses are comma-separated in the client. Choose Reassign, then open the other reviewer's independent session and inspect its queue and task ownership.
Reassign changes who should handle the pending decision. It is not an approval and does not by itself complete the requested work.
The button's simple email check is not proof that an entered person exists or is eligible. Read the server result and confirm the actual assignee. On failure, correct the target rather than repeatedly forwarding an invalid address.
7. Escalate according to the workflow's configured behavior
Use a task whose stage has an actual escalation definition. Inspect that definition in Workflow before the demonstration. Return to the expanded approval and choose Escalate. The control runs the stage's escalation now instead of waiting for its timer.
Show the resulting assignment/state and next reviewer. If the stage has no applicable escalation, teach the returned outcome; do not promise that Escalate always forwards to an administrator.
Escalation follows the stage's configured rule. We'll check that rule first, then inspect the task after running it.
Workflow design belongs in its own module, but this course must show the concrete configuration and effect used by this action.
8. Withdraw an unused request and inspect history
As the requester, open My requests, find the correct pending request and choose Withdraw. Refresh and inspect its cancelled state. As the reviewer, check that the same request no longer waits for a decision. Withdrawal is available for pending personal access requests; it does not undo an already granted role.
Open Decided and inspect who decided, when, status, note and saved grant where present. Follow a task link to inspect that exact request even when it is not in the current waiting list. The linked card may show Still waiting on… without decision controls when the account cannot decide it.
History explains the decision. To remove access that was already granted, change the role/group assignment through User Management; cancelling an old request is not revocation.
9. Read notices and handle concurrent decisions
Open Notices. Click an unread decision/assignment notice to mark it read and open its task. Access-change notices can mark read without opening a task. Use Mark all read only when the listed notices have been reviewed; it changes read state, not approval state.
If another reviewer already decided or the requester withdrew, an attempted decision can return a conflict. The queue handles that as a stale pending item and reloads. Inspect Decided before trying again. A failed fetch is different from Nothing is waiting on you; use the displayed retry/Refresh route and preserve the actual error.
Limitations and checks
Approvals gives the decision a clear owner and a traceable outcome. Check the requested action, choose a fitting grant or workflow decision, and verify the effect where the requester actually works.
Reviewed current components/approval/app.tsx, waiting-on-you.tsx, request-access.tsx, my-notices.tsx. Live proof remains for request policies, filtered grant correctness, independent acceptance/denial, reassignment, configured escalation, withdrawal conflicts, email delivery and resulting application operations. The course does not infer completion of an AI employee task merely from an approval: inspect the exact subsequent task/result in the AI Employees course.
BusinessMade routing and outcome check
The menu and route were checked in packages/ui/src/ui/sidebars/business-made-links.ts and apps/business-made/src/shell/route-registry.ts. After an authorized decision, return as the requester and verify the intended access in its original context; opening the approval list alone proves no access change. Do not infer branch isolation from a header location selection when this shared screen reads organization-wide records. Record any access refusal or consumer mismatch with the exact record identity. No new provider, payment, physical-device or live-tenant action was performed for this adaptation.