AndrewM.58865 (Customer) asked a question.
Looking to tap into the brilliant minds on here.
We've created a workflow that begins with the "User Assigned to Application" event trigger. We realized that if we assign a group containing thousands of users to an app it gets rate limited. What would be the best way to approach this?
Thanks
We use cookies to provide the best website experience and to help understand marketing efforts. We may also share data with ad partners to reach potential customers across the web. To learn more, visit our Privacy Policy. Click here for Your Privacy Choices. You may also opt out of this sharing by signaling your preference via GPC, applicable only to the browser signaling the opt-out.
More information
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.
These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.
Select All
We use cookies to provide the best website experience and to help understand marketing efforts. We may also share data with ad partners to reach potential customers across the web. To learn more, visit our Privacy Policy. Click here for Your Privacy Choices. You may also opt out of this sharing by signaling your preference via GPC, applicable only to the browser signaling the opt-out.
More information
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.
These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.
Select All
Here is one approach. Try adding a combination of a "Random Integer" function and a "Wait For" function - have the random integer function pick a random number, then use that in the Wait For function to delay the flow for a few minutes at random (or whatever delay you need for the rate limits they're hitting). Let me know if this helps.
@AndrewM.58865 (Customer) @MaxKatz (Okta)
As it is currently implemented Max's suggestion will likely have unexpected behaviors due to how Event Hook payload delivery's work. To give some technical details:
Event Hook Payload deliveries come in an array called "Events". This occurs because "IF" the same event occurs more than once in a short period of time they can be grouped (batched) into a single array for a single payload delivery to the defined event hook destination.
Workflows (Okta) Event cards are made up of 2 parts. The first part occurs on Flow "Enable/Disable" which sends an API call to Okta core to setup an event hook (or remove it on disable). The second part is the card is an API Endpoint that receives JSON payloads (Specifically from the event hook defined in the first part).
The "batched" events as described above are processed in series in the backend (basically a For-Each). So until the first event completes the second one won't start and so on. When a wait is add this will be cumulative. So lets say the batch size was 50 and you add lets a 1 minute wait the 50th one won't even start processing until (processing time + 1 minute) X 49 has occurred. This can result in unexpected behavior.
The problem:
This scenario is very complicated because the batch sizes are not controlled and if for example you were to add "thousands of users" this could result in 100's of unique deliveries of batched events. Which means you could run into the "invoke" limit for the endpoint which is 10 invocations (Flow execution starts) per second.
https://help.okta.com/wf/en-us/Content/Topics/Workflows/workflows-system-limits.htm
The next portion to consider are the rate limits for the individual API endpoints the flow is going to touch. The most important is going to be the endpoint you are touching that has the "lowest" rate limit (you may be touching multiple endpoints to perform a variety of tasks... and some have lower per minute limits than others).
The Solution:
There really isn't a good solution for this scenario.
The Okta Cards themselves do have "backoff / retry" logic built into them when a 423 (too many requests) rate limit is returned. What this means is the process will successfully work. It will just put the environment into a state where rate limits are exceeded for a period of time until everything is processed.
Another possible solution is based on the "Wait" like Max suggested. You can change the "User Assign to Application" event card to "List Mode" by clicking the "gear icon" on the card. In list mode the payload will be an array (list) of events. These can then be passed down into a Foreach card where you could then add a wait in an attempt to spread the processing out over a larger period of time to spread out the executions and prevent rate limits. So in a Scenario where this is a one-time run and you don't care if it takes a couple hours to complete the Helper flow target for the foreach could contain a "Wait 1 minute". And if the event batch is lets say 70 in size it would take 70+ minutes to churn through it. Keep in mind there will be multiple invokes of different batch sizes all running parallel As long as the total invokes does NOT exceed the rate limit maximum for that endpoint this should technically work (Example 400 batches with ave size of 50 = 20k users would only be hitting the endpoint 400 times a minute at maximum)
Hope this helps.