One of the ways we test configurations in Okta is creating a group and adding folks to it. Usually after the first few folks have been added, we need to increase the group to a certain percentage of users before evaluating if the configuration is ready to be applied to everyone.
Sharding is the idea of deploying a change to a large group, but doing it in small chunks. This Okta Workflow set is a bit over engineered and there's definitely a few more ways to accomplish this. Hopefully this helps folks when figuring out how to deploy a change.
Using a config table (this is designed to be quickly templated), fill out test groups and group size limitation. Then a series of workflows pulls all active uses from a specific group. It adds a random number to each row to make picking fairly straight forward. Once that is complete, another workflow pulls users from the test group and subtracts them from the other group. This is all done in tables so you can see the progress. Once the setup work is done, a workflow runs that picks the first row from the active user group with that random number and adds it to the test group. Lastly, a bit of cleanup is done to make sure that user doesn't get picked again and to make sure the test group doesn't go over a certain number.
There are a few variables in these workflows that are designed to speed up or slow down group ads. For instance if you set the max size to 300, there will never be more than 300 users in the group. To expand testing, increase the max group size and the workflow gradually adds users,
Open the config table in the tables section of the folder.
- Difference : This was an attempt at doing some live math. I'm leaving that there for for now. One of the ideas I had with this was sending a notification such as "There are X number of people to add to the group".
- Group ID : Add the groupID of the group that is going to get the users
- Maximum Number : This is the max number of accounts in the group. Set this to whatever number you want.
- Current Number : This is the current number of people in the group. Leave this blank.
Each numbered section corresponds to the numbered workflow in the folder.
Enter a groupID for a group to get all active users from. Then point this to flow 2.
Make this group as narrow or wide as you want. Don't use everyone group as this will get service users. Some of the best are groups that combine multiple employment types or departments.
This flow runs on a timer every day. It could be adjusted if groups contents change rapidly. Our org does hires on a weekly basis and the flow takes a few minutes to run so this seemed like a good start.
This helper flow needs no configuration. This will take each userID and create a row in the "Active Users Pool" table along with a random number.
The random number generator is designed to get a 1 to 10. This could be adjusted to any number. Our goal for testing this was to get to 20% of all users.
This scheduled flow is scheduled to run daily, an hour after 1 - Get Active Okta Users. This flow is used to compare to the test group and get all users that are already in the test group removed.
This helper flow takes the userID and rowID and passes the RowID to a another helper flow that will remove accounts already in the test group from the available pool.
This helper flow removes accounts from the available account pool.
This scheduled flow gets all members of the test group and sends them to a helpfer flow to create.
Fill in the groupID for the group to get the members of.
This helper flow creates a table of all users in the test group.
This scheduled flow takes everything from the previous flows, picks random accounts, adds them to the test group and then updates the pool and testing tables so that the user isn't picked again. Additionally the userID is added to a slack channel with a custom message to the user.
Here's what that looks like and to configure:
Add the rowIDs from the configuration table that shows how many people are in the group, the max number of people to be in the group, and the groupID to look at for the test pool. Also, the flow will not continue if the maximum number is reached.
For this part of the flow, it will generate a random number, and find the first instance of that number in the pool table, call another helper flow to add the user to the group asynchronously, and updating the information in the config table.
For this part of the flow, compose a message to the user that will let them know what config they are becoming a part of. Additionally, the other sections here remove the user from the pool.
For this part of the flow, the userID is added to the row in the test pool table, and they are invited to a slack channel and sent a direct message.
This workflow is set to run every 5 minutes but could be run less frequently.
This helper flow can be called by these workflows asynchronously and does not need to be configured.
There are alot of improvements that could be made and some of the flows aren't really needed. For instance, the helper flows for generating the tables aren't really needed as a different flow could just add people from and active okta account group or something like that. If users are "readded" to a group, nothing happens but the would get a Slack notification more than once.