Different Certification Campaign approaches

[Markharoll (Marco Carolla)]

Hello Community,

I am currently tasked with implementing Certification Campaigns triggered by changes to specific Identity Attributes. I’ve conceptualized two potential scenarios, and I need to thoroughly refine them and assess their feasibility before determining the optimal approach.

---

Scenario 1: Instant Campaign Triggered by Attribute Change

This approach involves creating an immediate certification campaign for a single user when a designated identity attribute is modified.

Implementation Idea:

• Workflow Trigger: Utilize a workflow configured with an “Identity Attribute Changed” trigger (e.g., for attributes like manager, department, costCenter, location, jobCode, title).
• Campaign Creation: Within this workflow, initiate the creation of a new certification campaign. This campaign would ideally target only the specific user whose attribute has changed.

Specific Questions & Considerations:

• User Inclusion in Campaign: While I can see the functionality to create a new campaign, how can I retrieve the specific user who triggered the workflow and add it to this newly created campaign? Is there an API endpoint or a specific campaign type that allows for dynamic population based on a single identity?
• Workflow 1 Trigger Behavior: When an Identity changes multiple attributes simultaneously (e.g., manager and department in a single HR feed update), will Workflow 1 be triggered once for the overall identity change, or once for each individual attribute change? How can we ensure that all concurrent changes are captured efficiently within a single workflow execution if possible?
• Retrieving Changed Attributes in Workflow: How can I reliably retrieve all the attributes that have changed from within Workflow 1? Are before and after values always available and easily parsed? What is the best practice for capturing and differentiating multiple attribute changes within a single workflow instance?

PROs:

• Simplicity of Initial Implementation: The core logic of triggering a workflow on attribute change and then creating a campaign seems straightforward.
• Immediate Response: Certification is initiated almost immediately after the attribute change, potentially ensuring quicker compliance.

CONs:

• Campaign Proliferation: This approach could lead to a significant number of individual certification campaigns being generated. For instance, if an entire organizational unit (e.g., 500 users) is reassigned to a new manager, 500 distinct campaigns might be created simultaneously. This could overwhelm the system and the certifiers.
• Certifier Fatigue/Overhead: Certifiers (e.g., managers) would receive multiple notifications and have to manage many small, individual campaigns, which could lead to inefficiency and overlooked certifications. It would be far more efficient to collect all relevant users into a single, larger campaign for the new manager to certify. Similar challenges arise when other attributes (like department or location) change for multiple identities.
• Reporting Complexity: Aggregating results and tracking overall certification status across numerous micro-campaigns could become complex.

---

Scenario 2: Scheduled Campaign with Intermediate State Tracking

This approach aims to consolidate attribute-change certifications into fewer, larger campaigns, run on a scheduled basis, by tracking changed attributes in an intermediate data store.

Implementation Idea:

• Intermediate Data Source: Create a new CSV source (e.g., a “Changed Attributes Source”) with an attribute schema designed to track changes. This schema must include uid (for correlation to Identity), and specific attributes like changedManager, changedDepartment, changedLocation, etc. Each changedX attribute would hold a Boolean value (TRUE/FALSE) indicating if the respective identity attribute has changed.
• Workflow 1 (Change Detection): Implement a custom workflow started by an “Identity Attribute Changed” trigger. This workflow would perform the following:
  • Identify the specific attribute(s) that changed.
  • Using an API to create or modify an account on the “Changed Attributes Source” for the affected identity.
  • Set the relevant changedX attribute (e.g., changedManager) to TRUE for that identity on the staging source.
• Scheduled Certification Campaign(s): Implement scheduled certification campaigns (e.g., weekly or monthly).
  • Each campaign would be configured to target all identities that have an account on the “Changed Attributes Source” with a specific changedX=TRUE attribute (e.g., changedManager=TRUE).
  • Multiple scheduled campaigns could be set up for different attribute types (e.g., one for changedManager=TRUE, another for changedDepartment=TRUE).
• Workflow 2 (Post-Certification Cleanup): Implement a second workflow (e.g., “Certification Cleanup Workflow”) triggered when a Certification Campaign ends.
  • This workflow would need to identify which specific campaign has just concluded (e.g., “Manager Change Certification Campaign”).
  • For all identities included in that campaign, it would then modify their corresponding account on the “Changed Attributes Source” via API to set the respective changedX attribute (e.g., changedManager) back to FALSE.

Specific Questions & Considerations:

• Workflow 1 Trigger Behavior: When an Identity changes multiple attributes simultaneously (e.g., manager and department in a single HR feed update), will Workflow 1 be triggered once for the overall identity change, or once for each individual attribute change? How can we ensure that all concurrent changes are captured efficiently within a single workflow execution if possible?
• Retrieving Changed Attributes in Workflow: How can I reliably retrieve all the attributes that have changed from within Workflow 1? Are before and after values always available and easily parsed? What is the best practice for capturing and differentiating multiple attribute changes within a single workflow instance?
• Alternatives to CSV Source: Are there more native or performant alternatives within SailPoint (e.g., Identity Attributes?) that could serve as this intermediate staging mechanism, instead of creating a synthetic “CSV Source”?

PROs:

• Consolidated Campaigns: Generates fewer, larger certification campaigns, making them easier for certifiers to manage and reducing system overhead.
• Improved Certifier Experience: Certifiers receive consolidated certification tasks, leading to less fatigue and a clearer overview.
• Centralized Tracking: The “Changed Attributes Source” provides a centralized log of which attributes have changed for which identities, potentially useful for auditing or reporting.

CONs:

• Increased Implementation Complexity: This approach involves multiple workflows, an intermediate data source, and complex API interactions, significantly increasing development effort and potential points of failure.
• Feasibility Unknowns: Many of the detailed steps (e.g., dynamic campaign population based on a custom source attribute, precise API usage for source modification, robust error handling across workflows) need to be thoroughly validated for feasibility within the SailPoint platform.

---

Final Questions: Which Approach is Better?

Considering the detailed pros and cons, and the questions raised, which of these two approaches do you consider to be the superior solution for implementing attribute-change-triggered certification campaigns in a SailPoint environment?

Are there alternatives or native SailPoint features that could address this requirement more effectively than either of these proposed scenarios?

[jesvin90 (Jesvin Joseph)]

Hi @Markharoll,

Here are some of my responses on your first approach since that’s something that I have checked.

1. The workflow triggers only once that includes all the changed attributes, assuming that all these changes are coming from a singe source. Refer to the sample data here.

2. In this approach, separate certifications will be created for each of the involved users.

3. The changed attributes can be called with filters like this :

$.trigger.changes[?(@.attribute == "manager")].newValue.id
$.trigger.changes[?(@.attribute == "email")].oldValue

4. Attaching a basic sample WF if you want to refer.

UserCertification20250521.json (1.8 KB)