Identity Security Cloud Reassigning the Sponsor of a Non-Employee

The Problem

Non-employee (NE) profiles managed through the Non-Employee Risk Management module are each tied to a sponsor — typically the identity who requested or is accountable for that non-employee’s access. When a sponsor’s identity is deactivated (for example, the sponsor leaves the organization and their cloudLifecycleState changes to inactive), every non-employee profile they sponsor is left pointing at an inactive owner. Left unaddressed, this creates orphaned sponsorship, breaks approval routing for those non-employees, and becomes a recurring audit finding.

This pattern automates detection of the condition and, wherever possible,

The Solution: " Reassign Sponsor" Workflow

This is implemented as an Identity Security Cloud workflow triggered directly off identity attribute changes. At a high level, the workflow:

1. Detects when an identity’s lifecycle state changes to inactive.

2. Checks whether that identity has a Non-Employee Users source account (i.e., whether they are an NE sponsor at all).

3. Looks up who currently manages the non-employees this sponsor was responsible for, via that sponsor’s manager.

4. If the manager already has a usable Non-Employee Users account, reassigns all of the inactive sponsor’s non-employee profiles to the manager automatically.

Each non-employee profile is updated by calling the Non-Employee Risk Management API directly, so the change is reflected back in the source system of record.

Trigger Configuration

The workflow is started by an Identity Security Cloud event trigger, filtered so it only fires on the relevant attribute change:

Workflow Walkthrough

1. Confirm the identity actually became inactive

Step: Compare Strings

Compares the new value of cloudLifecycleState from the trigger payload against the literal string “inactive”. If it doesn’t match, the workflow ends immediately (End Step – Success) — no further action is needed for this event.

3 Retrieve the non-employee profiles this sponsor owns**

Step: HTTP Request — “Get profiles that user is a sponsor”

A GET call to the Non-Employee Risk Management API’s /api/user_profiles endpoint, authenticated with a stored secret, returns every NE profile associated with this sponsor’s neUserId:

GET https://.mynonemployee.com/api/user_profiles ?metadata=true &ne_attribute_id= &user_id={{ $.defineVariable.neUserId }}

The resulting list of profile_id values is what gets reassigned later in the workflow.

4 Automatic path — reassign directly to the manager’s NE identity

For each profile_id returned in step 3, the workflow calls the Non-Employee Risk Management workflow_sessions API, setting sponsor_ne_attribute and requester_id to the manager’s NE user ID:

POST https://.mynonemployee.com/api/workflow_sessions Body: workflow_session.attributes.sponsor_ne_attribute = <manager’s NE ID> workflow_session.profile_id = workflow_session.requester_id = <manager’s NE ID> workflow_session.requester_type = “User” workflow_session.workflow_id =

This runs inside a Loop over every profile the deactivated sponsor owned, so every affected non-employee is updated in one pass.

5 End the workflow

success step once every affected non-employee profile has been resent to the Non-Employee Risk Management API with its new sponsor.

Prerequisites

• A configured Non-Employee Risk Management (NE) source, with the sourceName “Non-Employee Users” used consistently for account correlation.

• An identity event trigger enabled for idn:identity-attributes-changed.

• A published form definition for manual sponsor selection (referenced by formDefinitionId in the workflow).

• Stored secrets configured in the workflow for authenticating to the NE API (used by both HTTP Request steps).

• The correct NE workflow_id for the “update sponsor” workflow_session type, matching what your NE tenant expects.

Considerations

• The workflow relies on a manager reference (managerRef) being populated on the deactivated sponsor’s identity

• Because reassignment calls the NE API once per profile inside a loop, a sponsor with a large number of NE profiles will generate a corresponding number of API calls; consider NE API rate limits at scale.

Screenshots

can you share the workflow please if possible ?