Approval Step for Role Assignment

IdentityIQ (IIQ) IIQ Discussion and Questions
, , ,
1

IIQ 8.3

Hello community,

I have a customized Mover workflow in SailPoint triggered by an attribute change (Position) and want to add an approval step before roles or entitlements are granted or revoked.

Currently, the workflow builds a provisioning plan to update target application attributes, runs the default LCM Provisioning workflow, and finishes with an Identity Refresh to correlate entitlements and synchronize attributes. The refresh task automatically assigns new Business and IT roles based on the Position attribute and removes the old roles.

Before we assign and remove Business roles and provision/deprovision the entitlements, I want to add an approval step for the entitlement owner or a specific population to review and approve or deny these entitlement changes. This would be useful, for example, if the identity needs to keep old access for additional time to complete the handover of their previous position.

Business roles are assigned based on Position, and IT roles are configured as required in each Business role.

Any guidance on implementing this approval process within the workflow? Or any suggestion on how to approach this matter? Do I need to have a step before the Identity Refresh task with a script to handle approvals, or should I modify the LCM Provisioning or its subprocesses to achieve this?

Thank you!

2

Hi @Moben,

Once the plan is built, add an additional approval step to your custom mover workflow. In this approval step, pass the necessary variables, and reference the workflow Provisioning Approval Subprocess. The ApprovalSet will be assigned based on the approvalScheme. Please refer the workflow step

   <Step icon="Approval" name="Approve" posX="511" posY="27">
    <Arg name="approvalScheme" value="ref:approvalScheme"/>
    <Arg name="identityEmailTemplate"/>
    <Arg name="formTemplate" value="Identity Update"/>
    <Arg name="securityOfficerElectronicSignature"/>
    <Arg name="fallbackApprover" value="ref:fallbackApprover"/>
    <Arg name="workItemHoursBetweenReminders"/>
    <Arg name="workItemPriority"/>
    <Arg name="workItemComments" value="ref:workItemComments"/>
    <Arg name="project" value="ref:project"/>
    <Arg name="identityRequestId" value="ref:identityRequestId"/>
    <Arg name="managerElectronicSignature"/>
    <Arg name="workItemDescription"/>
    <Arg name="identityDisplayName" value="ref:identityDisplayName"/>
    <Arg name="ownerElectronicSignature"/>
    <Arg name="foregroundProvisioning" value="ref:foregroundProvisioning"/>
    <Arg name="approvalMode" value="ref:approvalMode"/>
    <Arg name="trace" value="ref:trace"/>
    <Arg name="plan" value="ref:plan"/>
    <Arg name="flow" value="ref:flow"/>
    <Arg name="requireCommentsForApproval"/>
    <Arg name="identityElectronicSignature"/>
    <Arg name="identityName" value="ref:identityName"/>
    <Arg name="approvalSet" value="ref:approvalSet"/>
    <Arg name="manualActionsEmailTemplate"/>
    <Arg name="policyViolations"/>
    <Arg name="ownerEmailTemplate"/>
    <Arg name="filterRejects"/>
    <Arg name="workItemReminderTemplate"/>
    <Arg name="policyScheme" value="ref:policyScheme"/>
    <Arg name="priority" value="ref:workItemPriority"/>
    <Arg name="workItemEscalationTemplate"/>
    <Arg name="splitProvisioning"/>
    <Arg name="setPreviousApprovalDecisions"/>
    <Arg name="clearApprovalDecisions"/>
    <Arg name="saveUnmanagedPlan"/>
    <Arg name="noTriggers"/>
    <Arg name="workItemMaxReminders"/>
    <Arg name="requireCommentsForDenial"/>
    <Arg name="approvingIdentities"/>
    <Arg name="securityOfficerEmailTemplate"/>
    <Arg name="optimisticProvisioning" value="ref:optimisticProvisioning"/>
    <Arg name="workItemHoursTillEscalation"/>
    <Arg name="managerEmailTemplate"/>
    <Arg name="launcher" value="ref:launcher"/>
    <Description>Call the standard subprocess that will process the
      approval decisisions and do provisioning. This
      includes calling any configured
      provisioning
      connectors and building manual actions.</Description>
    <Return name="approvalSet" to="approvalSet"/>
    <Return name="workItemComments" to="workItemComments"/>
    <Return name="project" to="project"/>
    <WorkflowRef>
      <Reference class="sailpoint.object.Workflow" name="Provisioning Approval Subprocess"/>
    </WorkflowRef>
    <Transition to="Provision"/>
  </Step>
3 Likes
3

Hi @Arun-Kumar ,

Thank you so much for your response! really appreciate it.

I wanted to clarify something about my workflow. In the step where I build the Provisioning Plan, I’m not handling any roles or entitlements. Instead, I’m focusing on updating some attributes and then provisioning those changes. The step responsible for assigning roles and provisioning the entitlements is actually the Identity Refresh task.

<Step action="call:refreshIdentity" icon="Task" name="Refresh Identity" posX="215" posY="188">
  <Arg name="identityName" value="ref:identityName"/>
  <Arg name="provision" value="string:true"/>
  <Arg name="correlateEntitlements" value="string:true"/>
  <Arg name="synchronizeAttributes" value="string:true"/>
  <Description>Add arguments as necessary to enable refresh features. Typically you only want this to correlate roles and possibly provision if we notice new assigned roles. Note that provisioning will be done in the Identity Refresh workflow so if there are any provisioning forms to display we won’t feed them directly to the current user, they’ll have to return to the inbox.</Description>
  <Transition to="Stop"/>
</Step>

The Identity Refresh step is the one that handles the roles and entitlements, so I’m thinking the approval step should come before that task to ensure that roles and entitlements are only updated after approval.

4

Hi @Moben,

I would suggest keeping the Approval step before the Provisioning Plan step, because there might be a chance of executing the Identity Refresh task independently, outside the main workflow.

To prevent the possibility of roles and entitlements being assigned prematurely, it’s best to place the Approval step before the Provisioning Plan. This ensures that no roles or entitlements are provisioned until the changes are explicitly approved. This approach safeguards the process and ensures that the Identity Refresh task, which handles roles and entitlements, only runs after the necessary validation and approval have been completed.

1 Like