In many organizations, access tends to proliferate for far longer than certain users require it. Maybe you’re working with a contractor who needs access to a single app, or offboarding policies break down for an ex-employee. All of a sudden, you realize that the user hasn’t logged in for months, and as part of a strong security posture, would like to suspend them until you’re notified that they do actually need access.
This flow reads all active users in your environment, and if they haven’t logged in within the past 6 months (180 days), suspends them.
Before you get started, you will need:
- Access to an Okta tenant with Okta Workflows enabled for your org
- Active users
- One of the active users needs to have not logged in for the past 180 days; if you don’t have a user with “inactivity”, you can simply edit the flow for a different date range (eg 5 minutes for a recently created user)
- Select the parent flow titled “Inactivity-based Suspension - Parent Flow”
- Make sure a connection is selected for the “List Users with Filter” card.
- The only input should be Status, with “Active” selected as the value.
- Open the child flow, “Inactivity-based Suspension - Child Flow” in a new tab. 3. Scroll to the right, and make sure a connection is selected for “Okta - Suspend User”.
- Turn both the parent and child flow on.
- Go to the parent flow, and click Test Flow in the toolbar.
- Click Flow History and make sure everything succeeded.
- Go to the child flow and select Flow History. You should see an execution for each user in your org.
- For those Okta users that you expected to be suspended (e.g. they hadn’t logged in for longer than 180 days), go to your Okta console and confirm that they are suspended.
- If you have a user that has never logged in (LastLogin = null), then the flow will fail. If you’d like to skip errors, you can replace the “List For Each” with “List For Each - Ignore Errors”.
- If you have a large number of users (50k+), we’d highly recommend breaking your List Users call into multiple groups of users. That could be individual Groups (using List Group Members), or based on some type of unique category (like their office location).