Build a SailPoint IdentityIQ Lab

Govern LDAP access with SailPoint IdentityIQ lifecycle and SoD controls.

Introduction

30 Second Summary

Old access can linger when someone changes teams. It can stay active after that person leaves the company.

In this project, you will turn one training identity into an end-to-end identity governance demonstration using SailPoint IdentityIQ 9.0. Your demonstration follows that identity from trusted HR ingestion through offboarding.

What You'll Build

You will walk an interviewer through one identity's journey from its HR record to disabled accounts using redacted evidence from a private repository.

By the end of this project, you'll have:

  • A visible Identity Cube that shows a linked LDAP account beside attributes from the authoritative HR source.
  • A two-tier role model backed by a custom Workflow whose Task Result proves the Engineering branch processed the department transfer.
  • A redacted private GitHub repository that preserves proof of the compliance journey from Separation of Duties detection through certification and remediation to leaver disablement.
  • Secret Mission: Reinstate the identity while restoring valid access without reviving the remediated toxic combination.

Are there any prerequisites?

You need a SailPoint University lab with administrative access plus preconfigured authoritative and LDAP applications. You also need Lifecycle Manager, Compliance Manager, and a GitHub account.

Before We Start

Before any configuration changes, this is your moment to commit to the organization scenario, the training identity you will follow, and the department-driven access change you will govern. Your chosen authoritative HR application, target LDAP application, and business risk will anchor every result you collect.

Baseline the Lab and Create the Evidence Repository

Your SailPoint IdentityIQ lab behavior depends on its exact release. Licensed modules determine which governance controls are available.

A private GitHub repository gives every later result a safe evidence home. Its starter files also set the implementation boundary before you change the lab.

In this step, get ready to:
  • Record the lab version and expiry.
  • Inventory the available applications and governance modules.
  • Create a private evidence repository with the starter files.
Record the lab baseline

The version gate protects your lab from XML written for a different release. The inventory also confirms that the later lifecycle tasks fit the capabilities available to your account.

  • Open the wrench menu in the IdentityIQ lab.
  • Select Debug.
  • Select About.
  • Record the displayed product version here: your exact IdentityIQ product version.
  • Record the displayed schema version here: your exact IdentityIQ schema version.
  • Switch back to the SailPoint University platform page from earlier.
  • Hover over the top-right corner of the platform home page.
  • Record the displayed expiry here: your lab expiry.

Stop at the Version Gate

The custom XML in this project targets IdentityIQ 9.0. A different product version blocks all later XML imports until the files receive a version-specific review.

  • Stop before importing any XML if the displayed product version differs from IdentityIQ 9.0.

Your version gate is now recorded. Next, the existing lab objects tell you which names and controls the project must preserve.

  • Switch back to the IdentityIQ browser lab.
  • Select Applications.
  • Select Application Definition.
  • Record the authoritative application name here: your authoritative application name.
  • Record the target LDAP application name here: your LDAP application name.

Why Preserve These Applications?

The applications already contain lab-specific connector settings. Recording their names lets you reuse that configuration without exposing credentials or rebuilding licensed connectors.

  • Select Setup.
  • Select Lifecycle Events to confirm whether lifecycle administration is available.
  • Return to Setup.
  • Select Policies to confirm whether policy administration is available.
  • Open the Certifications area to confirm whether certification administration is available.
  • Record the available modules here: your enabled IdentityIQ modules.

The pages you can access establish whether Lifecycle Manager and Compliance Manager features are present. The final inventory check covers the tasks you can run.

  • Return to Setup.
  • Select Tasks.
  • Check whether your account exposes task creation and execution actions.
  • Record the available task permissions here: your available task permissions.
Create the private evidence repository

The repository stores implementation files plus redacted evidence from later steps. Keep it private so you can review every file before deciding whether anything is suitable to share.

  • Switch back to GitHub from earlier.
  • Select New repository.
  • Choose your GitHub account under Owner.
  • Enter identityiq-governance-lab as the repository name.
  • Choose Private for the visibility.
  • Select Add README.
  • Click Create repository.

You should see the new private repository with an initial README.md file.

  • Select README.md from the repository file list.
  • Use the file-edit control above the README preview.
  • Replace the existing content with the project overview below:
# IdentityIQ Governance Lab

Target platform: SailPoint IdentityIQ 9.0
Actual lab version: Record before execution

## Scenario

One identity is aggregated from an authoritative HR source, correlated to LDAP, moved to a new department, evaluated for role access and Separation of Duties, certified, remediated, and offboarded.

## Evidence

- Version and module inventory
- Authoritative and LDAP aggregation Task Results
- Correlation failure and repair
- Identity mapping table
- Business and IT role model
- Mover rule and workflow
- Provisioning result
- SoD policy and violation
- Certification and remediation
- Leaver result

## Data handling

This repository contains only synthetic or redacted evidence. It contains no credentials, connection strings, personal data, proprietary course files, or access tokens.

What Does This README Establish?

  • The scenario follows one identity through ingestion and governance.
  • The evidence list defines the results you collect throughout the project.
  • The data-handling section defines what must stay outside the repository.
  • Click Commit changes.
  • Keep the default commit summary in the commit dialog.
  • Click Commit changes in the dialog.

You should see the rendered IdentityIQ Governance Lab README with the target platform and evidence categories.

README Not Showing the New Content?

Confirm that you committed the edit to README.md inside identityiq-governance-lab. Return to the file editor if the repository still shows GitHub's initial heading.

Help me fix the README commit

✔️ Awesome, I've got everything!

Your README.md matches the starter overview and data-handling boundary.

ⓧ I'd like to double check the full code

# IdentityIQ Governance Lab

Target platform: SailPoint IdentityIQ 9.0
Actual lab version: Record before execution

## Scenario

One identity is aggregated from an authoritative HR source, correlated to LDAP, moved to a new department, evaluated for role access and Separation of Duties, certified, remediated, and offboarded.

## Evidence

- Version and module inventory
- Authoritative and LDAP aggregation Task Results
- Correlation failure and repair
- Identity mapping table
- Business and IT role model
- Mover rule and workflow
- Provisioning result
- SoD policy and violation
- Certification and remediation
- Leaver result

## Data handling

This repository contains only synthetic or redacted evidence. It contains no credentials, connection strings, personal data, proprietary course files, or access tokens.

The README explains the story. The evidence checklist turns that story into a concrete collection plan.

  • Return to the repository file list.
  • Select Add file.
  • Select Create new file.
  • Enter evidence-checklist.md as the filename.
  • Add the environment and correlation sections with the content below:
# Evidence Checklist

## Environment

- [ ] Actual IdentityIQ version recorded
- [ ] Lab expiry recorded
- [ ] Enabled modules recorded
- [ ] Application names recorded without secrets

## Data and correlation

- [ ] Authoritative aggregation Task Result
- [ ] LDAP Test Connection and schema evidence
- [ ] Designed uncorrelated-account result
- [ ] Corrected correlation result
- [ ] Identity Cube with both source views

What Do These Sections Track?

The first section captures the environment gate. The second section tracks the ingestion and correlation evidence that you produce in the next two steps.

  • Click Commit changes.
  • Confirm the commit in the dialog.

