In this article you will learn how to make ServiceNow the frontend of user interaction by building a workflow with the ServiceNow connector in Okta Workflows.
This is a technical description in a series on Okta Workflows
PART 2: OKTA WORKFLOWS AND CONNECTORS: EXAMPLE WITH SERVICENOW
In part 1 of our Okta Workflows article series, you will learn more about Okta Workflows and connectors for frontend. This section assumes that you have read this introduction to Connectors.
Below you will see how we build a workflow that is triggered by an Okta event → forwards information to an external system for user interaction → then continues in Okta after the request has been approved.
In our example we will have a very simple approval workflow after a user account has been created or a user has setup it up with self-service registration.
The goals are:
- After a user is created, they should not have any applications or accesses assigned.
- A ServiceNow incident should be created for approval with the Okta user information.
- The business owner then reviews the request and approves if everything is correct. Then the provisioning continues.
- Once the incident is approved, the user should automatically be assigned to the groups and applications in Okta.
Create incident in ServiceNow
In the following example, we have the trigger “user created” from the Okta tenant. It reads some additional user properties from the Okta user profile and composes this in a text and creates the incident in ServiceNow.
Figure 1 - Trigger workflowon user creation
We simply use the existing Okta Connector ServiceNow action to create the incident and fill the fields that are required in ServiceNow:
Figure 2 -Detail: Text compose and filling incident description
Update Okta user after approval in ServiceNow
Figure 3 - Full workflowpart 2, after the approval
Again, we use the standard ServiceNow connector to capture all incidents that have been changed and filter out if they are unrelated to Okta or not approved.
For additional improvements, we could also save the incident number of the incident that has been created in part 1 and save it in a table. Then we could use it here to make sure we are capturing only Okta-triggered incidents.
Figure 4 - Detail: Capture approval and filter out unrelated incidents
Once it is confirmed that the incident is approved, we can add the user to the required group, activate (if it hasn’t already) and assign apps to the user:
Figure 5 - Detail: Okta tasks
And lastly, because the incident in ServiceNow was just “resolved” but not closed and our tasks have been completed successfully, we can go ahead and mark the incident as completed (closed) in ServiceNow:
Figure 6 - Close ServiceNow incident
As mentioned, a variety of connectors and tools can be used in Okta Workflows. In this example we used the ServiceNow connector to create and retrieve incidents.
Like many tools, ServiceNow has a very powerful automation and workflow engine itself, so very often the design questions are what to use to fulfill the objectives.
There is no definite answer and it often depends on the environment, but the suggestion is to identify and use the strengths of each component.
Okta has a very neat, easy-to-use as well as easy-to-maintain configuration setup for workflows and connectors with a strong no-code approach. Therefore, there is no need to maintain API calls and settings in code, like other tools might have to do when calling the Okta API directly.