MorganW.24067 (Flosports) asked a question.
Hi all, I am a new okta admin as our previous okta admin is no longer with the company. I recently integrated a third party app with Okta, and have it set up with automatic provisioning to the app upon okta account creation. There's an attribute at the group level that sets to true upon account creation. This sends the user an invite that expires within 7 days. I would like to setup either a workflow, or some sort of automation to keep the attribute at false until the okta account gets moved from Staged to Active. Once the account is moved to Active, an automation rule will then set the boolean to true and thus send the invitation to the user. To clarify, I want the account to provision (ideally), but I want for the attribute to be false until the account moves to Active. Let me know if you have any questions or ideas!
Hi @MorganW.24067 (Flosports) , Thank you for reaching out to the Okta Community!
Depending on the app's requirements and if you can initially provision users with the attribute set to "false", you might then be able to leverage Workflows to monitor events and to trigger an attribute change on user status change, but there are a lot of things to consider. For example: do you have a preview environment to test, is this for all users or just some, is there a way to filter them, does this need to happen on a schedule or not, rate limits, etc.
For specifics, you might need to get help from Workflows specialists during weekly community office hours.
Or if you have an account with us, open a case to discuss the matter with our Okta Support team. That being said, design implementation might fall in the realm of Professional Services.
If my answer helped, remember to mark it as best to increase its visibility for other members of the Okta Community who might have the same questions as you.
Hope my answer helps!
--
Help others in the community by liking or hitting Select as Best if this response helped you.
Collect them all. Learn a new skill and earn a new Okta Learning badge.
This month's AMA topic: Okta Device Access. Ask away today.
@MorganW.24067 (Flosports) -- I'm not really sure what you mean by "There's an attribute at the group level that sets to true upon account creation.". Is this group attribute in Okta or in the Third-Party application? This part really doesn't make much sense to me.
However, from a Workflows perspective:
Okta Workflows has 5 total methods to Invoke an execution of the flow. Other than manual all of them are in the "Event" slot at the start of a flow:
The "Vendor" based cards that can be assigned to the "Event" slot are combinations of either: (Scheduled + An API call to pull specific information on that schedule) or (An API endpoint listener + an API call to the vendor service to setup a web/event hook pointing to the API endpoint address)
What this means is in Okta there are a large number of event-hook-eligible events that can be configured to "listen" for these event types. When the event fires the payload of that event will be written to the Okta System log && Delivered to the HTTP address defined during the Event Hook setup. A list of all eligible events can be found here:
https://developer.okta.com/docs/reference/api/event-types/#catalog
In your scenario "user.lifecycle.activate" is the event that occurs when a user in Okta is activated. Meaning you can use an Event Hook to invoke a flow execution to perform the actions you want.
What I suggest when "learning" Workflows and building out a flow to perform an action is to first confirm there is "automation" available. But to build the flow out in such a way you can run it manually for your initial build/testing. I typically do this by leveraging an "Assign" card which allows you to set variables. Here is an example of what I mean:
In the following flow I "Know" the only input I need to dynamically populate everything else is the user's Okta Id (Everything else is static). So I created an Assign card to hold the user's Okta Id that I can manually populate for initial testing. I can then build out the rest of the flow manually running it for initial testing. Once I know everything works I can Add in an "Event" card to the left of the Assign card and pull out the User's Okta ID from the event and pass it into the Assign card's input replacing what I had previously manually typed in making the entire flow dynamic.