You should see evidence-checklist.md rendered with the Environment and Data and correlation sections.

Checklist File Missing?

Check that the filename is exactly evidence-checklist.md. Confirm that the commit completed before returning to the repository file list.

Help me find the checklist file

  • Use the file-edit control on evidence-checklist.md.
  • Place the cursor after the final Identity Cube checklist item.
  • Add the role and governance sections below:


## Roles and lifecycle

- [ ] IT role and entitlement profile
- [ ] Business role and assignment rule
- [ ] Mover Workflow rule
- [ ] IdentityLifecycle workflow diagram
- [ ] Engineering branch Task Result
- [ ] Provisioning result

## Governance

- [ ] Role SOD policy
- [ ] Policy simulation
- [ ] Active violation
- [ ] Certification decision
- [ ] Remediation result or manual work item
- [ ] Leaver account-disable result

Why Track Roles and Governance Separately?

The role section proves how access is modeled and provisioned. The governance section proves that incompatible access is detected and remediated.

  • Click Commit changes.
  • Confirm the commit in the dialog.

You should now see Roles and lifecycle plus Governance beneath the correlation evidence.

Sections Rendered Inside a Checklist Item?

Make sure there is one blank line before each level-two heading. Check that every checklist entry begins on its own line.

Help me repair the Markdown layout

  • Use the file-edit control on evidence-checklist.md again.
  • Place the cursor after the final leaver checklist item.
  • Add the repository-safety section below:


## Repository safety

- [ ] Credentials removed
- [ ] Connection strings removed
- [ ] Personal data replaced or redacted
- [ ] Proprietary course files excluded
- [ ] Screenshots checked before commit

What Does the Safety Check Prevent?

This final section creates a review gate before each evidence commit. It keeps secrets and restricted training material outside the portfolio repository.

  • Click Commit changes.
  • Confirm the commit in the dialog.

You should see five repository-safety checks at the bottom of evidence-checklist.md.

Safety Checks Missing From the Bottom?

Confirm that you edited the existing checklist file. Check that the new section follows the leaver item before committing again.

Help me complete the evidence checklist

✔️ Awesome, I've got everything!

Your evidence checklist now covers the complete governance story plus the repository-safety review.

ⓧ I'd like to double check the full code

# Evidence Checklist

## Environment

- [ ] Actual IdentityIQ version recorded
- [ ] Lab expiry recorded
- [ ] Enabled modules recorded
- [ ] Application names recorded without secrets

## Data and correlation

- [ ] Authoritative aggregation Task Result
- [ ] LDAP Test Connection and schema evidence
- [ ] Designed uncorrelated-account result
- [ ] Corrected correlation result
- [ ] Identity Cube with both source views

## Roles and lifecycle

- [ ] IT role and entitlement profile
- [ ] Business role and assignment rule
- [ ] Mover Workflow rule
- [ ] IdentityLifecycle workflow diagram
- [ ] Engineering branch Task Result
- [ ] Provisioning result

## Governance

- [ ] Role SOD policy
- [ ] Policy simulation
- [ ] Active violation
- [ ] Certification decision
- [ ] Remediation result or manual work item
- [ ] Leaver account-disable result

## Repository safety

- [ ] Credentials removed
- [ ] Connection strings removed
- [ ] Personal data replaced or redacted
- [ ] Proprietary course files excluded
- [ ] Screenshots checked before commit
Add the version-controlled XML

The custom XML files define the mover decision before it reaches the lab. They remain version-controlled only during this step.

The Rule uses BeanShell to choose a branch from the target department. The IdentityLifecycle workflow records that choice before refreshing the identity.

  • Return to the repository file list.
  • Select Add file.
  • Select Create new file.
  • Enter NW_Mover_Decision.xml as the filename.
  • Add the mover decision Rule with the content below:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sailpoint PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<sailpoint>
  <Rule language="beanshell" name="NW Mover Decision" type="Workflow">
    <Description>Returns the workflow branch for the target department.</Description>
    <Source><![CDATA[
      if (targetDepartment == null) {
        return "general";
      }

      String normalizedDepartment = targetDepartment.trim();
      if ("Engineering".equalsIgnoreCase(normalizedDepartment)) {
        return "engineering";
      }

      return "general";
    ]]></Source>
  </Rule>
</sailpoint>

What Does the Mover Decision Do?

  • A missing department returns the general branch.
  • The Rule trims the department before comparing it.
  • An Engineering value returns the engineering branch without depending on letter case.
  • Click Commit changes.
  • Confirm the commit in the dialog.

You should see NW_Mover_Decision.xml with the Rule named NW Mover Decision.

Rule XML Looks Truncated?

Confirm that the file ends with the closing Rule and sailpoint tags. Check that the CDATA opening and closing markers surround the BeanShell source.

Help me check the mover Rule XML

✔️ Awesome, I've got everything!

The mover Rule is committed with its Engineering and general branch results.

ⓧ I'd like to double check the full code

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sailpoint PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<sailpoint>
  <Rule language="beanshell" name="NW Mover Decision" type="Workflow">
    <Description>Returns the workflow branch for the target department.</Description>
    <Source><![CDATA[
      if (targetDepartment == null) {
        return "general";
      }

      String normalizedDepartment = targetDepartment.trim();
      if ("Engineering".equalsIgnoreCase(normalizedDepartment)) {
        return "engineering";
      }

      return "general";
    ]]></Source>
  </Rule>
</sailpoint>

The workflow file is longer because it defines the inputs plus each transition. You will build it in small committed sections so every addition remains visible in GitHub.

  • Return to the repository file list.
  • Select Add file.
  • Select Create new file.
  • Enter NW_Department_Mover.xml as the filename.
  • Create the workflow shell with its variables and boundary steps using the content below:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE SailPoint PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<sailpoint>
  <Workflow explicitTransitions="true"
            libraries="Identity"
            name="NW Department Mover"
            type="IdentityLifecycle">
    <Variable input="true" name="identityName">
      <Description>Name of the identity being processed.</Description>
    </Variable>
    <Variable initializer="Engineering" input="true" name="targetDepartment">
      <Description>Department that determines the mover branch.</Description>
    </Variable>
    <Variable name="moverDecision" output="true">
      <Description>Branch returned by the mover decision rule.</Description>
    </Variable>

    <Description>Evaluates a department move, records the selected branch, and refreshes the identity.</Description>

    <Step icon="Start" name="Start" posX="40" posY="120">
      <Description>Start the mover workflow.</Description>
      <Transition to="Evaluate Mover"/>
    </Step>

    <Step icon="Stop" name="Stop" posX="850" posY="120">
      <Description>Finish the mover workflow.</Description>
    </Step>
  </Workflow>
</sailpoint>

What Does the Workflow Shell Define?

  • The input variables identify the person and target department.
  • The output variable stores the Rule result.
  • The Start and Stop steps define the workflow boundaries.
  • Click Commit changes.
  • Confirm the commit in the dialog.

You should see identityName, targetDepartment, and moverDecision above the Start and Stop steps.

Workflow Shell Missing a Closing Tag?

Check that every Variable and Step has a closing tag. Confirm that Workflow closes before the final sailpoint tag.

