Skip to main content

​
After this article

  • You’ll know which Lumos objects to reassign before the admin’s last day, and how.
  • You’ll know which integrations break when their account is deactivated.
  • You’ll know what deactivation does not revoke on its own.

​
Overview

Deactivating the identity is the straightforward part. The risk is everything that still points at the departing admin: apps they administer, approvals routed to them, Access Reviews they own, and integrations authorized under their account. None of it moves automatically. Work through this article before their last day.

​
Before their last day

  • Confirm that at least one other active Lumos Admin exists, so nobody is locked out of the domain.
  • Decide who inherits each object below. Their manager is a reasonable default, if that person is staying.
  • If there’s no successor yet, add a second active owner now. Remove the departing admin once the successor is decided.
  • If the admin and their manager are both leaving, pick a fallback owner. Otherwise, any “transfer to manager” step breaks.

​
Reassign the objects they own

The Find and Reassign lines below are prompts for Albus. Paste them in and replace the bracketed placeholders with real values. If the admin owned more than a handful of objects, start with the sweep in Reassign at volume.

​
App Admins

If you skip this step, app configuration and manual removal tasks stay with someone who has left.
  • Find: List every app where [departing admin email] is the only app admin, then list the apps where they are one of several.
  • Reassign: Replace [departing admin email] with [new owner email] as app admin on these apps: [paste the list].

​
Approvers

If you skip this step, AppStore requests stall with an inactive approver.
  • Find: List every app and permission where [departing admin email] is the only approver, then list the ones where they are one of several.
  • Reassign: Replace [departing admin email] with [new approver email] as approver on these apps and permissions: [paste the list].
An approver can be set on a single permission instead of the whole app, so an app-level check alone misses them.

​
Policy owners

If you skip this step, Access Policies have no accountable owner at audit time. Owners are set on the policy itself, not on a version. You can reassign a published policy’s owners without creating a draft. To change the owners of one policy from the list:
  1. Go to Access Policies.
  2. Click the owner avatars in the “Policy Owner” column.
  3. Add the new owner, remove the departing admin, and confirm. The change saves immediately.
To change the owners of several policies at once:
  1. On the Access Policies list, select the checkbox next to each policy.
  2. Click “Assign Owners”.
You can also open a policy and click the owner avatars in the header. This route stages the change on the form. It doesn’t take effect until you click “Save”. If the owner avatars aren’t clickable, you don’t have permission to manage owners on that policy. Ask an Admin to make the change or to grant you the permission.

​
Access Review owners and reviewers

If you skip this step, reviews can’t be closed and their assigned items stall. Albus can’t take action on Access Reviews. Use the API or the UI, before the account is deactivated.
  • List the reviews: GET https://api.lumos.com/access_reviews. Results are paginated, 50 per page by default and capped at 100, so a large domain won’t return in one call. See List Access Reviews in the Lumos API reference.
  • Change the owner: PATCH https://api.lumos.com/access_reviews/{access_review_id} with a new owner_id. The owner_id is a user UUID, not an email. You can edit top-level fields on any review that isn’t COMPLETED yet. The caller needs the Access Review Administrator or App Admin role, or the call returns 403. See Update Access Review in the Lumos API reference.
  • Move their review items: Owner and reviewer are separate, so changing the owner leaves the departing admin’s review items in place. Find them with GET /tasks?product_area=ACCESS_REVIEWS&status=PENDING&assigned_identity_ids={user_id}. Add show_all_tasks=true to see beyond your own queue. Then move them with POST /tasks/{task_id}/reassign, or reassign them in Access Reviews.

​
Reassign at volume

One sweep is faster than checking each object type in turn. Ask Albus: Show me everywhere [departing admin email] is set as an owner, admin, or approver in Lumos, grouped by object type, and flag which ones have no other active owner. If any apps use a group as the App Admin or approver, follow up with: List out any groups that have app admin or approval configuration where [departing admin email] is the only member. The second prompt matters because the app points at a group, not a person, so the departing admin never appears in the first sweep. Neither prompt covers Access Reviews or Access Policies. Handle those in the UI. Read the list back before you confirm any reassignment, and expect the right successor to differ by app. The inactive-approvers skill runs the same sweep, but it only finds people after their account is deactivated. Use it as a backstop, and run it quarterly.

​
Check the integrations they connected

Integrations differ, so check each one instead of assuming:
  • Bound to the connecting user: Salesforce grants the scopes of whoever connected it.
  • Bound to nobody: Microsoft 365 and Entra ID use the Client Credentials Flow, so a service account isn’t needed for stability.
Lumos doesn’t show who connected an integration, and you don’t need to know. Reconnect anything user-bound with a dedicated service account, and the next departure skips this step. Find the app’s card in your Lumos integrations and choose “Reconnect”. Slack needs an extra step: revoke the old OAuth token in Slack first, or Slack won’t request the new scopes.

​
Revoke what deactivation does not

Deactivation doesn’t revoke personal API tokens, OAuth grants, or service accounts held by the individual. Go to Settings → API Tokens. Click any token to see Generated By and Date Created.
  • Note every token the admin generated. Tokens are labeled API or Agent.
  • Don’t delete tokens first. Most of them run live integrations.
  • Create a replacement under a service account, update whatever consumes the token, confirm that it works, and then delete the old one.
  • Follow up on any token with no known consumer while the admin is still there to ask.
For OAuth grants, ask Albus: Look up OAuth grants against the identity [departing admin email]. For service accounts, ask Albus: List any personally held service accounts that [departing admin email] has. This finds accounts tied to their identity. A service account under its own name and address, with no owner recorded against it, doesn’t surface this way. To catch those, you need an inventory that assigns every service account a human owner. The Lumos NHI Inventory, in beta, does this. Contact your Lumos CSM for more information.

​
Clear their queue

  • Reassign any pending, accepted, or blocked Task Center tasks.
  • Confirm that every app they alone covered for manual removal has an active owner and a backup.
For a long notice period, delegate their work instead of reassigning tasks one at a time:
  1. Go to Settings → Lumos Members.
  2. Find the departing admin and choose “Add Delegation”.
  3. Set a date range, or leave it indefinite.
  4. Pick who receives the work.
The Delegation Status column shows who currently has a delegation. Delegation has two limits. Its scope is fixed to all Task Center tasks, and it moves the work, not the ownership. The departing admin stays the owner of record until you reassign their objects.

​
Tell your Lumos CSM

Tell your CSM who is leaving and who is taking over, so Lumos can update your named contacts.

​
After the admin leaves

Check that nothing still points at the departing admin. It’s faster to catch now than at your next Access Review. Then make the next departure smaller. Set App Admins and approvers as groups instead of named individuals. When someone leaves, the group membership changes and no object is left without an owner. See Lumos AppStore Quick Start Guide.

​
Need help?

If you have questions, contact your Lumos administrator or support@lumos.com.