Passing ServiceNow ticket number from one workflow to another

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

As of our current state, Sailpoint handles many of the sources that can be directly connected. ServiceNow handles applications that have not been onboarded yet into Sailpoint and hardware provisioning. All accounts created in Sailpoint and all access granted or removed in Sailpoint, must be written to ServiceNow.

We have been given a process from Sailpoint Professional Service to create the REQ ticket in ServiceNow and then update that ticket via another workflow triggered on Provisioning Completed.

Leaver Process:

1. The user is aggregated from the HR source of truth hourly.

2.     If their HR status changes from Active to Inactive,
       change their LifecycleState to Inactive

3.        Sailpoint ISC triggers a Leaver workflow based on
          LifecycleState change

4.           Leaver workflow opens a ticket (REQ) in ServiceNow to initiate
             offboarding process in ServiceNow.

5.        Simultaneous, Sailpoint ISC begin disabling account in Sailpoint
          using the Identity Profile.

6.           When an account has been disabled, a workflow is called to
             create a CTask on ServiceNow

7.              The workflow is triggered by the Provisioning Completed
                trigger.

8.                  A CTask is created on ServiceNow under the REQ ticket
                    created in Step 4.

How do I pass the REQ ticket generated in Step 4 to the Provisioning Completed workflow, Step 7?

2

Hi @Chris_Hull4 welcome back

You can’t “pass” variables between two independent ISC workflows unless you persist them somewhere.

For your flow, the simplest approach is:

Leaver workflow: create the SNOW REQ → immediately Patch Identity (or another durable store) with the REQ number (e.g., snowOffboardingReq).

Provisioning Completed workflow: use $.trigger.recipient.id to read the Identity, fetch snowOffboardingReq, then create the CTask under that REQ, and finally clear the attribute so you don’t reuse an old REQ.

If you want a cleaner design, store the correlation on the REQ itself in ServiceNow (e.g., u_sailpoint_identity_id) and have the Provisioning Completed workflow query ServiceNow for the correct REQ before creating the CTask.

External Trigger chaining is great for “call another workflow now,” but your trigger is time-delayed, so persistence/correlation is the key.

1 Like
3

Thank you. I think this what I needed.

We would have liked to have chained the workflows together but since they are independent, we needed a way to persist the REQ ticket number.

4

Glad that helped, Chris. One nuance worth calling out: in ISC there isn’t a public “PATCH identity” style endpoint/action for updating arbitrary identity attribute values the way we’d do in other platforms—Identity APIs here are primarily read-oriented (GET) for the identity object.

So in practice, the most reliable persistence pattern is exactly what you said: persist the REQ correlation in ServiceNow (since SNOW is already the process system of record for your offboarding), then have the Provisioning Completed workflow look it up.

Recommended pattern (robust + avoids collisions):

  1. When you create the REQ, store correlation fields on the REQ (custom fields):
    • u_sailpoint_identity_id = ISC identity id
    • u_offboarding_event_id = a unique value for this leaver event (e.g., workflowExecutionId or lifecycle-change timestamp)

  2. In the Provisioning Completed workflow, use $.trigger.recipient.id to query SNOW for the latest open REQ for that identity + event id, then create the CTask under that REQ.

  3. Add idempotency so you don’t create duplicate CTasks (Provisioning Completed can fire multiple times): use a deterministic u_correlation_id on the CTask like {identityId}:{accountId}:{operation}:{eventId} and “check-before-create”.

If you ever decide you do want true chaining, the supported way is to have Workflow A call Workflow B via the External Trigger execute endpoint and pass the REQ number as input—but that means Workflow B can’t be purely “Provisioning Completed triggered” anymore.

5

I am looking for a way to persist the REQ number in Sailpoint. I was looking for the PATCH Identity API where I could update Identity attribute, adding the REQ number to snowOffboardingReq. I could not find any documentation on it.

I found put-identity-attribute | SailPoint Developer Community where it looks like I could update an identity attribute. Or possibly use the PATCH Update account update-account | SailPoint Developer Community and update the Sailpoint ISC account that every user has.

6

You won’t find a “PATCH identity attribute value” API in ISC. The PUT /identity-attributes/:name endpoint is for the attribute definition, not setting a value on a specific identity.

Also PATCH /accounts/:id won’t work as a general storage mechanism because attributes are only patchable for flat-file accounts.

Practical pattern: write the correlation to the ServiceNow REQ (ex: u_sailpoint_identity_id + u_offboarding_event_id). Then in the Provisioning Completed workflow, query SNOW using $.trigger.recipient.id (+ event id), get the right REQ, and create the CTask under it. Add idempotency (check-before-create) since Provisioning Completed can fire more than once.