Help me check the workflow shell

  • Use the file-edit control on NW_Department_Mover.xml.
  • Place the cursor on the blank line directly before the Stop step.
  • Insert the Rule evaluation step below:
    <Step action="rule:NW Mover Decision"
          icon="Task"
          name="Evaluate Mover"
          posX="220"
          posY="120"
          resultVariable="moverDecision">
      <Arg name="targetDepartment" value="ref:targetDepartment"/>
      <Description>Return the branch associated with the target department.</Description>
      <Transition to="Engineering Branch" when="script:&quot;engineering&quot;.equals(moverDecision)"/>
      <Transition to="General Branch"/>
    </Step>

How Does the Evaluation Step Branch?

The step passes targetDepartment to the reusable Rule. It stores the returned branch in moverDecision.

The conditional transition selects Engineering. The final unconditional transition provides the general path.

  • Click Commit changes.
  • Confirm the commit in the dialog.

You should see Evaluate Mover between Start and Stop with two outgoing transitions.

Evaluate Mover Appears After Stop?

Move the entire Evaluate Mover block above the Stop step. Keep both transitions inside the Evaluate Mover closing tag.

Help me position the evaluation step

  • Use the file-edit control on NW_Department_Mover.xml again.
  • Place the cursor on the blank line directly before the Stop step.
  • Insert the Engineering message step below:
    <Step action="call:addMessage"
          icon="Message"
          name="Engineering Branch"
          posX="430"
          posY="60">
      <Arg name="message" value="string:NW mover branch selected: Engineering"/>
      <Description>Record the Engineering mover path in the workflow case.</Description>
      <Transition to="Refresh Identity"/>
    </Step>

What Does the Engineering Branch Record?

This step adds the Engineering branch message to the workflow case. Its transition sends the workflow toward the identity refresh.

  • Click Commit changes.
  • Confirm the commit in the dialog.

You should see Engineering Branch after Evaluate Mover with the Engineering message value.

Engineering Message Missing?

Check that the Arg remains inside the Engineering Branch step. Confirm that its transition points to Refresh Identity.

Help me repair the Engineering branch

  • Use the file-edit control on NW_Department_Mover.xml again.
  • Place the cursor on the blank line directly before the Stop step.
  • Insert the general message step below:
    <Step action="call:addMessage"
          icon="Message"
          name="General Branch"
          posX="430"
          posY="180">
      <Arg name="message" value="string:NW mover branch selected: General"/>
      <Description>Record the general mover path in the workflow case.</Description>
      <Transition to="Refresh Identity"/>
    </Step>

What Does the General Branch Record?

This step records the fallback path in the workflow case. It joins the Engineering path at the same refresh step.

  • Click Commit changes.
  • Confirm the commit in the dialog.

You should see General Branch after Engineering Branch with its own general message.

Branch Messages Look Identical?

Compare the Arg values in both message steps. The Engineering step ends with Engineering while the General step ends with General.

Help me compare the branch messages

  • Use the file-edit control on NW_Department_Mover.xml one final time.
  • Place the cursor on the blank line directly before the Stop step.
  • Insert the identity refresh step below:
    <Step action="call:refreshIdentity"
          icon="Task"
          name="Refresh Identity"
          posX="650"
          posY="120">
      <Arg name="identityName" value="ref:identityName"/>
      <Description>Refresh the identity after the mover decision.</Description>
      <Transition to="Stop"/>
    </Step>

How Does the Workflow Finish?

The refresh step passes identityName to the Identity workflow library. It transitions to Stop after the refresh.

  • Click Commit changes.
  • Confirm the commit in the dialog.

You should now see a continuous path from Start through evaluation and branch messaging to Refresh Identity and Stop.

Workflow Path Stops Before Refresh?

Confirm that both message steps point to Refresh Identity. Check that Refresh Identity appears directly before Stop.

Help me complete the workflow path

✔️ Awesome, I've got everything!

The complete IdentityLifecycle workflow is committed. It remains unimported until the version gate permits the later import step.

ⓧ I'd like to double check the full code

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE SailPoint PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<sailpoint>
  <Workflow explicitTransitions="true"
            libraries="Identity"
            name="NW Department Mover"
            type="IdentityLifecycle">
    <Variable input="true" name="identityName">
      <Description>Name of the identity being processed.</Description>
    </Variable>
    <Variable initializer="Engineering" input="true" name="targetDepartment">
      <Description>Department that determines the mover branch.</Description>
    </Variable>
    <Variable name="moverDecision" output="true">
      <Description>Branch returned by the mover decision rule.</Description>
    </Variable>

    <Description>Evaluates a department move, records the selected branch, and refreshes the identity.</Description>

    <Step icon="Start" name="Start" posX="40" posY="120">
      <Description>Start the mover workflow.</Description>
      <Transition to="Evaluate Mover"/>
    </Step>

    <Step action="rule:NW Mover Decision"
          icon="Task"
          name="Evaluate Mover"
          posX="220"
          posY="120"
          resultVariable="moverDecision">
      <Arg name="targetDepartment" value="ref:targetDepartment"/>
      <Description>Return the branch associated with the target department.</Description>
      <Transition to="Engineering Branch" when="script:&quot;engineering&quot;.equals(moverDecision)"/>
      <Transition to="General Branch"/>
    </Step>

    <Step action="call:addMessage"
          icon="Message"
          name="Engineering Branch"
          posX="430"
          posY="60">
      <Arg name="message" value="string:NW mover branch selected: Engineering"/>
      <Description>Record the Engineering mover path in the workflow case.</Description>
      <Transition to="Refresh Identity"/>
    </Step>

    <Step action="call:addMessage"
          icon="Message"
          name="General Branch"
          posX="430"
          posY="180">
      <Arg name="message" value="string:NW mover branch selected: General"/>
      <Description>Record the general mover path in the workflow case.</Description>
      <Transition to="Refresh Identity"/>
    </Step>

    <Step action="call:refreshIdentity"
          icon="Task"
          name="Refresh Identity"
          posX="650"
          posY="120">
      <Arg name="identityName" value="ref:identityName"/>
      <Description>Refresh the identity after the mover decision.</Description>
      <Transition to="Stop"/>
    </Step>

    <Step icon="Stop" name="Stop" posX="850" posY="120">
      <Description>Finish the mover workflow.</Description>
    </Step>
  </Workflow>
</sailpoint>

Before you check the repository, which four filenames do you expect to see?

  • Return to the identityiq-governance-lab repository file list.
  • Confirm that README.md is listed.
  • Confirm that evidence-checklist.md is listed.
  • Confirm that NW_Mover_Decision.xml is listed.
  • Confirm that NW_Department_Mover.xml is listed.
  • Open README.md from the file list.
  • Confirm that the rendered README shows the IdentityIQ 9.0 target and repository data-handling boundary.

You should see all four starter files in the private repository. Your recorded baseline now supplies the actual version, schema, expiry, modules, permissions, and application names without placing sensitive lab data in the files.

Your lab now has a version gate plus a redacted evidence structure. Next, you will run the authoritative and LDAP aggregations before exposing the planned correlation gap.

Aggregate Sources and Expose a Correlation Gap

Your lab baseline is documented. You can now use SailPoint IdentityIQ to turn source accounts into evidence you can inspect.

