Skip to main content
After this article
  • You will understand how Lumos determines account status when data comes from multiple sources.
  • You will understand why certain accounts may appear in inactivity workflow notifications unexpectedly.
  • You will know how to prevent stale account data from causing incorrect inactivity alerts.

​
Overview

Lumos inactivity workflows enable you to identify and act on user accounts in connected applications that have not been used recently. When an account’s last login date exceeds the inactivity threshold you have configured, Lumos notifies the designated reviewer to take action (typically to remove or reassign the license). Occasionally, customers are surprised to see specific accounts included in inactivity notifications - especially accounts they believe are already suspended or deprovisioned. This is almost always related to how Lumos coalesces account status when an account has data from multiple sources.

​
How Lumos Determines Account Status

When a user’s account in an application is tracked by more than one data source (for example, Okta and a manual CSV upload), Lumos combines those records into a single account view. To determine the account’s overall status, Lumos uses a priority-based coalescing rule - it picks the “most active” status from all sources. The priority order is:
  1. ACTIVE (highest precedence)
  2. ACCESS_CREATED
  3. STAGED
  4. ARCHIVED
  5. SUSPENDED
  6. DEPROVISIONED
  7. ACCESS_REMOVED
  8. Other statuses
This means: if any source shows the account as ACTIVE, the account will be treated as ACTIVE in Lumos - even if another source (such as Okta) shows the account as SUSPENDED.

​
Why This Can Cause Unexpected Behavior

A common scenario that causes confusion:
  1. An account is synced from Okta and shows as SUSPENDED (the employee was suspended in Okta).
  2. The same account was also imported via a CSV upload, and that record shows as ACTIVE (because the CSV was uploaded before the suspension and was never updated).
  3. Lumos coalesces the two records and shows the account as ACTIVE, because ACTIVE takes precedence over SUSPENDED.
  4. The inactivity workflow uses the account’s last login timestamp (which came from Okta) and the account’s status (ACTIVE, coalesced from the CSV). Because the account appears active and the login is stale, the workflow triggers a notification.

​
How to Prevent This

​
Keep CSV-Uploaded Accounts Up to Date

If you use manual CSV uploads to supplement your Okta or other IdP data, ensure those uploads reflect the current state of accounts. Stale CSV data showing accounts as ACTIVE can override suspension and deprovisioning signals from your IdP. Best practice: Re-upload your CSV data whenever the underlying access changes, or remove manual account imports for applications that are fully managed through an integrated IdP.

​
Use the “Ignore” Feature for Known Exceptions

If a specific account should never be included in inactivity workflow processing, you can mark it as Ignored in the Lumos account view. Ignored accounts are excluded from inactivity workflow evaluations. To ignore an account:
  1. Navigate to the application in Lumos.
  2. Find the account under the Users or Accounts tab.
  3. Click the account and use the Ignore option.
Note: Be aware that ignored accounts remain in scope for other Lumos features. Only use this for accounts you are certain should be permanently excluded from workflow processing.

​
Need Help?

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