NERM – Workflow Attribute Type: Profile vs Request

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

Hi folks,

While configuring NERM workflows, I noticed we can choose between “Profile” and “Request” attribute types in Automated and Update Workflows.

My understanding is that “Request” should be used when you’re working with a form submission, since it captures values directly from the request. But it’s unclear when exactly to use “Profile” — is that only for referencing existing identity data?

Could someone clarify the difference and provide guidance on when to use each, especially in onboarding vs update scenarios?

thanks

2

The “Request” attribute type specifically refers to data within the current workflow session or form submission, capturing values being actively entered or modified during that transaction. This is useful for new information provided during an onboarding process or updated values submitted via a form in an update workflow.

Conversely, the “Profile” attribute type is used to reference existing identity data already stored within a NERM profile. This allows workflows to access and manipulate established information associated with an individual, organization, or other managed object. When a workflow needs to read existing data from a profile to make decisions, populate fields, or apply updates to a pre-existing record, the “Profile” attribute type is the appropriate choice. This distinction ensures that data from active submissions is handled separately from an entity’s enduring record in the system.

Let’s imagine you have a “Non-Employee” profile type, and within that profile type, you have an attribute called “onboarding_status” which tracks the current stage of a non-employee’s onboarding.

Here’s an example of referencing this “onboarding_status” profile attribute in an “Automated Workflow” or “Update Workflow”:

Scenario: You want an automated workflow to trigger an action (e.g., send a reminder email) if a non-employee’s “onboarding_status” has been “Pending Approval” for more than 7 days.

Workflow Configuration (conceptual):

  • Workflow Type: Automated Workflow
  • Trigger/Filter (within the workflow’s PROFILES section):
    • Filter Type: Profile attribute
    • Attribute: onboarding_status (referencing the existing attribute on the non-employee’s profile)
    • Operator: equals
    • Value: Pending Approval
    • Add another filter for the date condition:
      • Attribute: onboarding_status_last_updated_date (assuming you have another profile attribute tracking when the status was last updated)
      • Operator: more than
      • Days: 7
      • Timeframe: days before today

In this example, the workflow directly references the onboarding_status and onboarding_status_last_updated_date as “Profile” attributes because it’s checking existing data on the non-employee’s stored profile to determine if the workflow should run.

2 Likes