A successful connector run proves that records moved. You will inspect the HR path plus the LDAP path so connector success never hides poor identity data.

In this step, get ready to:
  • Run authoritative Account Aggregation for one synthetic training identity.
  • Validate the LDAP connection plus its account and group schemas.
  • Use a nonmatching pair to expose an account correlation gap.
Aggregate the authoritative identity

An authoritative source owns the identity attributes that IdentityIQ trusts. Its aggregation creates or updates the corresponding Identity Cube.

  • Return to the SailPoint University IdentityIQ browser lab from earlier.
  • Review the available synthetic HR records for a training identity.
  • Confirm that the same training identity has a corresponding account in the recorded LDAP application.
  • Confirm that the LDAP account is not already linked to another identity.
  • Record your chosen identity here: your selected training identity.

What Does the Authoritative Source Establish?

An authoritative application creates the trusted identity record during aggregation. Later sources must correlate their accounts to that record.

This ordering gives you one governed identity instead of disconnected source accounts.

  • Select Setup in the IdentityIQ navigation.
  • Select Tasks.
  • Locate the existing Account Aggregation task configured for the authoritative application you recorded earlier.
  • Right-click the authoritative Account Aggregation task.
  • Select Execute.
  • Open Task Results after the task finishes.
  • Open the newest result for the authoritative aggregation.

You should see a completed result showing that the source account created or updated an identity. The result should contain no source-processing failure for the selected record.

  • Search for your selected training identity using the lab's identity search.
  • Open the Identity Cube for your selected training identity.
  • Compare the visible authoritative attributes with the synthetic HR source record.

You should see the source identifier plus the available name, email, department, manager, and inactive attributes from the authoritative record.

Keep Identity Evidence Redacted

Identity pages can place useful proof beside personal data. This is worth slowing down for before you capture evidence.

Keep the synthetic identifier plus the relevant attribute names visible. Remove credentials, connection details, and any personal values.

  • Capture a redacted screenshot of the authoritative Task Result.
  • Capture a redacted screenshot of the authoritative attributes on the Identity Cube.

Identity Missing or Unchanged?

  • Confirm that the task configuration names the authoritative application recorded in the previous step.
  • Confirm that the selected synthetic record is included in the source data available to the task.
  • Check the detailed Task Result for a source-processing failure before running the task again.

Ask for help with the task result: Help me diagnose why my authoritative Account Aggregation did not create or update the selected Identity Cube.

Validate the LDAP schema

LDAP supplies the target account that must eventually connect to the authoritative identity. Connection testing proves that IdentityIQ can reach the configured source.

Schema preview shows the account fields that IdentityIQ can aggregate. Those fields determine which attributes are available for correlation plus entitlement governance.

  • Select Applications in the IdentityIQ navigation.
  • Select Application Definition.
  • Open the LDAP application you recorded earlier.
  • Select Configuration.
  • Select Settings.
  • Click Test Connection.

You should see a successful connection status. This confirms that the preserved connector settings can reach the LDAP source.

  • Locate the defined account schema in the LDAP application configuration.
  • Click Preview for the account schema.

You should see a sample table containing LDAP account data. A failed preview identifies where the schema test stopped.

  • Record the account schema's Identity Attribute here: your LDAP identity attribute.
  • Record the account schema's Display Attribute here: your LDAP display attribute.
  • Record the governed entitlement attribute here: your LDAP entitlement attribute.
  • Locate the defined group schema in the LDAP application configuration.
  • Click Preview for the group schema.

You should see a sample table containing the available LDAP group data. This proves the schema can expose group objects for later entitlement work.

  • Record the group schema here: your LDAP group schema.
  • Capture the account schema fields in a redacted screenshot.
  • Capture the group schema in a redacted screenshot.

Connection or Preview Failed?

  • Confirm that you returned to the recorded LDAP application instead of the authoritative application.
  • Review the failure point reported by Preview without changing the preserved connector settings.
  • Use the task permissions recorded earlier to confirm that your lab account can test the application.

Ask for help without sharing connection details: Help me interpret my LDAP Test Connection or schema Preview failure.

Expose the correlation gap

Attribute Based Correlation compares an Application Attribute with an Identity Attribute. A stable pair links a source account to the correct Identity Cube.

For this controlled test, you will select two attributes whose values visibly differ for the chosen identity. The correlation safety option protects the lab from unwanted identity creation.

  • Return to the LDAP application configuration from earlier.
  • Select the Correlation tab.
  • Locate the Attribute Based Correlation configuration.
  • Compare the previewed LDAP values with the authoritative values for your selected training identity.
  • Select a visibly nonmatching LDAP field under Application Attribute.
  • Record the failed application attribute here: your failed application attribute.
  • Select a visibly nonmatching identity field under Identity Attribute.
  • Record the failed identity attribute here: your failed identity attribute.

The two recorded fields are your failed mapping evidence. Their selected values should be visibly different before you continue.

  • Save the LDAP application configuration.
  • Capture the nonmatching Application Attribute plus Identity Attribute pair in a redacted screenshot.
  • Select Setup in the IdentityIQ navigation.
  • Select Tasks.
  • Open the existing Account Aggregation task configured for the recorded LDAP application.
  • Select Only create links if they can be correlated to an existing identity.

Before you execute the LDAP task, do you think a successful connector run is enough to attach this account to the selected Identity Cube?

  • Run the configured LDAP aggregation by clicking Save and Execute.

The LDAP aggregation completes while the account remains uncorrelated. This is the intended shortfall produced by the nonmatching pair.

  • Open Task Results.
  • Open the newest result for the LDAP Account Aggregation task.
  • Inspect the detailed result for the uncorrelated LDAP account.
  • Return to the Identity Cube for your selected training identity.
  • Confirm that the LDAP account is absent from the Identity Cube's linked accounts.

The LDAP result records an account that remains available for Identity Correlation. The authoritative Identity Cube remains intact without an unwanted duplicate identity.

You found the governance gap on purpose. Connector success now has a separate data-quality check behind it.

LDAP Account Linked Anyway?

  • Compare the chosen attribute values again to confirm that they differ for the selected identity.
  • Confirm that the LDAP account was not already linked before this aggregation.
  • Choose another synthetic training pair if the account already had an existing link.

Ask for help with the unexpected link: Help me determine why my deliberately nonmatching LDAP correlation pair still linked the account.

  • Capture a redacted screenshot of the detailed LDAP Task Result.
  • Capture the failed Application Attribute plus Identity Attribute mapping in the same evidence set.
  • Open the authoritative Task Result once more to confirm that it created or updated the selected identity.
  • Open the LDAP Task Result once more to confirm that its account remains uncorrelated.

You exposed a connector run that looks successful while governance remains incomplete. Next, you'll repair the mapping before building the role model.

Repair Correlation and Build the Role Model

Your aggregations proved that SailPoint IdentityIQ can read the authoritative source and LDAP. The LDAP account is still detached from the selected Identity Cube.

Stable account correlation connects that account to the correct identity. A two-tier role model then turns its entitlement into access that the business can understand.

