# Companion-video brief — Give a colleague the right access

Use [the Markdown course](../appmint-roles-groups-and-permissions.md) as the narration source. The current recording reference is local Studio Manager0.6.2, own Copper Kettle organisation, owner Ada Okafor and colleagues Nora Ellis and Maya Ito. Capture real interactions in separate owner and colleague browser profiles. Keep the identity in frame when switching between them.

**Review status:** the required role/group, invitation, allowed edit, visible Delete refusal, website approval/revocation, direct-role recovery and maintenance screens have now been exercised locally. The server Delete defect and browser error-handling defect were repaired and retested. Effective-role-holder display also passed after reload. Account-departure guidance is the remaining course audit item.

## Story and pace

The business needs someone to follow up enquiries. Show the intended job first: read, create and update leads, without administering the company. Build the role, put it in Sales, invite a named colleague, then test both a permitted task and a refusal. Extend the story with a website request and remove that extra grant again.

Use a short outcome-led opening, then five chapters: **Define the job**, **Invite the colleague**, **Test actual work**, **Approve an extra responsibility**, and **Take access back**. Let each saved result remain visible long enough to read. Use close-ups for fields and permission checkboxes; retain the section label so viewers know where they are.

## Recorded stills and motion to capture

All numbered references below are PNG/TXT pairs in [local roles evidence](../../application-fixes/assets/local-roles/). These are actual screenshots. They are not existing video clips; record motion from the same application actions when producing the video.

| Scene | Evidence | Motion and explanation |
| --- | --- | --- |
| Choose the job | 02-role-ready | Show Read/Create/Update selected, Delete clear; explain the specific work this grants. |
| Select the screen | 02–03 | Appmint → CRM → Leads; keep the route and menu summary in frame, then save and reopen. |
| Make a job group | 04-sales-ready,14-group-description-fixed | Sales grants LeadEditor. Show saved description and distinguish group membership from role definition. |
| Separate website responsibility | 06–07 | Website Editors grants Publisher. Explain that Publisher is broader and includes Delete. |
| Existing-person membership | 09–11 | Select person → Add1 → Save group → reload; remove the rehearsal membership. Owner access is not a restriction test. |
| Invite | 22-nora-sales-only-invitation | Fill identity, select Sales only, review the personal message, send once. |
| Verify sent state | 23-invitation-immediate-refreshed-date | Pending row, group, sent date and expiry. Explain queued mail rather than pressing Send repeatedly. |
| Colleague signup | 24-nora-acceptance-ready | Actual private invitation → first/last name, password and confirmation → Create my account. Mask password and address-bar token. |
| First session and tour | 25-nora-inherited-role-after-signup | Nora identity and LeadEditor; acknowledge44-stop tour, then End to continue this focused lesson. |
| Open the right pipeline | 26-nora-leads-access | Expand sidebar → CRM → Leads → Show Pipelines. Empty Unassigned Leads does not mean no records exist. |
| Verify a real save | 32–33,37 | Reversible title edit, Update Lead and readback. The older capture needed reload because of the stale-detail defect; use capture50 for the repaired immediate readback. Restore the original title afterwards. |
| Refused screen | 38–39 | Open the owner-shared role administration/editor address as Nora; show the actual refusal. |
| Request | 40–41 | State the task in Ask for access, submit once, show owner named in Request sent. |
| Owner decision | 42–44 | Waiting on you → request → Grant through Website Editors → Approve → Decided. Explain why this group matches website work. |
| Reauthenticate | 45–46 | Fresh colleague session, combined LeadEditor/Publisher, same editor now accessible. No page save is needed to prove this screen grant. |
| Revoke extra responsibility | 47–49 | Owner removes Website Editors membership, saves/reloads; new colleague session again refuses the same editor. |
| Direct versus inherited | 27–31 | Nora has Sales but no direct roles. Maya's old direct User is removed with confirmation; Sales remains after reload. |

