What to Do When a Lumos Admin Leaves Your Company

Last updated: September 1, 2026

After this article

  • You'll know which Lumos objects to reassign before their 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 easy part. The risk is everything still pointing at them: apps they administer, approvals routed to them, Access Reviews they own, integrations authorized under their account. None of it moves automatically. Work through this before their last day.

Before their last day

  • Confirm at least one other active Lumos Admin, 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.

  • No successor yet? Add a second active owner now and remove the departing admin once it's decided.

  • If the admin and their manager are both leaving, pick a fallback owner. Any "transfer to manager" step will break otherwise.

Reassign the objects they own

The Find and Reassign lines below are prompts for Albus. Paste them in, replacing the bracketed placeholders with real values.

If they owned more than a handful, start with the sweep at the end of this section.

AppAdmins

Skip it and app configuration and manual removal tasks sit with someone who is gone.

  • 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

Skip it and 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].

Approvers can sit on a single permission rather than the whole app, so an app-level check alone will miss them.

Policy Owners

Skip it and Access Policies have no accountable owner at audit. Owners sit on the policy itself rather than on a version, so a published policy's owners can be reassigned without creating a draft.

For 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, then confirm. This saves immediately.

For several at once:

  1. On the Access Policies list, tick the checkbox next to each policy. You can select several.

  2. Click Assign Owners...

You can also open a policy and click the owner avatars in the header. That route stages the change on the form—it does not 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 grant you the permission.

Access Review Owners and Reviewers

Skip it and reviews cannot be closed, and their assigned items stall.

Albus AI cannot action Access Reviews. Use the API or the UI, before the account is deactivated.

  • List them: GET https://api.lumos.com/access_reviews. Paginated, 50 per page by default and capped at 100, so a large domain will not come back in one call. See List Access Reviews.

  • Change the owner: PATCH https://api.lumos.com/access_reviews/{access_review_id} with a new owner_id, which is a user UUID rather than an email. Top-level fields are editable on any review not yet COMPLETED. The caller needs the Access Review Administrator or App Admin role, or it returns 403. See Update Access Review.

  • Owner and reviewer are separate. Changing the owner leaves their review items where they are. Find those with GET /tasks?product_area=ACCESS_REVIEWS&status=PENDING&assigned_identity_ids={user_id}, adding 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.

Doing this at volume

One sweep beats checking each 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 it with:

List out any groups that have app admin or approval configuration where [departing admin email] is the only member.

The second one matters because the app points at a group, not a name, so the departing admin never appears in the first sweep.

Neither covers Access Reviews or Access Policies. Handle those in the UI. Read the list back before confirming any reassignment, and expect the right successor to differ by app.

The inactive-approvers skill runs the same sweep, but only finds people once the account is deactivated. Useful as a backstop, and worth running quarterly regardless.

Check the integrations they connected

Integrations differ, so check rather than assume:

  • Bound to the connecting user: Salesforce grants the scopes of whoever connected it.

  • Bound to nobody: Microsoft 365/Entra ID uses Client Credentials Flow, so a service account isn't needed for stability.

Lumos does not 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 entirely. Find the app's card in your Lumos integrations and choose Reconnect.

Slack has an extra step: revoke the old OAuth token in Slack first, or it will not request the new scopes.

Revoke what deactivation does not

Deactivation does not touch personal API tokens, OAuth grants, or service accounts held by the individual.

Go to Settings, then API Tokens. Click any token to see Generated By and Date Created.

  • Note every token they generated. Tokens are labelled API or Agent.

  • Don't delete first. Most are running live integrations.

  • Create a replacement under a service account, update whatever consumes it, confirm it works, then delete the old one.

  • Chase anything with no known consumer while they're still here to ask.

For OAuth grants, ask Albus AI:

Look up OAuth grants against the identity [departing admin email].

For service accounts:

List any personally held service accounts that [departing admin email] has.

That finds accounts tied to their identity. A service account under its own name and address, with no owner recorded against it, will not surface this way. Catching those needs an inventory that assigns every service account a human owner. Lumos has an NHI Inventory in beta that does this. Reach out to your Lumos CSM if you want more information.

Clear their queue

  • Reassign any pending, accepted, or blocked Task Center tasks.

  • Confirm every app they solely covered for manual removal has an active owner and a backup.

For a long notice period, delegate instead of reassigning one at a time. Go to Settings, then Lumos Members, find them and choose Add Delegation. Set a date range or leave it indefinite, then pick who receives the work. The Delegation Status column shows who currently has one.

Two limits: scope is fixed to all Task Center tasks, and delegation moves the work, not the ownership. They stay the owner of record until you reassign.

Tell your Lumos CSM

Tell your CSM who is leaving and who is taking over, and we'll update your named contacts.

After

Check that nothing still points at them. Faster to catch now than at your next access review.

Then make the next departure smaller: set App Admins and Approvers as groups rather than named individuals, so a leaver changes who is in the group instead of leaving an object unowned. See the Lumos AppStore Quick Start Guide.

Need Help?

If you have any questions or need assistance, please contact your Lumos administrator or reach out to support@lumos.com.