In this step, get ready to:
  • Replace the failing correlation with a stable match or a documented manual exception.
  • Map the authoritative identity attributes without creating circular sources.
  • Create an IT role and a department-based business role.
Repair the LDAP correlation

A correlation pair compares one LDAP account attribute with one identity attribute. Both values must identify the same person consistently.

Finding that pair can be fiddly because the two sources may use different attribute names. The values themselves reveal whether the match is dependable.

  • Select Applications from the IdentityIQ navigation.
  • Select Application Definition.
  • Open the LDAP application recorded earlier.
  • Select its Correlation tab.
  • Compare the available LDAP values with the selected identity's authoritative attributes.
  • Identify one LDAP attribute whose value uniquely matches one identity attribute.

What makes a stable pair?

A stable pair uses values maintained consistently by the source systems. The official IdentityIQ example maps application mail to identity email.

Use that example only when both values match for the selected identity. Avoid display names or department values because they can change or be shared.

  • Choose the tab that matches the data in your lab.

✔️ I found a stable pair

  • Replace the failing Application Attribute with the stable LDAP attribute.
  • Replace the failing Identity Attribute with the corresponding identity attribute.
  • Review one additional training account to confirm that the pair remains unique.
  • Save the LDAP application configuration.

The Correlation tab should now show the repaired attribute pair. This pair becomes the repeatable link between LDAP accounts and identities.

ⓧ No stable pair exists

The source data does not currently provide a dependable automated match. A one-time Identity Correlation exception links this training account while you document the underlying data problem.

  • Return to the uncorrelated LDAP account in Identity Correlation.
  • Link the LDAP account to the selected identity once.
  • Record which source attribute is missing or inconsistent.
  • Document the source-data correction required for automated correlation.

Your evidence should label this link as a temporary exception. The documented source correction explains how production correlation would become repeatable.

  • Return to Setup in IdentityIQ.
  • Select Tasks.
  • Open the LDAP Account Aggregation task used earlier.
  • Keep Only create links if they can be correlated to an existing identity.

Before you execute the task, do you expect IdentityIQ to create another identity or attach the LDAP account to the existing one?

  • Run the LDAP Account Aggregation task with Execute in background.
  • Open the completed result under Task Results.
  • Return to the selected identity's Identity Cube.

You should see the LDAP account linked beside the authoritative source account. Searching by the authoritative identity ID should still return one identity.

That closes the correlation gap you exposed earlier. You now have one governed identity instead of two disconnected records.

LDAP account still uncorrelated?

Compare the values exactly for spaces or case differences. Confirm that the repaired pair is saved on the same LDAP application used by the aggregation task.

Check the detailed Task Result for the account that was skipped. Make sure the option that prevents unmatched identity creation remained enabled.

Help me diagnose the remaining correlation gap.

Map authoritative identity attributes

Identity mappings decide which application supplies each Identity Cube attribute. Clear source ownership keeps HR values authoritative while LDAP remains a governed target.

  • Return to the gear menu in IdentityIQ.
  • Select Global Settings.
  • Select Identity Mappings.

Avoid circular mappings

Each mapped identity attribute needs a primary source. Using the same application attribute as both a source and a target can cause its value to change during repeated synchronization.

Use the authoritative application as the source for this lab's identity data. Keep LDAP focused on account access and entitlements.

  • Open the ID identity attribute.
  • Click Add Source.
  • Select Application Attribute.
  • Select the authoritative application recorded earlier.
  • Select its stable unique identifier attribute.
  • Click Add.

The ID mapping should now display the authoritative application and its unique source attribute. This row makes the source ownership visible.

  • Map manager to its corresponding authoritative application attribute.
  • Map email to its corresponding authoritative application attribute.
  • Map firstname to its corresponding authoritative application attribute.
  • Map lastname to its corresponding authoritative application attribute.
  • Map department to its corresponding authoritative application attribute.
  • Map inactive to its corresponding authoritative application attribute.
  • Review each row for any source that points back to its own target attribute.
  • Save the Identity Mappings changes.

You should see authoritative sources listed for ID, manager, email, firstname, lastname, department, and inactive. None of those mappings should form a circular source and target pair.

You now have a documented source of truth for every identity attribute used in this governance story. Those mappings give the role assignment rule dependable department data.

Missing an authoritative attribute?

Return to the selected Identity Cube and confirm the source attribute exists in its authoritative account data. Use the actual schema attribute from the lab instead of guessing a similar name.

If the authoritative source lacks a required value, document that data-quality gap before continuing. Do not substitute an LDAP target attribute as its own source.

Help me review my identity mappings.

Build and detect the two-tier role model

Role-based access control connects job context to technical access. A business role represents the job need while an IT role contains the managed LDAP entitlement.

Why native roles?

IdentityIQ's native two-tier model keeps access logic visible in role reviews and certifications. Required Roles connect the business role directly to the IT role.

Custom BeanShell is useful for complex decisions. Native assignment rules provide a clearer department match for this birthright-access example.

  • Return to the selected identity's Identity Cube.
  • Record its current department as the selected identity department.
  • Identify one managed LDAP entitlement already shown on the linked account.
  • Select Setup in IdentityIQ.
  • Select Roles.
  • Click Add.
  • Enter your IT role name in Name.
  • Select IT for Type.

You should see the panels used for technical access. The Entitlements panel is where this role receives its LDAP access.

  • Select a suitable training identity or workgroup in Owner.
  • Enter a description that names the LDAP access represented by the role.
  • Click Save.

The new IT role should now appear in Role Management. Its empty entitlement profile is ready for the managed LDAP value.

  • Open your IT role name from Role Management.
  • Click Add in the Entitlements panel.
  • Select the recorded LDAP application in Application.

You should now see the account attributes and managed entitlement values available from that LDAP application. This confirms that aggregation made the entitlement usable in role design.

  • Select the LDAP entitlement attribute in Account Attribute.
  • Select the chosen managed value in Select Entitlement.
  • Click Save to return to the Role Editor.
  • Save the IT role.

Your IT role now displays one entitlement profile for the LDAP application. That profile packages the underlying technical access into a reusable role.

  • Return to Setup.
  • Select Roles.
  • Click Add.
  • Enter your business role name in Name.
  • Select business for Type.

The Role Editor should now show business-role relationship fields. Required Roles provides the mandatory link to technical access.

  • Select a suitable training identity or workgroup in Owner.
  • Enter a description that explains the department-based job function.
  • Save the business role.

The business role should now appear in Role Management. You can add its required access and assignment logic without losing the basic role definition.

  • Open your business role name.
  • Add your IT role name under Required Roles.
  • Save the required-role relationship.

The business role should now list the IT role under Required Roles. This visible relationship connects the job function to its LDAP entitlement.

  • Open your business role name again.
  • Select Match List under Assignment Rule.
  • Add the identity attribute department.
  • Set its match value to the selected identity department.
  • Save the business role.

The saved business role should show a department-based assignment rule and the required IT role. Identity Refresh can now calculate the complete access chain.

Provision assignments can change access on the target LDAP system. Keeping that option clear makes this run a safe role-detection check.

  • Return to Setup.
  • Select Tasks.
  • Create or edit an Identity Refresh task for the selected identity.
  • Filter the task to the selected identity.
  • Select Refresh assigned and detected roles and promote additional entitlements.
  • Clear Provision assignments.

