Grant a person access to a new app

When to use

A person needs access to an app — new to the company or new to them. Not for removing access when someone leaves — use people.offboard-employee, which consumes this register. Not for a company-wide security review of who has what — use tech.security-audit. Not for rotating the credentials of an account that already exists — use tech.password-rotation.

Before you start

• The person and the purpose are named. "We might need it" is not a request.
• The access level is proposed by the requester, not assumed; admin is a separate decision.
• It is known whether the app is already used in the company (check the access register first) —

What a run requires3

The trail8 steps

1. S1

   Check what already existsagent

   Read the access register for the app: is it used, on which plan, who is admin, what does it cost? Search the company mailbox for the app's domain to catch unrecorded accounts.

   Done when the register state for this app is written down, including "not used — nothing found".

2. S2

   Confirm the minimum accessagent

   Map the request to the app's actual roles. Note what the requested role can do that the next-lower role cannot.

   Done when a one-line recommendation exists: role, plan, cost per month, why.

3. S3

   Decideownerneeds approval · owner

   Approval · S3 · owner — the run stops until a named person records the decision

   Present the recommendation from S2.

   Done when the owner has named the person, the role and the plan (or declined, which ends the run).

4. S4

   Create the accountagentneeds approval · ownerirreversible

   Approval · S4 · owner — the run stops until a named person records the decision

   Irreversible · S4 — an agent never closes it alone

   Sign up with the company e-mail — never a personal address. Prefer SSO through the company identity provider if the app offers it; otherwise set the initial password and store it in the company password manager (paroles), shared with the owner, not the person's private store.

   Done when the app shows the account with the company e-mail as its identity.

   ⛔ Never start a paid trial or plan with a personal card or a personal e-mail — the company cannot recover the account or the data later.

5. S5

   Set the role and turn on MFAagent

   Assign exactly the role approved in S3 — not the app's default, which is often admin. Enrol MFA (authenticator app, not SMS where the app offers a choice).

   Done when the app's admin panel shows the role, and MFA shows as enabled for the account.

6. S6

   Verify by logging inagent

   Log in as the new account from a clean session: sign-in works, MFA prompt appears, the role's permissions are visible (e.g. the editor sees edit buttons, the viewer does not).

   Done when one working login is demonstrated, not assumed.

7. S7

   Recordagent

   Add the row to the access register: app, person, role, plan, cost per month, account owner (who approves changes), date. If the app is new to the company, add the renewal/contract date to ops.contract-renewal-watch.

   Done when the row exists and the register's total monthly cost is updated.

8. S8

   Hand backagent

   Send the requester a three-line summary: how to log in (SSO or password manager entry), what they can do, who to ask for more access.

   Done when the person confirms they are in.

Checks — how we know it worked

• The account's identity is the company e-mail, read back from the app's profile page — not from memory.
• Role in the app's admin panel = the role approved in S3.
• MFA shows enabled in the app's security settings.
• The register row exists and names an owner; a run without the row is incomplete.

If it goes wrong

What each step leaves behind

1. S1the register state for this app is written down, including "not used — nothing found".
2. S2a one-line recommendation exists: role, plan, cost per month, why.
3. S3the owner has named the person, the role and the plan (or declined, which ends the run).
4. S4the app shows the account with the company e-mail as its identity.
5. S5the app's admin panel shows the role, and MFA shows as enabled for the account.
6. S6one working login is demonstrated, not assumed.
7. S7the row exists and the register's total monthly cost is updated.
8. S8the person confirms they are in.

Evidence to keep

The owner's decision in S3 (who, when, what was approved) · the account's identity e-mail and role as shown by the app · a screenshot of the MFA-enabled state · the register row id · the plan price at start, so later price changes are detectable.

How this playbook improves

After every 10 runs ask: how long from ask to working login, and which step waited? Did any account later turn up without a register row, or with a role higher than approved? Did any paid plan start without an S3 approval? A new version changes the step that caused the wait or the miss, and says so in its change note.