Periodic self-verification

@DanielM.86160 (Customer)​  - This is definitely something you could potentially handle with Workflows. If you wanted it to be "pretty" you might need to tie in a webserver or a "code" solution.

Here's the idea behind this: You would need to have some sort of profile attribute that you are maintaining such as "nextSuspendDate". When the user is unsuspended you would as part of the unsuspend update this value to some increment (90 days for example).

You could then leverage a Workflows API Endpoint flow which will have a URL to invoke the Workflow that looks something like this:

https://domain.workflows.okta.com/api/flo/dc560f1fdd4e40cf9f3dc4072600c871446d/invoke?clientToken=2faafc12907dd0f1fd961cf9f3dc4070f1fe6ed35ef155d71f67b68

You can then modify the URL (this could be done dynamically in a flow) to something like this:

https://domain.workflows.okta.com/api/flo/dc560f1fdd4e40cf9f3dc4072600c871446d/invoke?clientToken=2faafc12907dd0f1fd961cf9f3dc4070f1fe6ed35ef155d71f67b68&userName=exampleEmail@mydomain.com

When you go to this and invoke the flow it will now have 2 query objects that are delivered with their specific values.:

• clientToken
• userName

You could then create a HTML body email that contains this link and is delivered to the "suspended" user. When they click the link it opens a new webpage and invokes the flow and could return back a response like: {"Complete":"Your account is now reactivated."} using the API close card.

So to put this all together:

A Schedule flow that performs a "list users with search" against the nextSuspendDate runs daily and finds all users that need to be suspended. It then passes all found users into a helper. This flow generates an email for each user and sends them the link they can click to unsuspend themselves.

An API endpoint flow then receives the payload that contains their "user identifier such as email address" and runs the flow. This flow would then unsuspend them and update their nextSuspendDate to a later date to repeat the process.

Note: You would be better off using their "Okta Id" instead of the email address in the Invoke link. This would make it pretty impossible for them to manually send in unexpected content and make an action happen. Or you could send both and do a check when the payload is received and if they don't match (okta userId and email address) then stop the processing. Since there is no way for a user to tie those two together this would be pretty secure.

This is definitely a higher-complexity use case buildout. If you wanted it done for you I would suggest contacting your Okta sales rep and discussing a Professional Services engagement.