Before you run the refresh, which layers do you expect the Identity Cube to show from the department match through to the LDAP entitlement?

  • Run the filtered Identity Refresh with Save and Execute.
  • Open its completed result under Task Results.
  • Return to the selected identity's Identity Cube.
  • Search for the authoritative identity ID to confirm that only one identity exists.

You should see the linked LDAP account and the business role. You should also see its required IT role and the underlying entitlement without a duplicate identity.

You have turned a disconnected account into a governed access chain. The identity is now ready for a controlled department-mover test.

Roles missing from the Identity Cube?

Confirm that the selected identity's current department exactly matches the business role's Match List value. Review the business role to make sure the IT role appears under Required Roles.

Check that the IT role still contains the managed LDAP entitlement. Confirm that the refresh task included the role-detection option while Provision assignments remained clear.

Help me troubleshoot role detection.

Your correlation and role model are working together. Next, you will import the mover logic and use a department change to trigger a recorded lifecycle decision.

Implement the Mover Workflow

Your role model now detects the selected identity's birthright access in SailPoint IdentityIQ. It has no workflow evidence for a department transfer.

In this step, you'll import the version-controlled mover objects. An Attribute Change lifecycle event uses them to record a testable decision before provisioning changes LDAP access.

In this step, get ready to:
  • Import the existing mover XML objects into IdentityIQ.
  • Configure a department lifecycle event for the selected authoritative source.
  • Prove the department move through workflow evidence and role-based provisioning.
Import the mover rule and workflow

The NW Mover Decision rule uses BeanShell to return a branch name. The NW Department Mover object is an IdentityLifecycle workflow that records the branch before refreshing the identity.

The rule must exist before the workflow can resolve rule:NW Mover Decision. Your private GitHub repository contains both import files.

Check the version gate

These XML objects target IdentityIQ 9.0. A different product version needs a version-specific review before any import.

  • Stop this step if the product version you recorded earlier differs from IdentityIQ 9.0.
  • Request a version-specific edit before changing the lab.
  • Switch back to your private identityiq-governance-lab repository.
  • Open NW_Mover_Decision.xml from the repository file list.
  • Download NW_Mover_Decision.xml to your computer by using your browser's file download control.
  • Open NW_Department_Mover.xml from the repository file list.
  • Download NW_Department_Mover.xml to your computer by using your browser's file download control.

Import the decision rule first. This gives the workflow a valid rule action to call during its own import.

  • Switch back to the IdentityIQ browser lab.
  • Select the gear icon.
  • Select Global Settings.
  • Select Import from File.
  • Click Browse.
  • Select NW_Mover_Decision.xml from your downloads.
  • Click Import.

The Import from File Results page should confirm that the NW Mover Decision Rule was imported.

  • Click Import Another File.
  • Click Browse.
  • Select NW_Department_Mover.xml from your downloads.
  • Click Import.
  • Review the Import from File Results page for the NW Department Mover Workflow.

Great work. IdentityIQ now has the decision rule plus the lifecycle workflow that depends on it.

  • Click Done.
  • Select Setup.
  • Select Business Processes.
  • Open NW Department Mover.

What should the workflow show?

The workflow contains identityName. It also contains targetDepartment initialized to Engineering.

The Evaluate Mover step invokes rule:NW Mover Decision. Its return value is stored in moverDecision.

A return value of engineering leads to Engineering Branch. Every other value follows General Branch.

Each branch records its own message. Both paths move through Refresh Identity before reaching Stop.

Workflow missing or incomplete?

Confirm that you imported NW_Mover_Decision.xml before NW_Department_Mover.xml. A workflow cannot resolve a rule action when its Rule object is missing.

Check that your browser kept each filename ending in .xml. Downloading a rendered page can produce a different file type.

Help me diagnose the IdentityIQ XML import failure.

Configure the department lifecycle event

A lifecycle event connects an identity attribute change to a business process. This event watches the selected authoritative source for a new department value of Engineering.

This page is a little fiddly because the trigger fields share one form with the workflow settings. Keeping the filters narrow protects the rest of the training identities.

  • Select Setup in the IdentityIQ navigation.
  • Select Lifecycle Events.
  • Use the page's create control to begin a lifecycle event.
  • Select Attribute Change as the event type.
  • Select department as the changed identity attribute.
  • Restrict the event to the authoritative application you recorded earlier.
  • Set New Value Filter to Engineering.
  • Select NW Department Mover in the Business Process field.

Keep the test narrow

The application restriction confines the trigger to the authoritative source. The new-value filter confines it to the Engineering move.

  • Set a small Identity Processing Threshold appropriate for the single selected identity.
  • Enable the lifecycle event.
  • Save the lifecycle event.

The event summary should show an enabled Attribute Change event for department. It should list NW Department Mover as the selected business process.

Can't enable the event?

Confirm that Lifecycle Manager was listed in the module inventory you recorded earlier. Lifecycle events depend on that module being available in the lab.

Check that the authoritative application restriction points to the source of the selected identity's department value.

Help me troubleshoot the lifecycle event configuration.

Trigger the mover and provision access

Account Aggregation brings the authoritative department change into IdentityIQ. Identity Refresh processes the lifecycle event against that updated identity.

Your first refresh leaves provisioning off so the workflow result stays separate from the target change. Your second refresh enables provisioning for the selected identity only.

  • Return to the authoritative source editing area you used earlier.
  • Locate the selected synthetic identity.
  • Change its department value to Engineering.
  • Save the source record.

The authoritative source now contains the change that should launch the mover event. Aggregation must bring that value into the Identity Cube before the event can evaluate it.

  • Select Setup in IdentityIQ.
  • Select Tasks.
  • Locate the existing Account Aggregation task for your authoritative application.
  • Right-click the Account Aggregation task.
  • Select Execute in background.

Background execution keeps the lab available while aggregation processes the selected source.

  • Open Task Results.
  • Open the completed authoritative Account Aggregation result.

You should see the selected identity updated from the authoritative source. Its mapped department value should now be Engineering.

Good work. The trusted source now carries the department change that drives the workflow test.

Department still shows the old value?

Confirm that you executed the Account Aggregation task for the recorded authoritative application. An aggregation task for the LDAP application does not update the authoritative department mapping.

Check the completed Task Result for the selected identity. Verify that the source record was saved before aggregation began.

Help me trace the stale department value.

The identity now has the trigger value. Configure the first refresh to process the event while keeping provisioning disabled.

  • Return to Setup.
  • Select Tasks.
  • Open the Identity Refresh task you used earlier for role detection.
  • Keep its filter restricted to the selected identity.
  • Enable Refresh identity attributes.
  • Enable Refresh assigned and detected roles and promote additional entitlements.
  • Enable Process Events.
  • Enable Check active policies.
  • Keep Provision assignments disabled for this refresh.

Before you run the refresh, which workflow branch do you expect the Engineering value to select?

  • Run the filtered Identity Refresh by clicking Save and Execute.
  • Open Task Results after the refresh finishes.
  • Open the result associated with NW Department Mover.

You should see NW mover branch selected: Engineering in the workflow evidence. This proves that Evaluate Mover received the target department and followed Engineering Branch.