## Graphics

Use one simple diagram: **Role → Group → Colleague**, with labels **actions and screens**, **job membership**, **combined access**. Beside the colleague, show two separate checks: **open the screen** and **perform the operation**. Use capture55 for the actual refused Delete, with the retained lead visible behind the confirmation.

For the approval chapter, show **request → owner selects matching group → new session → verify task**. For removal, reverse the membership arrow and show a new sign-in. Do not imply that removing one group disables the entire account or instantly invalidates every older token.

## Final verified shots

| Scene | Evidence | Result |
| --- | --- | --- |
| Repaired immediate edit | 50-repaired-immediate-edit-readback | New title appears in the open detail view after Update Lead. |
| Refused Delete | 55-delete-refusal-visible-and-record-retained | Forbidden remains visible in the confirmation; record remains on screen. |
| Recovered colleague | 53–54 | Maya's fresh session inherits Sales/LeadEditor only and opens Leads. |
| Recognise devices | 57-device-management-readonly | User, browser, status and last-seen rows; no trust/block mutation. |
| Cards introduction | 58-access-cards-readonly | NFC staff badge entry and zero-card state; no card issued. |
| Password policy | 59-password-policy-readonly | Policy table; no policy created or changed. |
| Approvals reload | 60-approvals-correct-route-reloaded | Correct Studio route and Decided record survive reload. |
| Owner cleanup | 61–62 | Only the disposable probe deleted by owner; original two enquiries remain. |
| Effective role holders | 63–64 | LeadEditor shows Maya and Nora, two people inheriting the role through Sales; reload preserves both. |

Record motion for these actions when producing the video. The evidence currently consists of stills and request/readback records; no finished video is being claimed. Retest with a new disposable record if filming repeats the sequence, since the recorded probe has been cleaned up.

## Evidence and privacy

The first Permissions Practice lead was genuinely deleted because the server failed to enforce its missing Delete permission. Captures34–36 belong in the repair evidence, not as a successful restriction demonstration. Keep them available for an optional troubleshooting insert only after explaining the defect and its repair.

Do not reveal passwords, invitation tokens, session tokens, API keys, authenticator secrets or recovery codes. The local SMTP inbox contains private invitation links and is not an instructional screenshot source. Use the real pending invitation's Copy Link action privately. Show the learner's normal Studio entry in narration; localhost is the recording environment, not their destination.

Use fresh motion from this workflow. Do not substitute a production clip or another organisation's page for the recorded local result. Earlier17September footage and screenshots are historical research, not the current sequence.

## Final fixture checks

After filming, leave the agreed staff job in place: Sales contains the intended tutorial colleagues, and Website Editors has no temporary member after its revocation exercise. Maya's historical direct User is removed; owner administrator memberships remain. Restore any reversible lead edit. Remove disposable test leads only through an authorised owner action after recording the restricted refusal. No website content, device trust, access card or password policy should be changed merely for an illustrative shot.

Deliver the chapter recordings, edited video, transcript/captions, chapter timestamps and stills with a shot ledger. This brief provides production instructions and actual still references; it does not claim that new video files have been recorded.

## Account lock and recovery chapter

Use68for named confirmation,72for actual refused fresh sign-in,80–81for Locked row/active4of5 and full reload, then82for restored active5of5. Explain that groups remain unchanged. Use89for the fresh colleague’s original lead cards after unlocking. Do not use75as sign-in proof: it only shows a loading screen. Capture88is a diagnostic wide-pipeline frame;89is the readable finished shot.

For an optional connection-recovery insert,86shows the visible stale-data warning and87the unavailable initial load. These failures were deliberately induced by aborting the local pipeline request; label the rehearsal accordingly. Restore the connection, press the top Refresh control, and show89. Do not present fabricated responses or create duplicate leads for the shot. Phone-provider token and ongoing-call termination remain outside the demonstrated account-lock result.