Follow the account from invitation to departure.

An account is more than an email address and a role. Plan who approves it, which systems it reaches and what evidence shows that later changes took effect.

Before an invitation leaves

Name the business sponsor and the administrator authorized to create access. Establish the intended recipient and organization through the approved process; a familiar display name is not enough. Decide the starting role, records it may reach and any time limit before issuing an invitation.

Record how an expired, canceled or misdirected invitation is handled. Explain whether a new invitation supersedes the old one and how the recipient gets help. Avoid copying invitation links or recovery material into ordinary project notes. Include separately provisioned applications in the inventory rather than assuming one sign-in creates every account.

During work and role changes

List concrete actions such as viewing assigned cases, editing drafts, approving exports and administering accounts. Identify the allowed record boundary and test a denied case too. Name who approves a new role and who removes the old permissions. A role change can require both actions.

Temporary delegation needs a reason, owner and review or end point. Keep responsibility for business records distinct from permission to sign in. Use the application-role guide to prepare examples for ordinary and restricted work.

Recovery without shared credentials

Agree how a legitimate user establishes identity after losing a factor or device and which authorized administrator can help. Describe the fallback before changing sign-in. Test it with suitable isolated accounts and harmless data; do not improvise by sharing another person's account or weakening permissions.

Document where approved recovery procedures live and how the responsible team is reached. Do not record actual secrets on this worksheet. A proposed recovery method still needs review against the provider and application that will implement it.

Departure and session review

List the identity-provider account, application accounts, active sessions, connected permissions and any delegated access requiring attention. Assign each action to an authorized owner. Consider who takes over records, scheduled work and integration administration so that removing personal access does not orphan business operations.

Disabling future sign-in and ending existing access are separate checks. Applications can maintain their own sessions, and provider behavior varies. For example, Microsoft's access-revocation guidance explains the need to account for application-controlled sessions. Use the documentation for the actual environment; do not assume immediate revocation everywhere.

Keep a compact decision record

For each system write: account or role reference without secrets, approving owner, intended action, isolated test, recovery fallback, expected result, observed result and unresolved dependency. Before a production change agree its exact scope, timing, stop conditions and administrative recovery route. Leave unverified actions visibly pending.

This is a planning aid and authorizes no account changes. Review SSO integration and team-access services or describe the account journey using a safe example.