How to use ServiceNow as frontend with Okta Workflows

How to use ServiceNow as frontend with Okta Workflows

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.

Andreas is a cloud architect in Cloudworks and an Okta Technical Champion. He is helping customers on their digital Identity journey by designing and implementing complex IAM solutions. These have a high amount of automation to achieve high impact with minimal user friction.

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.

WORKFLOW 1

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.

Trigger workflow

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:

Okta Connector ServiceNow

Figure 2 -Detail: Text compose and filling incident description

WORKFLOW 2

Update Okta user after approval in ServiceNow

Okta tasks

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.

Updated Incudent

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:

Okta tasks

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:

Incidents

Figure 6 - Close ServiceNow incident

Conclusion

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.