Engineering message missing?

Confirm that the lifecycle event is enabled. Check that its new-value filter is exactly Engineering.

Confirm that the refresh included Process Events. Verify that the task filter included the selected identity.

Help me diagnose the missing workflow branch message.

The workflow evidence is complete. The next refresh turns the detected role assignment into a target provisioning action.

  • Return to the filtered Identity Refresh task.
  • Keep the task restricted to the selected identity.
  • Enable Provision assignments.

Before you run the second refresh, what role-based action do you expect IdentityIQ to record for the managed LDAP access?

  • Run the second filtered refresh by clicking Save and Execute.
  • Open Task Results after the second refresh finishes.
  • Open the new Identity Refresh result.

You should see a role-based provisioning action for the managed LDAP access. The result may show the connector action or the lab's recorded provisioning request.

  • Return to the selected Identity Cube from earlier.

The Identity Cube should show Engineering as the mapped department. It should retain the linked LDAP account without creating a duplicate identity.

The business role should connect to the IT role. The provisioning result should represent the underlying managed entitlement.

No provisioning action recorded?

Confirm that Provision assignments was enabled for the second refresh. Check that the task remained filtered to the selected identity.

Verify that the business role still requires the IT role. Confirm that the IT role still contains the managed LDAP entitlement.

Help me trace the missing role provisioning action.

Your mover path now records the department decision before applying role-based access. Next up, you'll detect toxic access and capture an accountable remediation decision.

Govern Access and Offboard the Identity

Your mover workflow now records the Engineering branch in SailPoint IdentityIQ 9.0. Your narrow refresh also proves the valid role can provision LDAP access.

Provisioning proves access can be granted. Governance must also detect incompatible access before it becomes accepted risk.

You'll add an accountable certification decision that removes one conflicting role set. The predefined Leaver process then disables managed accounts when the identity becomes inactive.

In this step, get ready to:
  • Detect a toxic combination across two conflicting business roles.
  • Complete a targeted certification that revokes one conflicting role set.
  • Offboard the identity through the predefined Leaver process.
Create and detect conflicting access

Separation of Duties prevents one identity from holding access that creates an unacceptable concentration of power. A Role SOD policy makes that conflict visible for review.

  • Return to the business role editor from earlier.
  • Create an additional business role named your first conflicting business role name.
  • Create another business role named your second conflicting business role name.
  • Select Setup in IdentityIQ.
  • Select Policies.
  • Select New Policy.
  • Choose Role SOD as the policy type.
  • Create the policy with the name your Role SOD policy name.
  • Select Create New Rule.
  • Use Add Role to place your first conflicting business role name under Any of these roles.
  • Use Add Role to place your second conflicting business role name under conflict with any of these roles.
  • Save your Role SOD policy name.
  • Select Run Simulation.

You should see simulation results. The policy status changes to Inactive.

Why simulate before activation?

Simulation tests the enabled rule against current identity data. IdentityIQ changes the policy to Inactive after simulation.

Reactivating the policy allows later Identity Refresh tasks to evaluate the conflict.

  • Set the policy status back to Active.
  • Save the active policy.
  • Assign your first conflicting business role name to the selected training identity using the role-assignment control available in your lab.
  • Assign your second conflicting business role name to the same identity.
  • Return to the filtered Identity Refresh task from earlier.
  • Limit the task to the selected identity.
  • Select Check active policies.

Before you run the refresh, do you expect the active policy to detect one role or the combination of both roles?

  • Start the filtered refresh with Save and Execute.

The refresh evaluates the active policy for your selected identity. Its result records a violation for the conflicting role combination.

  • Open Policy Violations.
  • Confirm the active violation names the selected identity plus both conflicting business roles.

That is a key governance result. IdentityIQ now surfaces the toxic combination for an accountable decision.

Policy violation missing?

  • Confirm the simulation did not leave the policy Inactive.
  • Confirm both conflicting business roles are assigned to the selected identity.
  • Confirm the Identity Refresh included the selected identity plus Check active policies.

Help me diagnose the missing policy violation.

Certify and remediate the violation

A targeted certification turns the detected conflict into a recorded reviewer decision. For an SoD violation, the reviewer chooses which conflicting access remains.

  • Select the active violation on the open Policy Violations page.
  • Open Bulk Decisions.
  • Select Certify.

IdentityIQ opens Schedule Certification for the selected policy violation.

  • Scope the targeted certification to the selected identity.
  • Include policy violations in the certification.
  • Select Enable Revocation Period if your lab exposes that option.
  • Select Process Revokes Immediately when the target supports direct provisioning.
  • Create the certification using the page's scheduling control.

What does revocation tracking prove?

A revocation period tracks whether the requested removal reaches its remediation outcome. Immediate processing launches the revocation when the reviewer records the decision.

A connector can remove the access automatically. A target without direct provisioning can produce a manual work item instead.

  • Open the certification's access review.
  • Select Revoke for the SoD violation.
  • Choose one conflicting role as the access that remains.
  • Choose the other complete conflicting role set as the access to remove.
  • Submit the completed review using the certification's completion control.

The completed certification now records the reviewer decision. The remediation status shows automatic removal or a manual work item.

  • Complete the manual remediation work item if IdentityIQ generates one.
  • Capture redacted evidence of the remediation result.
  • Return to the selected Identity Cube.
  • Confirm the revoked conflicting role is absent.
  • Confirm the retained access matches the certification decision.

You have closed the governance loop. The toxic combination has an accountable decision plus a traceable remediation outcome.

Remediation still pending?

  • Check whether the certification generated a manual work item for the target application.
  • Check whether the certification used a tracked revocation period.
  • Confirm the review removed one complete conflicting role set.

Help me trace the pending remediation.

Enable the Leaver event and offboard the identity

A Lifecycle Event translates an identity data change into an access action. The predefined Leaver event triggers when inactive changes from false to true.

Its business process builds a plan to disable all managed accounts. This gives the final governance story a measurable offboarding result.

  • Select Setup.
  • Select Lifecycle Events.
  • Open the predefined Leaver event.
  • Confirm the event watches for inactive changing from false to true.
  • Confirm its business process disables managed accounts.
  • Enable the Leaver event.
  • Save the event.

Setting inactive to true starts offboarding for this identity. The test stays contained in your training lab.

  • Verify the selected record is your synthetic training identity.
  • Return to the authoritative source used earlier.
  • Set the selected identity's inactive attribute to true.
  • Return to the IdentityIQ browser lab.
  • Return to the authoritative application's Account Aggregation task.
  • Run the aggregation for the authoritative application.

The Account Aggregation Task Result should show the selected identity updated with inactive set to true.

  • Return to the filtered Identity Refresh task from earlier.
  • Limit the refresh to the selected identity.
  • Select Process Events.

Before you run the refresh, do you expect the Leaver process to leave the LDAP account enabled or start its disablement path?

  • Start the refresh with Save and Execute.

IdentityIQ processes the inactive change through the enabled Leaver event. The resulting workflow disables managed accounts or creates manual disablement work items.

  • Select Setup.
  • Select Tasks.
  • Open Task Results.
  • Open the Leaver workflow result for the selected identity.
  • Capture a redacted copy of the Leaver result.
  • Return to the selected Identity Cube.
  • Confirm the inactive attribute is true.
  • Confirm the managed LDAP account is disabled or represented by a documented manual work item.

