AndyM.92578 (Customer) asked a question.
Removing group memberships from all deactivated user accounts
Objective: Remove group memberships from all deactivated users (800 accounts, some of which were deactivated one year ago)
My thinking:
- Workflow 1, searches for users with the DEPROVISIONED status and updates my Okta table
- Workflow 2, searches the table and sends the User ID to Workflow 3
- Workflow 3, gets the group memberships for each user ID and triggers Workflow 4 - Is it possible to push both User ID and group ID to Workflow 4?
- Workflow 4, removes group memberships for each user ID and group ID
Below is the Okta table with the following columns UserID and login.
Sample data
The Workflow successfully searches the rows and returns the UserID, however, the for each loop fails. I have attempted to change the values, parse data etc without success.
My flow
Error
Greatly appreciate any suggestions / input regarding my thoughts on how to achieve the objective
@AndyM.92578 (Customer)
This is really a two part use case.
Use case (1) is your baseline. That is basically what you are discussing above. It only needs to occur once to set your baseline. Use case (2) below would be your "going forward".
The following Video shows you how to setup Streaming Actions. And actually covers the group removal portions of your use case.
https://support.okta.com/help/s/article/How-to-use-Streaming-Action-cards-in-Okta-Workflows?language=en_US
So essentially for your first use case you would want this:
1) A flow containing Clear Table & List Users With Search set to a status of "Deactivated". This would be Streamed to a Helper flow.
2) The Helper flow that creates a row within the table with each user. I would recommend something like Okta User ID , Login or Email as the columns to make it easy to track people. But include what ever you want.
3) A Flow that Searches the table and returns all results. This would Feed to a Helper flow that is the "Parent" flow in the example video I provided. (This flow will be re-used for use case 2). It really only needs to include the okta ID which is the required input for the groups search. But it is fine if it is an object containing multiple values you will just need to account for it in the Helper.
4) The flows outlined in the provided video link to finish off your use case.
Use case (2). This would be an Event Driven use case going forward. So when a user is brought into a deactivated/deprovisioned state an Event from Okta would be delivered to Workflows invoking the flow. You would then pull the user ID out of the payload. You would want to likely create an Object with the same name as the Object being fed into Step 3 above so you can re-use Step 3 and Step 4 flows to process the ID, find the groups, remove the groups. This would use a "Call Flow" card to call the helper.
Note: In reality the "Adding to Table, Searching Table" is typically not something that is required. This could be accomplished with streaming all found users to the group find flow. However since it is basically a foreach into a foreach it could be a heavy load if done this way. Using the table and passing into a "For Each" allows you to control the concurrency and leaving it at the default of (1) will remove problems like running into Rate Limits removing 800 users from X number of groups in a really short amount of time.
I went ahead and attached a simple flopack (2 flow) + 1 table that functions fine. It also has some notes for user case (2) described above.
tabletoforeach