Your lifecycle control now turns an authoritative employment state into a documented access outcome. That is the offboarding result an auditor can follow.

Leaver process did not run?

  • Confirm the predefined Leaver event is enabled.
  • Confirm aggregation changed inactive from false to true for the selected identity.
  • Confirm the filtered Identity Refresh included Process Events.

Help me diagnose the missing Leaver result.

The final evidence belongs in your private GitHub repository. Each artifact should prove one governance decision without exposing credentials or personal data.

What belongs in the repository?

  • The existing custom XML for the mover rule and workflow.
  • Redacted screenshots of the policy violation plus certification decision.
  • Redacted Task Result summaries for policy evaluation plus Leaver processing.
  • Remediation evidence showing automatic removal or the manual work item.
  • The existing evidence checklist with corresponding repository evidence.
  • Redact credentials from every new screenshot.
  • Redact personal data from every new Task Result summary.
  • Return to the private identityiq-governance-lab repository from earlier.
  • Open evidence-checklist.md.
  • Use the checklist to identify any missing governance evidence.

The checklist should now map each governance item to visible evidence in the repository.

  • Select Add file.
  • Select Upload files.
  • Upload the redacted evidence set described above.
  • Select Commit changes.

Before the final check, do you expect the Identity Cube plus repository to tell the same remediation and offboarding story?

  • Return to the final Identity Cube.
  • Verify the inactive attribute is true.
  • Verify the retained access matches the completed certification.
  • Verify the managed LDAP account is disabled or linked to a documented manual work item.
  • Return to the private evidence repository.
  • Verify each governance checklist item has corresponding synthetic or redacted evidence.

The final Identity Cube now matches the recorded governance decisions. Your repository preserves the evidence trail without exposing credentials or personal data.

You now have a complete governance lifecycle. The same identity has moved through access assignment, toxic-access detection, accountable remediation, and offboarding.

Secret mission

Reinstate the Identity Without Restoring Toxic Access

Offboarding proved that IdentityIQ can disable managed access. Now bring the identity back while keeping the remediated toxic role out. Your evidence should prove that reinstatement respects the earlier governance decision.

Clean Up Your Resources

Clean Up Your Resources

Your time-limited SailPoint IdentityIQ training lab and private GitHub repository add no incremental project charge. Choose whether to keep the lab objects active, pause their automation, or delete the custom configuration and repository.

Resources you used:

  • Department Attribute Change lifecycle event connected to NW Department Mover.
  • Workflow rule named NW Mover Decision.
  • IdentityLifecycle workflow named NW Department Mover.
  • Two-tier role model containing the valid business role plus its required IT role.
  • Two conflicting business roles used to demonstrate toxic access.
  • Active Role SOD policy used for detection plus remediation.
  • Lab-only task definitions created for filtered aggregation or refresh runs.
  • Private repository named identityiq-governance-lab containing redacted portfolio evidence.

Keep everything running

You do not need to change anything. Keep this setup if you want to rehearse the governance story before the training lab expires.

Your redacted repository remains available after the lab ends.

  • Keep the department Attribute Change lifecycle event enabled.
  • Keep the custom Role SOD policy active.
  • Keep identityiq-governance-lab private on GitHub.
  • Use the repository as evidence when demonstrating the correlation repair, mover workflow, remediation decision, or reinstatement result.

Pause - I'll come back to this later

Pause the controls that can act on future identity changes while keeping your configuration intact. Your Task Results plus redacted repository evidence remain available for review.

  • Return to the SailPoint IdentityIQ browser lab.
  • Select Setup.
  • Select Lifecycle Events.
  • Disable the department Attribute Change lifecycle event connected to NW Department Mover.

You should see the custom lifecycle event in a disabled state. Future department changes no longer launch the mover workflow.

  • Select Setup.
  • Select Policies.
  • Set the custom Role SOD policy to inactive.
  • Save the policy change.

You should see the custom policy in an inactive state. Future refreshes no longer evaluate that policy.

  • Leave all Account Aggregation tasks idle.
  • Leave all Identity Refresh tasks idle.
  • Keep identityiq-governance-lab private on GitHub.

Your governance evidence is preserved while the custom automation stays quiet.

Delete - I don't want to use this again

This cleanup permanently removes your custom governance configuration plus the private evidence repository. The preconfigured authoritative and LDAP applications remain untouched.

  • Return to the SailPoint IdentityIQ browser lab.
  • Select Setup.
  • Select Lifecycle Events.
  • Remove the department Attribute Change lifecycle event connected to NW Department Mover.
  • Confirm the custom event no longer appears on the Lifecycle Events page.

The mover workflow can no longer launch from a department change.

  • Select Setup.
  • Select Policies.
  • Remove the custom Role SOD policy.
  • Confirm the custom policy no longer appears on the Policies page.

The policy no longer evaluates identities or creates new violations.

  • Return to the role management area used earlier.
  • Remove each of the two conflicting business roles.
  • Remove the valid business role.
  • Remove the IT role containing the managed LDAP entitlement.
  • Confirm no project-created roles remain in the role management area.

Your custom role model is now removed from the lab.

  • Select Setup.
  • Select Business Processes.
  • Remove the workflow named NW Department Mover.
  • Confirm NW Department Mover no longer appears in the business process list.

The custom IdentityLifecycle workflow is now gone.

  • Return to the Debug pages through the wrench menu.
  • Open the Rule object list.
  • Remove the rule named NW Mover Decision.
  • Confirm a rule search no longer returns NW Mover Decision.

The workflow rule can no longer be referenced by a custom process.

  • Select Setup.
  • Select Tasks.
  • Remove only the task definitions you created specifically for this lab.
  • Confirm your lab-only task definitions no longer appear.

The lab keeps its original task definitions while your project-specific copies are removed.

  • Switch back to the identityiq-governance-lab repository.
  • Open the repository settings page.
  • Use the repository deletion control to remove identityiq-governance-lab.
  • Complete the repository-name confirmation that GitHub presents.
  • Return to the former repository URL to confirm the private repository no longer opens.

That completes the cleanup. The custom configuration covered here is gone from the lab, while the private repository no longer stores your evidence.

Nice Work!

Nice Work!

You did it! Your SailPoint IdentityIQ governance lab now follows one identity from authoritative ingestion through reinstatement while preserving its remediation history. Your private GitHub repository backs that story with redacted implementation files and test evidence.

You've learned how to:

  • Prove authoritative aggregation on a selected Identity Cube. Diagnose an uncorrelated LDAP account before repairing account correlation with a stable matching pair.
  • Model birthright access with linked business roles and IT roles. Route a department move through a custom BeanShell Workflow rule and an IdentityLifecycle workflow before recording role-based provisioning.
  • Detect toxic access with an active Role SOD policy. Capture an accountable certification decision. Record the remediation outcome. Prove leaver disablement with redacted evidence.
  • Secret Mission: Reinstate the identity while preserving the earlier remediation decision. The valid role returns. The toxic combination stays absent.

Ready to quiz yourself?