SailPoint Workflow

Lifecycle Manager Workflows This document describes the top-level workflows which are provided as part of Lifecycle Manager. It is intended to help customers understand the default functionality so they know whether and where they need to make modifications to meet their specific business requirements. These workflows all include long lists of variables which can be passed in, or set in the workflows as defaults, to affect their functionality without having to apply any workflow step customizations; these variables are described in detail here, along with their impact on the workflows.

Introduction Workflows drive all provisioning functionality in Lifecycle Manager (LCM). IdentityIQ includes some default workflows so that LCM is fully-functional out of the box. Those default workflows are designed to be flexible to meet many customers' business needs with little to no customization required. They include an array of variables which can be set as needed to drive the desired functionality, such as how to manage approvals, whom to notify of various occurrences in the provisioning process, what email templates to use in those notifications, and many others. This document explains the default workflows so customers can better understand what the default processes are, how they can control them without doing any custom workflow development, and where they might need to modify the default workflows' processes for their own specific business needs. Note that when making any customizations to these workflows -- even changing the values set for workflow variables, customers are strongly advised to copy the default workflows and rename them to their own custom workflow names. For example, ACME Corporation could clone the LCM Provisioning workflow and call it "ACME LCM Provisioning".

LCM Workflow Process and Structure Multiple default workflows exist to support each type of provisioning activity in LCM. For example, one workflow controls provisioning of new accounts and changes to accounts (e.g. entitlement changes, enable/disable operations), another workflow controls password resets, and a third controls creation and editing of identities and identity attributes. In general, these workflows follow the same basic process, but they differ in some small details. To promote code reuse, the core functions needed across multiple processes have been encapsulated in subprocesses which can be called by each of the main "top-level" workflows. This allows the main workflows to include their needed variances while maximizing uniformity across the processes. The organization of these subprocesses also makes it easy to customize the workflows for individual customer needs by using the desired modules and skipping others.

1. 2. 3. 4. 5.

The overall process flow for the default LCM workflows is this, with each of these process steps being controlled by a separate subprocess workflow: Initialize: Compile the provisioning plan, set up the identity request, perform initial auditing, check policies, do pre-approval data gathering Approve: Gather approvals from the appropriate parties and filter the provisioning project to remove non-approved items Provision: Do post-approval data gathering and complete the provisioning actions to update the target systems Notify: Send emails to interested parties informing them of the final status of the provisioning request Finalize: Mark the identity request with the final status of the provisioning request, perform final auditing

Each of the top-level workflows is examined and explained in detail below. The subprocess workflows are explored in detail in a separate document: LCM Subprocess Workflows. Each subprocess in that document is also linked to its usage in this document to facilitate navigation between the two articles and make the processes easy to explore and understand.

Setting Top-level Workflows The top-level workflows used by LCM are configured on the System Setup > Lifecycle Manager Configuration > Business Processes page in the IdentityIQ user interface.

   

There are four main default LCM workflows which are applied to complete the required provisioning actions, depending on the origin of the provisioning request: LCM Provisioning LCM Manage Passwords LCM Create and Update LCM Registration As shown here, the same workflow can be used to drive provisioning in response to different starting events. For example, by default, LCM Provisioning handles requests coming from the Request Access LCM option (role and entitlement requests) as well as Manage Accounts requests (new accounts or enable/disable/unlock/delete requests), among others.

Business Processes Configuration Page

Implementing a custom workflow for any of these functional areas in a specific customer implementation requires creating the workflow (often by cloning and modifying these core workflows) and pointing IdentityIQ to the custom workflow through this user interface page. Understanding how the default workflows work is critical to successfully modifying the processes to meet specific customer needs.

Subprocess Workflows As noted, each of these top-level, or master, workflows performs much of its functionality through calls to subprocess workflows. Hyperlinks embedded in the Workflow Steps sections of each of these workflow descriptions take the reader directly to the specific subprocess's description in the LCM Subprocess Workflows document. That document can also be read independently to understand the actions being performed within the various subprocess workflows.

Workflow Variables

Workflow variables defined in each of the provided workflows, master and subprocess, can be used to control certain aspects of their behaviors. For example, the variables can specify which users are involved in approval processes, which users receive notification of the workflow status, and whether policy violations detected in evaluating the request should terminate the request processing, among many others. Some of these variable values are passed in as arguments to the workflow, while others are specified in the static workflow definition to set default behaviors for the installation.

Passing Variable Values between Workflows and Subprocesses Workflow steps which call subprocesses can specify elements and elements. Args are used to pass variable values to a subprocess from the parent workflow, and Returns are used to pass variable values back to the parent workflow from the subprocess. These elements are the sole determinants for what variables values are passed to and from the subprocess. Subprocesses may have various variables marked as input or outputvariables, but those flags are primarily used for documentation. Omitting the "input" flag does not prevent a calling workflow from passing in a value and overriding the default value for a variable in a subprocess, and marking the "output" flag does not mean that the value of that variable will automatically be passed back to the parent workflow when the subprocess ends.

Variable Declarations in Workflows It is a best practice to declare all variables which will be used in any workflow -- master or subprocess. This includes declaring all variables in a subprocess which are being passed in as arguments from the parent workflow. When variables are not declared but are passed in as arguments to a subprocess, they are still present in the workflow context; consequently, they can often be used in the workflow despite not being declared (for example, they can be referenced in script steps within the workflow). However, in some cases, the workflow engine cannot resolve undeclared variables, such as when they are referenced in arguments to workflow steps which call other subprocesses, workflow library methods, or rules. Declaring all variables in workflows simplifies the workflow development process, improves the self-documentation of the workflow, and helps with long-term workflow maintenance. Despite the fact that the input and output flags do not control the workflow variables' usages, it is also a best practice to mark as input variables all those which are expected as potential inputs to the workflow and to mark as output variables all those which are usually specified as Return elements when the workflow is called. This is recommended because of the benefit it provides to developers who may later need to make adjustments to the workflows' functionality; a clear understanding of which variables should be passed to and returned from each process will make it easier to successfully support and modify the workflows. NOTE: The output flag has one other usage -- on toplevel workflows, variables declared as with the output flag are available for inclusion in the task result data recorded for the workflow execution.

LCM Provisioning (7.0+) The LCM Provisioning workflow provides the core functionality for provisioning (and deprovisioning) roles and entitlements. It also drives the process of provisioning new accounts on managed applications and of making changes to existing user accounts on those applications; this can include unlocking, enabling, disabling, and deleting those accounts. The LCM Provisioning workflow was refactored in version 7.0 to support splitting a provisioning plan so that components of the plan can be provisioned immediately even when other parts of the request are still pending approval. Customers using version 6.4 and earlier versions should refer to the LCM Provisioning (Pre 7.0) description below instead. The LCM Provisioning workflow is illustrated in the Business Process Editor like this: This workflow follows the full core process for LCM Workflows, which includes these key steps: 1. 2. 3. 4. 5.

Initialize Approve Provision Notify Finalize Each of those steps is performed through calls to subprocesses. Other auxiliary functions are performed in this workflow depending on arguments passed to the workflow.

1.

LCM Provisioning (7.0+) Workflow Steps

Like most workflows, this workflow begins with an empty Start step -- a placeholder step which contains no logic. In general, the recommended best practice is to start all workflows with an empty Start step which exists only to give a visual indicator of where the workflow process begins. 2. The next step, Initialize, calls the Identity Request Initialize subprocess workflow. The most important task of this subprocess is to compile the provisioning plan into a provisioning project. Another major purpose of this subprocess is to create the IdentityRequest object which will make it possible for the requester and the requestee to follow the progression of the request. Identity requests contain information like approvals required and their current status, expansion details for

fulfilling the request, whether the request enters a retry loop or a queued state, and more. Additionally, this subprocess performs policy checking, as directed by the workflow variables, 3. The next step for the workflow depends on results of the Initialize workflow. There are 3 available exits for the process at this point, examined and taken in this order:  Exit on Policy Violation - If the workflow variable policyScheme is set to "fail" and the policy analysis in the Initialize subprocess found policy violations or if the policy analysis prompted the requester with an option to abort the request due to policy violations and the user chose that option, this step sets an error message which will be reported to the requester through the user interface, and the provisioning process terminates.  Exit on Provisioning Form - If the workflow variable endOnProvisioningForms is set to "true" and the provisioningProject returned by the Initialize step includes any unanswered questions, which required creation of IdentityIQ work items assigned to a user to gather required data to complete the provisioning action, this step sets an error message which will be reported to the requester through the user interface, and the provisioning process terminates.  Exit on Manual Work Item - If the workflow variable endOnManualWorkItem is set to "true" and the provisioningProject returned by the Initialize step includes an unmanagedPlan, which required creation of an IdentityIQ work item assigned to a user to complete the provisioning action, this step sets an error message which will be reported to the requester through the user interface, and the provisioning process terminates. 4. If none of the exits is taken, the next step in the process is the Create Ticket step. This step calls the Manage Ticket subprocess. However, this step is only executed if the workflow was called from an integration with a ticketing system, in which case the workflow variable ticketManagementApplication is non-null (it names the ticketing application); otherwise, the workflow proceeds to the next step. 5. Version 7.0 introduced the option to split the provisioning plan into individual line-item components during the approval process, at this point in the flow. Historically, an LCM access request was processed as a unit for each target user. For example, if the requester selected 5 entitlements together in the cart, the provisioning of all 5 entitlements would occur at once, and only after the approvals for all 5 entitlements had been completed. If one entitlement's owner was slow to respond, the other 4 entitlements would also have to wait to be provisioned until the fifth was approved or rejected. In version 7.0, the workflow can be configured to split the provisioning plan (the cart) into its component pieces at any step in the approval process. If, for example, the approvalScheme is "manager, owner", the manager approval could be left as one unit but the owner approval could be processed per owner. Then, each of the 5 entitlement can be provisioned as its approval gets completed. 

Branching of this workflow depends on a variable called approvalSplitPoint. When approvalSplitPoint is set to an approvalScheme value which exists in the approvalScheme variable, the workflow proceeds to the Pre Split Approve step (step 6 below). Otherwise, it goes to the Approve and Provision step (step 10 below).



NOTE: The split occurs based on the approval, which is built from the original cart, so in a role request which requires provisioning of multiple entitlements, the role gets approved and all entitlements within that role are still provisioned as a unit.



Example: approvalSplitPoint = "owner" and approvalScheme = "manager, owner, securityOfficer" -> workflow proceeds to Pre Split Approve 6. If there are any approvalScheme values in the list before the split point named in approvalSplitPoint, those approvals should be processed with an unsplit plan (i.e. all items go together in one plan to the approval process, and all items wait until the whole set has been approved before any further processing occurs on them). The Pre Split Approve step examines the approvalScheme for the approvalSplitPoint value and calls the Provisioning Approval Subprocess, passing it only the approvalScheme values specified before the named split point. The purpose of this subprocess is to get approval from the required people before provisioning the request. 

In the example given above, this step would call Provisioning Approval Subprocess with approvalScheme = "manager".



NOTE: This step is bypassed for account unlock requests (when the flow variable is set to "UnlockAccount").

7.

Next, the Split Plan step calls the workflow library method splitProvisioningPlan to parse the request into individual plans according to the approvers for the component items. The rest of the approval process and the actual provisioning process will be split according to these plans.



For example, if the request contained 5 entitlements, this step would split the plan into 5 plans, one per entitlement. The rest of the approval process and the provisioning would occur separate for each of the 5 plans. 8. The next step is the Approve and Provision Split step. This step makes use of the Step Replicator functionality introduced in version 7.0. It uses the list of plans generated in the Split Plan step and calls the Approve and Provision Subprocess once for each of those plans, launching the subprocess workflows simultaneously. The rest of the approvals and the provisioning for each of those plans happens in that subprocess. 9. When all instances of the Approve and Provision Subprocess have finished, the LCM Provisioning workflow proceeds to the Assimilate Splits step. This step calls the workflow library method joinLCMProvWorkflowSplits, which combines the approval sets, provisioning plans, and work item comments from the individual subprocess executions back into the master objects in the LCM Provisioning workflow. It also update the identity request object with remaining details from processing the requests so the requester and requestee can see the updated status information in the user interface. The workflow then proceeds to the Refresh Identity step (step 11 below). 10. When the workflow does not specify an approvalSplitPoint variable value, the Approve and Provision step is executed instead of the last 4 steps described above. This step executes the Approve and Provision Subprocess to complete the approval and provisioning for the whole request, as a single unit. Though this step uses the same subprocess as the Approve and Provision Split step, it calls that subprocess only once with the whole plan instead of once for each split plan. 11. The two paths for provisioning rejoin at this point. Next, the Refresh Identity step of the workflow can optionally perform a targeted identity refresh on the identity for whom the provisioning action was processed. By default, this refresh is not performed, but it can be turned on by setting the doRefreshworkflow variable to "true". The step is preconfigured to update the user's role assignments and detections when it runs, and other options can be added to this refresh task as needed. Most customers do not enable this step, instead letting the next Identity Refresh task handle the role assignments and detections at a later time, but this option exists to allow the installations to update these related data points on the identity immediately if they so desire. 12. The Notify step comes next. This step calls the Identity Request Notify subprocess to send emails to various system users, notifying them of the final status of the request. The notificationScheme workflow variable determines which users are notified, and the email templates to use for the notifications can be set through other LCM Provisioning workflow variables (passed as arguments to the subprocess through this Notify step) or can be left under the control of workflow variables predefined in the subprocess itself. 13. The last execution step in this workflow, before the placeholder End step, is the Finalize step, which calls the Identity Request Finalize subprocess. The Finalize step is always executed before the workflow terminates, even if it terminates with a catastrophic error condition. The two main purposes of the Identity Request Finalize subprocess are to update the Identity Request with the final dispensation of the request and to audit the provisioning action if that audit action has been turned on in the Audit Configuration. 14. The final step in this workflow is the End step, which like the Start step, is an empty placeholder step which contains no logic.

LCM Provisioning (7.0+) Workflow Variables

These tables list the workflow variables available to the LCM Provisioning workflow and the impact each can have on the process. The variables are organized into separate tables according to their functional purposes.

Workflow Flow Control Variables Variable Name identityName

Default Value -

Purpose

REQUIRED ARGUMENT*; Name of the identity being provisioned. Th

Variable Name

Default Value

Purpose

the LCM shopping cart, but could be passed in as a workflow variab from a custom workflow. This variable is required as an input to th subprocess called in the first action step of this workflow.

-

REQUIRED ARGUMENT*; Representation of the requested items to typically provided by the LCM shopping cart but can also be passed when calling this workflow from a custom workflow. Throughout th compiled and expanded into a provisioningProject, will go through provisioned.

approvalSplitPoint

-

ApprovalScheme value on which the approval process, and subseq should be split so each entitlement can be approved and provision timeline from the other entitlements in the request; this is use to p process for one entitlement from delaying the provisioning for othe the same access request. The value specified in approvalSplitPoint must be one of the value approvalScheme for this variable to be applied and cause the work approval branch.

doRefresh

false

Flag which causes the workflow to run a targeted identity refresh a to refresh role assignments and detections for the user; off by defa

endOnManualWorkIte ms false

Flag which causes the workflow to terminate after plan compilation any manual provisioning activities (Manual provisioning requires a assigned to a user to process; this is how IdentityIQ supports provi system.)

endOnProvisioningFor ms false

Flag which causes the workflow to terminate after plan compilation require attributes which cannot be auto-calculated and therefore w prompted for attribute values through a work item

flow

-

Name of the process flow which initiated this request. When invok interface, this is one of several predefined values, but it is not an e value for custom usages of this workflow (e.g. when it is invoked fr event). Values from LCM are AccountsRequest, EntitlementsReques UnlockAccount. NOTE: If this value is UnlockAccount, the workflow subprocess step.

-

The ID of the individual request in the batch file when the request This is used by the batch interface to record the individual request batch request.

plan

batchRequestItemId

optimisticProvisioning false

Flag which makes the workflow treat the provisioning process as su queued status; usually used for demo mode, but occasionally used through a ticketing system or provisioning system which are not fr IdentityIQ

foregroundProvisionin g true

Flag which keeps provisioning in the foreground so the provisioning when control is returned to the user; otherwise, provisioning steps releasing the requester's session while the provisioning actions tak efficient for users in a production environment. This flag is usually development/testing environments and in demo mode.

*The identityName and plan variables are not technically required by the LCM Provisioning workflow itself, but they are required inputs to the Identity Request Initialize workflow which is executed as the first step of the LCM Provisioning workflow. Therefore, either these two attributes must be provided to this workflow as arguments or the default LCM Provisioning workflow must be edited to add a step before the Initialize step which calculates the identityName and plan. The LCM user interface options all submit an identityName and plan automatically.

Policy Checking Control Variables

Variable Name

Default Value

Purpose

Action the workflow should take if any policy violations are analysis in the Identity Request Initialize subprocess. Valid none: disable policy checking

continue: process the request anyway, even if violat

interactive: allow the requester to remove request it violations before processing the rest of the request policyScheme

continue

fail: terminate the workflow without processing the r are found; requester is not notified that the workflow has te

policiesToCheck

-

List of specific policies to check in the policy analysis proce policies are checked

allowRequestsWithViolations true

Flag which specifies whether requesters should be able to p Violation Review form without taking any action on policy v request. This is only relevant when policyScheme is set to i

requireViolationReviewComm ents true

Flag which specifies whether the requester must enter com request that will result in a policy violation. This is only rele set to interactive.

remediate: user removed the requeste items that we violationReviewDecision

policyViolations

-

cancel: user abandoned the request, terminating the

-

List of policy violations found during the policy analysis ste each work item so approvers can see pending violations wh the request.

Ticket System Control Variables Variable Name

Default Value

Purpose

ticketManagementApplica tion -

Name of the application that can handle ticket requests; Ident ticket there throughout the provisioning process.

ticketId

ID of the ticket generated by the ticketManagementApplicatio when the ticket is first created and is used to update the ticke related steps of the workflow. The value is also stored in the I externalTicketId.

-

Approval Control Variables Variable Name approvalMode

Default Value parallel

Purpose

Structure for managing the approval process. Valid v its subprocesses are:

serialPoll: assign work item to approvers one a decision is made only after all approvers have provide

parallelPoll: assign work items to all approver s is made only after all approvers have provided their i

any: assign work items to all approvers simulta by the first responder is acted upon as the final decis

serial: assign work item to approvers one at a out any rejected items before passing to next approv subsequent approvers are never notified or prompted

parallel: assign work items to approvers at the rejected by one, other approvers' work items will be d requiring their review, however individual line items a

Variable Name

Default Value

Purpose approvals when rejected by other approvers. NOTE: The default behavior for poll decisions is that results in rejection of requested item.

CSV list of approvers to include in the approval proce

owner: object owner is prompted for approval; request into multiple approval work items since differ be owned by different users

manager: the target user's manager is prompt items are submitted together in one approval work ite

securityOfficer: the identity named in the varia prompted for approval; all requested items are subm one approval work item

identity: looks for another workflow variable ca includes those identities in the approval process; all r submitted to each of these users together in one app

approvalScheme

owner

none: disables all approvals (overrides the oth included in the list) If more than one of these are specified together in th according to the approvalMode. In serial or serialPoll in the order they are specified in this list. In versions prior to 6.2, which used the Identity Reque approvals, they were always processed in the order: m officer, and the identity option did not apply.

approvalEmailTemplate

LCM Identity Update Approval

Email template to use when sending notification ema

spadmin

Name of the identity who will be assigned any approv cannot be resolved (e.g. an "owner" approval where t owner attribute or a securityOfficer approval with no specified)

filterRejects

true

Causes rejected items to be filtered from subsequent SerialPoll modes so that anything rejected by one app subsequent approvers in the chain

securityOfficerName

-

Name of the identity to use in a securityOfficer appro includes securityOfficer)

fallbackApprover

managerElectronicSignature -

Name of the electronic signature object to attach to t approvals; contains the legal text to which the manag sign off on the approval

ownerElectronicSignature

-

Name of the electronic signature object to attach to t approvals; contains the legal text to which the owner off on the approval

securityOfficerElectronicSign ature -

Name of the electronic signature object to attach to t officer approvals; contains the legal text to which the when they sign off on the approval

approvalSet

The approvalSet object which represents all of the lin approval; this is created by the Identity Request Initia collect the final approval status of each requested ite can be modified before provisioning occurs to remove rejected by approvers.

-

Provisioning Control Variables

Variable Name

enableRetryRequest

Default Value

Purpose

Flag which disables the workflow retry loop (in the Provision w causes the Provision step to create Request objects to handle provisioning attempts fail in a retryable state. In older version provisioning was managed through Request objects. While m newer retry loop process, as managed by the Provision with Re customers who wish to use the older functionality can use this management style.

-

Notification Control Variables Variable Name

Default Value

Purpose

CSV list of users who should be notified of the final status o once its processing is complete. Valid values include:

user: notify the target user (the person whose acces

requester: notify the requester (the person who initi through the Lifecycle Manager user interface pages) manager: notify the target user's manager

user, requester

securityOfficer: notify the user specified in the secur variable As many of these four may be specified as desired. The Id subprocess sends emails to the specified users.

userEmailTemplate

LCM User Notification

Email template to use when notifying the target user of the provisioning request

requesterEmailTemplate

LCM Requester Notification

Email template to use when notifying the requester of the provisioning request

managerEmailTemplate

LCM Manager Notification

Email template to use when notifying the target user's man the provisioning request

notificationScheme

securityOfficerEmailTempl ate -

Email template to use when notifying the security officer o provisioning request

Other Workflow Variables Variable Name

Default Value

Purpose

displayName of the identity named in identityName

Display name of the identity being upda an input argument; otherwise, it is autom displayName of the identity named in th the workflow.

-

The name of the identity request object of this provisioning request. The Identity various steps throughout the process an provisioning process ends. Note that tho identityRequestId, it is not the GUID for t it is an incrementally assigned number s object.

LCM

Source indicating where the request orig representation of the sailpoint.object.So Javadocs for an up-to-date list of valid va

workItemComments

-

Global comments accumulated during th shared with all approvals. When a new a comments in this list will be added to th

project

-

ProvisioningProject representation of the

identityDisplayName

identityRequestId

source

Variable Name

Default Value

Purpose

This contains all the details required to f is built by the plan compiler as it perform whether account creation requests are n provisioning policies, and determines the channels for each target application. A also included in the provisioningProject.

splitPlans

splitProjects

splitApprovalSet

splitWorkItemComments

workItemPriority

trace

-

List of ProvisioningPlans when request g for approval and provisioning (when app populated by the Split Plans step

-

List of ProvisioningProjects built from the Approve and Provision Split step's calls t Subprocess when approvalSplitPoint is s

-

List of ApprovalSet objects returned from Split step's calls to the Approve and Prov approvalSplitPoint is set

-

List of WorkItemComment objects return Provision Split step's calls to the Approve when approvalSplitPoint is set

Normal

Attribute to mark on each work item gen which designates its priority relative to o attribute can be used to sort work items list; it does not affect the order in which any system-driven parts of the processe High, and Low.

false

This attribute turns on trace logging for by the workflow handler. When trace is of all workflow variables is printed when messages indicating the start and end o are logged as well. This can be extremel during workflow development, as it help occurring. These statements are written

LCM Provisioning (Pre 7.0) The LCM Provisioning workflow provides the core functionality for provisioning (and deprovisioning) roles and entitlements. It also drives the process of provisioning new accounts on managed applications and of making changes to existing user accounts on those applications; this can include unlocking, enabling, disabling, and deleting those accounts. This section pertains to the LCM Provisioning workflow as it existed prior to version 7.0 of IdentityIQ; the 7.0+ structure of this workflow is documented above.

Its flow is illustrated in the Business Process Editor like this: This workflow follows the full core process for LCM Workflows, which includes these key steps: 1. 2. 3. 4. 5.

Initialize Approve Provision Notify Finalize

Each of those steps is performed through calls to subprocesses. Other auxiliary functions are performed in this workflow depending on arguments passed to the workflow.

1. 2.

3. 





4.

5.

6.

7. 8.

9.

LCM Provisioning (Pre 7.0) Workflow Steps

Like most workflows, this workflow begins with an empty Start step -- a placeholder step which contains no logic. In general, the recommended best practice is to start all workflows with an empty Start step which exists only to give a visual indicator of where the workflow process begins. The next step, Initialize, calls the Identity Request Initialize subprocess workflow. The most important task of this subprocess is to compile the provisioning plan into a provisioning project. Another major purpose of this subprocess is to create the IdentityRequest object which will make it possible for the requester and the requestee to follow the progression of the request. Identity requests contain information like approvals required and their current status, expansion details for fulfilling the request, whether the request enters a retry loop or a queued state, and more. Additionally, this subprocess performs policy checking, as directed by the workflow variables, The next step for the workflow depends on results of the Initialize workflow. There are 3 available exits for the process at this point, examined and taken in this order: Exit on Policy Violation - If the workflow variable policyScheme is set to "fail" and the policy analysis in the Initialize subprocess found policy violations or if the policy analysis prompted the requester with an option to abort the request due to policy violations and the user chose that option, this step sets an error message which will be reported to the requester through the user interface, and the provisioning process terminates. Exit on Provisioning Form - If the workflow variable endOnProvisioningForms is set to "true" and the provisioningProject returned by the Initialize step includes any unanswered questions, which required creation of IdentityIQ work items assigned to a user to gather required data to complete the provisioning action, this step sets an error message which will be reported to the requester through the user interface, and the provisioning process terminates. Exit on Manual Work Item - If the workflow variable endOnManualWorkItem is set to "true" and the provisioningProject returned by the Initialize step includes an unmanagedPlan, which required creation of an IdentityIQ work item assigned to a user to complete the provisioning action,this step sets an error message which will be reported to the requester through the user interface, and the provisioning process terminates. If none of the exits is taken, the next step in the process is the Create Ticket step. This step calls the Manage Ticket subprocess. However, this step is only executed if the workflow was called from an integration with a ticketing system, in which case the workflow variable ticketManagementApplication is non-null (it names the ticketing application); otherwise, the workflow proceeds to the next step. Next, the Approve step calls the Provisioning Approval Subprocess. In earlier versions of IdentityIQ (6.1 and before), the Identity Request Approvesubprocess was used instead. Though their processing details differ, the purpose of both of these subprocesses is to get approval from the required people before provisioning the request. This step is bypassed for account unlock requests (when the flow variable is set to "UnlockAccount"). The next step is the Update Ticket Post Approval step, which is only executed if the workflow contains a ticketManagementApplication value (i.e. if it was called from an integration with a ticketing system). This step calls the Manage Ticket subprocess, just like the Create Ticket step above did. The most important step in the process comes next: the Provision step. This calls the Identity Request Provision subprocess workflow to provision the access request to the target system(s). Once provisioning is complete (whether it succeeds or fails), the next step is Update Ticket Post Provision. As with the Create Ticket and Update Ticket Post Approval steps, this step is only relevant, and only executed, if the workflow was invoked by a ticketing system and the ticketManagementApplication variable is non-null. In that case, this step calls the Manage Ticket subprocess once more. Next, the Refresh Identity step of the workflow can optionally perform a targeted identity refresh on the identity for whom the provisioning action was processed. By default, this refresh is not performed, but it can be turned on by setting the doRefresh workflow variable to "true". The step is preconfigured to update the user's role assignments and detections when it runs, and other options

can be added to this refresh task as needed. Most customers do not enable this step, instead letting the next Identity Refresh task handle the role assignments and detections at a later time, but this option exists to allow the installations to update these related data points on the identity immediately if they so desire. 10. The Notify step comes next. This step calls the Identity Request Notify subprocess to send emails to various system users, notifying them of the final status of the request. The notificationScheme workflow variable determines which users are notified, and the email templates to use for the notifications can be set through other LCM Provisioning workflow variables (passed as arguments to the subprocess through this Notify step) or can be left under the control of workflow variables predefined in the subprocess itself. 11. The last execution step in this workflow, before the placeholder End step, is the Finalize step, which calls the Identity Request Finalize subprocess. The Finalize step is always executed before the workflow terminates, even if it terminates with a catastrophic error condition. The two main purposes of the Identity Request Finalize subprocess are to update the Identity Request with the final dispensation of the request and to audit the provisioning action if that audit action has been turned on in the Audit Configuration. 12. The final step in this workflow is the End step, which like the Start step, is an empty placeholder step which contains no logic.

LCM Provisioning (Pre 7.0) Workflow Variables These tables list the workflow variables available to the LCM Provisioning workflow and the impact each can have on the process. The variables are organized into separate tables according to their functional purposes.

Workflow Flow Control Variables Variable Name

Default Value

Purpose

-

REQUIRED ARGUMENT*; Name of the identity being provisioned. Th the LCM shopping cart, but could be passed in as a workflow variab from a custom workflow. This variable is required as an input to th subprocess called in the first action step of this workflow.

plan

-

REQUIRED ARGUMENT*; Representation of the requested items to typically provided by the LCM shopping cart but can also be passed when calling this workflow from a custom workflow. Throughout th compiled and expanded into a provisioningProject, will go through provisioned.

doRefresh

false

Flag which causes the workflow to run a targeted identity refresh a to refresh role assignments and detections for the user; off by defa

endOnManualWorkIte ms false

Flag which causes the workflow to terminate after plan compilation any manual provisioning activities (Manual provisioning requires a assigned to a user to process; this is how IdentityIQ supports provi system.)

endOnProvisioningFor ms false

Flag which causes the workflow to terminate after plan compilation require attributes which cannot be auto-calculated and therefore w prompted for attribute values through a work item

flow

-

Name of the process flow which initiated this request. When invok interface, this is one of several predefined values, but it is not an e value for custom usages of this workflow (e.g. when it is invoked fr event). Values from LCM are AccountsRequest, EntitlementsReques UnlockAccount. NOTE: If this value is UnlockAccount, the workflow subprocess step.

-

The ID of the individual request in the batch file when the request This is used by the batch interface to record the individual request batch request.

identityName

batchRequestItemId

optimisticProvisioning false

Flag which makes the workflow treat the provisioning process as su

Variable Name

Default Value

Purpose

queued status; usually used for demo mode, but occasionally used through a ticketing system or provisioning system which are not fr IdentityIQ

Flag which keeps provisioning in the foreground so the provisioning when control is returned to the user; otherwise, provisioning steps releasing the requester's session while the provisioning actions tak efficient for users in a production environment. This flag is usually development/testing environments and in demo mode.

foregroundProvisionin g true

*The identityName and plan variables are not technically required by the LCM Provisioning workflow itself, but they are required inputs to the Identity Request Initialize workflow which is executed as the first step of the LCM Provisioning workflow. Therefore, either these two attributes must be provided to this workflow as arguments or the default LCM Provisioning workflow must be edited to add a step before the Initialize step which calculates the identityName and plan. The LCM user interface options all submit an identityName and plan automatically.

Policy Checking Control Variables Variable Name

Default Value

Purpose




continue


policiesToCheck

-






Decision made by the user in the Policy Violation Review st Initialize. Valid values are:

ignore: user is ignoring the violations and processing require comments, and can only be selected if allowed by a flag)


policyViolations

-


-


Ticket System Control Variables Variable Name ticketManagementApplica -

Default Value

Purpose

Name of the application that can handle ticket requests; Ident

Variable Name

Default Value

Purpose

tion

ticket there throughout the provisioning process.

ticketId

ID of the ticket generated by the ticketManagementApplicatio when the ticket is first created and is used to update the ticke related steps of the workflow. The value is also stored in the I externalTicketId.

-

Approval Control Variables Variable Name

Default Value

Purpose

Structure for managing the approval process. Valid v its subprocesses are:

serialPoll: assign work item to approvers one a decision is made only after all approvers have provide

parallelPoll: assign work items to all approver s is made only after all approvers have provided their i

approvalMode

parallelPoll

any: assign work items to all approvers simulta by the first responder is acted upon as the final decis In the poll modes, the workflow is responsible for ass decisions and determining the action to take; the out precedence to rejection, so if any approver rejects a l provisioned.

CSV list of approvers to include in the approval proce

owner: object owner is prompted for approval; request into multiple approval work items since differ be owned by different users

manager: the target user's manager is prompt items are submitted together in one approval work ite

securityOfficer: the identity named in the varia prompted for approval; all requested items are subm one approval work item

identity: looks for another workflow variable ca includes those identities in the approval process; all r submitted to each of these users together in one app

approvalScheme

owner

none: disables all approvals (overrides the oth included in the list) If more than one of these are specified together in th according to the approvalMode. In serialPoll mode, th order they are specified in this list. In versions prior to 6.2, which used the Identity Reque approvals, they were always processed in the order: m officer, and the identity option did not apply.



Email template to use when sending notification ema

fallbackApprover

spadmin

Name of the identity who will be assigned any approv cannot be resolved (e.g. an "owner" approval where t owner attribute or a securityOfficer approval with no specified)

securityOfficerName

-

Name of the identity to use in a securityOfficer appro includes securityOfficer)

managerElectronicSignature -

Name of the electronic signature object to attach to t approvals; contains the legal text to which the manag

Variable Name

Default Value

Purpose sign off on the approval

-

Name of the electronic signature object to attach to t approvals; contains the legal text to which the owner off on the approval

securityOfficerElectronicSign ature -

Name of the electronic signature object to attach to t officer approvals; contains the legal text to which the when they sign off on the approval

approvalSet

The approvalSet object which represents all of the lin approval; this is created by the Identity Request Initia collect the final approval status of each requested ite can be modified before provisioning occurs to remove rejected by approvers.

ownerElectronicSignature

-

Provisioning Control Variables Variable Name

enableRetryRequest

Default Value

Purpose

Flag which disables the workflow retry loop (in the Provision w causes the Provision step to create Request objects to handle provisioning attempts fail in a retryable state. In older version provisioning was managed through Request objects. While m newer retry loop process, as managed by the Provision with Re customers who wish to use the older functionality can use this management style.

-


Default Value

Purpose




notificationScheme

user, requester


userEmailTemplate











Other Workflow Variables Variable Name identityDisplayName

Default Value displayName of the identity named in

Purpose

Display name of the identity being upda

Variable Name

Default Value

identityName

Purpose

an input argument; otherwise, it is autom displayName of the identity named in th the workflow.

identityRequestId

The name of the identity request object of this provisioning request. The Identity various steps throughout the process an provisioning process ends. Note that tho identityRequestId, it is not the GUID for t it is an incrementally assigned number s object.

source


LCM

workItemComments

Global comments accumulated during th shared with all approvals. When a new a comments in this list will be added to th

project

ProvisioningProject representation of the This contains all the details required to f is built by the plan compiler as it perform whether account creation requests are n provisioning policies, and determines the channels for each target application. A also included in the provisioningProject.

workItemPriority

Normal


false


trace

LCM Manage Passwords The LCM Manage Passwords workflow manages provisioning of password changes and password resets for passwords on applications managed by IdentityIQ. Its flow is illustrated in the Business Process Editor like this: This workflow follows most of the core process for LCM workflows, but it skips the approval step since password changes generally do not require approvals and would not really have any details to show to the approver in any case. Thus, the key steps in the LCM Manage Passwords workflow are: 1. 2. 3.

Initialize Provision Notify

4.

Finalize Each of those steps is performed through calls to subprocesses. Other auxiliary functions are performed in this workflow depending on arguments passed to the workflow.

LCM Manage Passwords Workflow Steps 1.

This workflow begins with an empty Start step -- a placeholder step which contains no logic and exists only to give a visual indicator of where the workflow process begins. 2. The next step, Initialize, calls the Identity Request Initialize subprocess workflow. This subprocess compiles the provisioningPlan into a provisioningProject. It also creates the Identity Request, which will make it possible for the requester and the requestee to follow the progression of the request. The LCM Manage Passwords workflow passes in a policyScheme variable value of "none" which causes this subprocess to bypass policy checking (policy checking does not really apply to password resets). 3. The next step for the workflow depends on results of the Initialize workflow. There are 2 available exits for the process at this point:  Exit on Provisioning Form - If the workflow variable endOnProvisioningForms is set to true and the provisioningProject returned by the Initialize step includes any unanswered questions, which required creation of IdentityIQ work items assigned to a user to gather required data to complete the provisioning action, this step sets an error message which will be reported to the requester through the user interface, and the provisioning process terminates.  Exit on Manual Work Item - If the workflow variable endOnManualWorkItem is set to true and the provisioningProject returned by the Initialize step includes an unmanagedPlan, which required creation of an IdentityIQ work item assigned to a user to complete the provisioning action, this step sets an error message which will be reported to the requester through the user interface, and the provisioning process terminates. 4. If neither of the exits is taken, the next step in the process is the Create Ticket step. This step calls the Manage Ticket subprocess. However, this step is only executed if the workflow was called from an integration with a ticketing system, in which case the workflow variable ticketManagementApplication is non-null (it names the ticketing application); otherwise, the workflow proceeds to the next step. 5. The most important step in the process comes next: the Provision step. This calls the Identity Request Provision subprocess workflow to provision the password change. 6. Next, this workflow includes a step called Post Provision, which is a script step containing some data clean-up logic. The Identity Request Initialize subprocess automatically includes creation of an approvalSet; since no approval is ever sought in this workflow, this step sets all items in the approvalSet to approved and marks the approvalSet as provisioned. It also sets the taskResult associated to this workflow (where the workflow's status is reported) to verified. 7. The next step is Update Ticket Post Provision. As with the Create Ticket steps, this step is only executed if the workflow was invoked by a ticketing system and the ticketManagementApplication variable is non-null. In that case, this step calls the Manage Ticket subprocess once more. 8. The Notify step then calls the Identity Request Notify subprocess to send emails to various system users, notifying them of the final status of the request. 9. The last step to be executed in this workflow, before the placeholder End step, is the Finalize step, which calls the Identity Request Finalizesubprocess. The Finalize step is always executed before the workflow terminates, even if it terminates with a catastrophic error condition. The two main purposes of the Identity Request Finalize subprocess are to update the Identity Request with the final dispensation of the request and to audit the provisioning action if that audit action has been turned on in the Audit Configuration. 10. The final step in this workflow is the End step, which like the Start step, is an empty placeholder step which contains no logic. ^Back to Top

LCM Manage Passwords Workflow Variables

The tables below list the workflow variables available to the LCM Manage Passwords workflow and the impact each can have on the process.


identityName

plan

endOnManualWorkItems

endOnProvisioningForms

flow

foregroundProvisioning

Default Value

Purpose

-

REQUIRED ARGUMENT*; Name of the identity being provisione by the LCM shopping cart, but could be passed in as a workflo workflow from a custom workflow. This variable is required as Request Initialize subprocess called in the first action step of t

-

REQUIRED ARGUMENT*; Representation of the requested item the other required input to this workflow, typically provided by can also be passed as a workflow variable when calling this w workflow. Throughout the workflow, this plan will be compiled provisioningProject, will go through approvals, and will finally b

false

Flag which causes the workflow to terminate after plan compil require any manual provisioning activities, where a work item assigned to a user to process provisioning to a disconnected s

false

Flag which causes the workflow to terminate after plan compil policies require attributes which cannot be auto-calculated an to be prompted for attribute values through a work item

-

Name of the process flow which initiated this request. When in interface, this is one of these predefined values:ForgotPasswo PasswordRequest. However, it is not an enum so it can be set usages of this workflow (e.g. when it is invoked from a quicklin can be used to drive functionality in the workflow which is spe needed, though is not used, by default, with this password wo

true

Flag which keeps provisioning in the foreground so the provisi completed when control is returned to the user; otherwise, pro backgrounded, releasing the requester's session while the pro which is more efficient for users in a production environment. only in development/testing environments and in demo mode

*The identityName and plan variables are not technically required by the LCM Manage Passwords workflow, but they are required inputs to the Identity Request Initialize workflow which is executed as the first step of the LCM Manage Passwords workflow. Therefore, these two attributes must be provided to this workflow as arguments or the LCM Manage Passwords workflow must be edited to add a step before the Initialize step which calculates the identityName and plan. These variables are automatically passed to this workflow when called from the LCM user interface options.


Default Value

Purpose


Name of the application that can handle ticket requests; Ident ticket there throughout the provisioning process.

ticketId

ID of the ticket generated by the ticketManagementApplicatio ticket in the various ticket-related steps of the workflow. The Identity Request object as the externalTicketId.

-

Notification Control Variables Variable Name notificationScheme

Default Value user

Purpose

CSV list of users who should be notified of the final s request once its processing is complete. Valid value

Variable Name

Default Value

Purpose

user: notify the target user (the person whose

requester: notify the requester (the person wh usually through the Lifecycle Manager user interface manager: notify the target user's manager

securityOfficer: notify the user specified in the workflow variable As many of these four may be specified as desired. subprocess sends emails to the specified users. userEmailTemplate

LCM Password Change Notification

Email template to use when notifying the target user provisioning request



Email template to use when notifying the requester o provisioning request





identityDisplayName

Default Value


Purpose


identityRequestId

The name of the identity request object of this provisioning request. The Identity throughout the process and persists afte ends. Note that though this is called ide GUID for the IdentityRequest object -- it number stored in the name field of the o

source

Indication of where the request originate representation of the sailpoint.object.So Javadocs for an up-to-date list of valid va

LCM

project


workItemPriority

Normal


false


trace

Variable Name

approvalSet

Default Value

-

Purpose

The approvalSet object which represents require approval; this is created by the I process but is not used by this workflow approved and provisioned at the end of the Post Provision step).

LCM Create and Update The LCM Create and Update workflow drives the provisioning of new identities as well as any editing of identity attributes. This workflow is invoked through the LCM options: Create Identity and Edit Identity. Its flow is illustrated in the Business Process Editor like this: Like the LCM Provisioning workflow, this workflow follows the full core process for LCM workflows, which includes these key steps: 1. 2. 3. 4. 5.

Initialize Approve Provision Notify Finalize Each of those steps is performed through calls to subprocesses. Other functions are performed in this workflow depending on arguments passed to the workflow. The key difference between this workflow's process and the LCM Provisioning process is that the approval step in this workflow allows the approver to change details in the request; this means that the request must be recompiled prior to provisioning so it reflects any updates made in the approval.

LCM Create and Update Workflow Steps 1.

This workflow begins like the other top level LCM workflows: with an empty Start step -- a placeholder step which contains no logic and exists only to give a visual indicator of where the workflow process begins. 2. The first action step in this workflow is different from the previous two -- it is a Build Approval Set step. Though the Initialize subprocess (called next) contains logic to build an approval set, the approval set needed for an identity-centric operation is slightly different in two ways. First, the provisioning plan gets annotated with the previous value of each changed attribute so the approver can see the "before" and "after" picture of this identity change. Second, comments entered at checkout can only be entered at the request level, not at the line item level, in identity update/create requests, so the process of adding those to the approval set is slightly different. To accommodate these differences, this workflow builds the approvalSet and modifies the provisioning plan in advance of calling the Identity Request Initialize subprocess and passes the pre-built approvalSet to the subprocess along with the modified plan. Passing in an approvalSet allows the subprocess to skip that step in its own logic. This step prebuilds the approval set by calling a rule called LCM Build Identity ApprovalSet, which is provided with Lifecycle Manager. 3. The next step, Initialize, calls the Identity Request Initialize subprocess workflow. The most important task of this subprocess is to compile the provisioningPlan into a provisioningProject. Another major purpose of this subprocess is to create the identity request which will make it possible for the requester and the requestee to follow the progression of the request -- approvals required and their current status, expansion details for fulfilling the request, whether the request enters a retry loop or a queued state, etc. Additionally, this subprocess performs policy checking, as directed by the workflow variables. As indicated in step 2 above, the subprocess skips creation of the approvalSet when one is provided to it as an argument.

4.

The next step for the workflow depends on results of the Initialize workflow. There are 3 available exits for the process at this point:  Exit on Policy Violation - If the workflow variable policyScheme is set to fail and the policy analysis in the Initialize subprocess found policy violations or if the policy analysis prompted the requester with an option to abort the request due to policy violations and the user chose that option, this step sets an error message which will be reported to the requester through the user interface, and the provisioning process terminates.  Exit on Provisioning Form - If the workflow variable endOnProvisioningForms is set to true and the provisioningProject returned by the Initialize step includes any unanswered questions, which required creation of IdentityIQ work items assigned to a user to gather required data to complete the provisioning action, this step sets an error message which will be reported to the requester through the user interface, and the provisioning process terminates.  Exit on Manual Work Item - If the workflow variable endOnManualWorkItem is set to true and the provisioningProject returned by the Initialize step includes an unmanagedPlan, which required creation of an IdentityIQ work item assigned to a user to complete the provisioning action, this step sets an error message which will be reported to the requester through the user interface, and the provisioning process terminates. 5. If none of the exits is taken, the next step in the process is the Create Ticket step. This step calls the Manage Ticket subprocess. However, this step is only executed if the workflow was called from an integration with a ticketing system, in which case the workflow variable ticketManagementApplication is non-null (it names the ticketing application); otherwise, the workflow proceeds to the next step. 6. Next, the Approve step calls the Identity Request Approve Identity Changes subprocess. This is a different subprocess from the one used by the LCM Provisioning workflow. One of its most notable differences is that it allows the approver to edit the request while approving it in the work item. 7. The next step is the Update Ticket Post Approval step, which is only executed if the workflow contains a ticketManagementApplication value (i.e. if it was called from an integration with a ticketing system). This step calls the Manage Ticket subprocess, just like the Create Ticket step above did. 8. This workflow again diverges from the LCM Provisioning workflow at this point because it must be able to process any editing of identity attributes done in the approval step. Therefore, the next step is Process Approval Decisions, which invokes the workflow library method processPlanApprovalDecisions. This method audits the decision and modifies the provisioning plan to reflect the changes made in the approval. (Though this is not commonly done, auditing can be explicitly disabled by specifying a disableAudit argument set to "true" on the step or in the workflow.) 9. The workflow contains another exit at this point. If the approver rejected the identity change request, the workflow proceeds directly to the Notify step (see step 15 below) to notify the appropriate users that the request was rejected. This bypasses the provisioning steps so the request is not fulfilled. 10. If the request was not rejected by the approver(s), the next step is the Recompile Project step. This recreates the provisioning project for the workflow to match the updated provisioning plan, reflecting any changes made to the provisioning request in the approval step. This step calls the workflow library method recompileProvisioningProject. 11. The most important step in the process comes next: the Provision step. This calls the Identity Request Provision subprocess workflow to provision the access request. 12. Next is the Post Provision step, which updates the approvalSet to mark everything as provisioned. Provisioning within IdentityIQ to create or update identities is synchronous, so when the Provision step completes and the process moves forward, it means the provisioning is finished. 13. The next step is Update Ticket Post Provision. As with the Create Ticket and Update Ticket Post Approval steps, this step is only relevant, and only executed, if the workflow was invoked by a ticketing system and the ticketManagementApplication variable is non-null. If executed, this step calls theManage Ticket subprocess once more. 14. Next, the Refresh Identity step can optionally perform a targeted identity refresh on the identity for whom the provisioning action was processed. This allows the system to update the user's role assignments and detections, provision any entitlements necessary to fulfill role assignments, and do attribute synchronization. Other options can be added to this refresh task as needed, or options

could be removed from this list. By default, this refresh is not performed, but it can be turned on by setting the doRefresh workflow variable to "true". 15. The Notify step then calls the Identity Request Notify subprocess to send emails to various system users, notifying them of the final status of the request. The notificationScheme workflow variable determines which users are notified, and the email templates to use for the notifications can be set through other LCM Create and Update workflow variables or can be left under the control of workflow variables in the subprocess itself. 16. The last step to be executed in this workflow, before the placeholder End step, is the Finalize step, which calls the Identity Request Finalizesubprocess. The Finalize step is always executed before the workflow terminates, even if it terminates with a catastrophic error condition. The two main purposes of the Identity Request Finalize subprocess are to update the Identity Request with the final dispensation of the request and to audit the provisioning action if that audit action has been turned on in the Audit Configuration. 17. The final step in this workflow is the End step, which like the Start step, is an empty placeholder step which contains no logic.

LCM Create and Update Workflow Variables This table lists the workflow variables available to the LCM Create and Update workflow and the impact each can have on the process.


Default Value

Purpose

-

REQUIRED ARGUMENT*; Name of the identity being provisione by the LCM shopping cart, but could be passed in as a workflo workflow from a custom workflow. This variable is required as Request Initialize subprocess called in the first action step of t

plan

-

REQUIRED ARGUMENT*; Representation of the requested item typically provided by the LCM shopping cart but can also be p when calling this workflow from a custom workflow. Througho be compiled and expanded into a provisioningProject, will go t finally be provisioned.

doRefresh

false

Flag which causes the workflow to run a targeted identity refre completes to refresh role assignments and detections for the u

false

Flag which causes the workflow to terminate after plan compil require any manual provisioning activities, where a work item assigned to a user to process provisioning to a disconnected s

false

Flag which causes the workflow to terminate after plan compil policies require attributes which cannot be auto-calculated an to be prompted for attribute values through a work item

-

Name of the process flow which initiated this request. When i interface, this is one of two predefined values for this workflow IdentityEditRequest. However, it is not an enum so it can be se usages of this workflow (e.g. when it is invoked from a quicklin

-

The ID of the individual request in the batch file when the requ request. Thsi is used by the batch interface to record the indiv back into the batch request.

optimisticProvisioning

false

Flag which makes the workflow treat the provisioning process in a queued status; usually used for demo mode, but occasion managed through a ticketing system or provisioning system w reaggregated into IdentityIQ.


true

identityName

endOnManualWorkItems

endOnProvisioningForms

flow

batchRequestItemId

Flag which keeps provisioning in the foreground so the provisi completed when control is returned to the user; otherwise, pro backgrounded, releasing the requester's session while the pro

Variable Name

Default Value

Purpose

which is more efficient for users in a production environment. only in development/testing environments and in demo mode *Technically, the identityName and plan variables are not required by the LCM Create and Update workflow itself, but plan is expected in the rule called by the first step of the workflow, and both are required inputs to the Identity Request Initialize workflow which is executed as the next step of the LCM Create and Update workflow. Therefore, these two attributes must be provided to this workflow as arguments or the workflow needs to be edited to add a different first step which would calculate the identityName and plan. When this workflow is called by the core product, either from the LCM user interface or from the LCM Registration workflow, an identity name and provisioning plan are always passed to it automatically.

Policy Checking Control Variables Variable Name

Default Value

Purpose




continue


policiesToCheck






Decision made by the user in the Policy Violation Review st Initialize. Valid values are:

ignore: user is ignoring the violations and processing require comments, and can only be selected if allowed by a flag)


policyViolations

-


-



Default Value

Purpose


Name of the application that can handle ticket requests and w opened and kept updated throughout the provisioning process

ticketId

ID of the ticket generated by the ticketManagementApplicatio ticket in the various ticket-related steps of the workflow. The Identity Request object as the externalTicketId.

-


Default Value

Purpose

Structure to use for managing the approval process. Val

serial: assign work items to approvers one at a tim

parallel: assign work items to approvers simultan

serialPoll: assign work item to approvers one at a decision is made only after all approvers have provided t

parallelPoll: assign work items to all approver sim made only after all approvers have provided their input.

approvalMode

serial

any: assign work items to all approvers simultane the first responder is acted upon as the final decision In the poll modes, the workflow is responsible for assimil decisions and determining the action to take; the out of precedence to rejection, so if any approver rejects a line provisioned. CSV list of approvers to include in the approval process.

manager: the target user's current manager is pro request includes a manager change, this sends the appr manager; all requested items are submitted together in

newManager: if the identity change involves a ma user's new manager is prompted for approval; otherwise current manager just like managerwould; all requested i in one approval work item

securityOfficer: prompt the user specified in the s for approval none: disables approvals for the identity change

approvalScheme

manager, newManager

If manager and newManager are specified together, both approval if the user's manager attribute changes; otherw manager will only be prompted once. More than one of overrides all other choices; the rest will be applied in the manager, securityOfficer (though the parallel, parallelPo process them all concurrently).



Email template to use when sending notification emails

fallbackApprover

spadmin

Name of the identity who will be assigned any approvals cannot be resolved (e.g. securityOfficer approval with no specified)

securityOfficerName

-

Name of the identity to use in a securityOfficer approval securityOfficer)

approverElectronicSignatu re -

Name of the electronic signature object to attach to the text to which the approver is agreeing when they sign off

approvalSet

The approvalSet object which represents all of the line it this is created by the first step in this workflow and is us approval status of each requested item so the provisioni before provisioning occurs to remove any items which w

-

Notification Control Variables

Variable Name

Default Value

Purpose




notificationScheme

user, requester


userEmailTemplate












identityDisplayName

Default Value


Purpose


identityRequestId

The name of the identity request object of this provisioning request. The Identity throughout the process and persists afte ends. Note that though this is called ide GUID for the IdentityRequest object -- it number stored in the name field of the o

source


LCM

workItemComments

Global comments accumulated during th shared with other approvals. When a new comments in this list will be added to th

project


workItemPriority


Normal

Variable Name

trace

Default Value

false

Purpose


LCM Registration The LCM Registration workflow manages the self-service registration identity creation process. Its flow is illustrated in the Business Process Editor like this: This workflow indirectly follows the full core process for LCM Workflows, includes these key steps: 1. 2. 3. 4. 5.

Initialize Approve Provision Notify Finalize However, the steps specified in this workflow itself are all precursors to that process. The last action step of this workflow, Submit Registration Request, calls the LCM Create and Update workflow, passing in a provisioning plan and identity name, to complete the provisioning process for the selfregistered identity.

LCM Registration Workflow Steps 1. 2.

3.

4. 5.

Like the other top level LCM workflows, this workflow starts with an empty Start step -- a placeholder step which contains no logic and exists only to give a visual indicator of where the workflow process begins. The first action step in this workflow, Initialize, calls the workflow library method getIdentityModel. That method creates an IdentityModel map of the attributes needed when creating a new identity; the map is empty at this stage of the process. IdentityModel is a special map variable which is supported by IdentityIQ workflow library methods; these library methods make it easy to build an empty identity model, build an identity model for any defined identity, and turn identity model changes into a provisioning plan so the changes can be easily provisioned through the system. The next step is Registration Form, which presents a blank identity registration form to the user who launched this workflow. This form is defined by the Self-service Registration identity provisioning policy; this identity provisioning policy is pre-defined in IdentityIQ by default, but it can be modified for specific customer needs. Once the user has submitted their data, the next step - Build Confirmation Form -- creates a read-only confirmation form. This form looks almost exactly like the registration form, but all of the fields are read only. In the Confirmation Form step, the read-only form is presented to the user to validate the data they entered at registration before it is submitted for processing. If the user approves the data on this form, the identity data entered there is stored into the identityModel created in the Initialize step (step 2).

6.

If the user rejects the data on the confirmation form, the process loops back to the Registration Form step (step 3). If the user approves the data on the confirmation form, control passes to the Verify step. The default Verify step contains no logic; it is a placeholder step where customers can insert their own pre-validation logic. This could include white-list or black-list processing, among other things. 7. Next, the Set identity name step retrieves the identity name out of the identityModel and sets it into the identityName variable. Identity name needs to be passed as an argument to the LCM Create and Update workflow in step 9. 8. The next step, Build Provisioning Plan, calls the workflow library method buildPlanFromIdentityModel to automatically build a provisioning plan which represents the request to create the new identity with the attributes specified in the identityModel. Like identityName, plan must be passed as an argument to the LCM Create and Update workflow in step 9. 9. The last logic step in this workflow, Submit Registration Request, passes the identity name and provisioning plan into the LCM Create and Updateworkflow, calling it as a subprocess, to create the new identity. The approvalScheme set in this workflow is "securityOfficer", which relies on thesecurityOfficerName variable; that variable is null for this workflow, by default, so the fallbackApprover is used instead. Because SailPoint is inherently unaware of any identity specific to any customer's deployment, spadmin is set as the fallbackApprover in the out-of-the-box workflow; this should generally be modified for any customer's implementation of this workflow. Many options are available for controlling the approval in a customer-specific version of this workflow: for example, a different fallback approver could be specified, a securityOfficerName could be entered, or the Verify step could be used to calculate a manager for the user based on the data entered and the approvalScheme could be changed to manager, allowing that manager to be the approver for the identity creation process. 10. The final step in this workflow is the end step, which like the Start step, is an empty placeholder step which contains no logic.

LCM Registration Workflow Variables This table lists the workflow variables available to the LCM Registration workflow and the impact each can have on the process.


Default Value

Purpose

identityName

-

Name of the identity being provisioned. This is populated in th from the registration form data.

plan

-

Representation of the requested items to be provisioned. This Provisioning Plan step from the registration form data.

doRefresh

false

Flag which causes the LCM Create and Update workflow to run after provisioning completes to refresh role assignments and d default

flow

Registration

Name of the process flow which initiated this request.

-

The ID of the individual request in the batch file when the requ request. Thsi is used by the batch interface to record the indiv back into the batch request.

false

Flag which makes the workflow treat the provisioning process in a queued or retry status; usually used for demo mode, but o managed through a ticketing system or provisioning system w reaggregated into IdentityIQ.


true

Flag which keeps provisioning in the foreground so the provisi completed when control is returned to the user; otherwise, pro backgrounded, releasing the requester's session while the pro which is more efficient for users in a production environment. only in development/testing environments and in demo mode

transient

true

This flag keeps work items and workflowcases from being pers

batchRequestItemId

optimisticProvisioning

Variable Name

Default Value

Purpose

workflow if the user cancels the process before submitting the the user is not registered to the system, there would be no wa work item and resume the workflow, so this keeps orphaned w cases from being created by this process. This variable is a re used to drive this non-persistence behavior in any workflow; it custom QuickLink workflows.


Default Value

Purpose

Management structure for the approval process. Valid valu

serial: assign work items to approvers one at a time

parallel: assign work items to approvers simultaneou

serialPoll: assign work item to approvers one at a tim is made only after all approvers have provided their input.

parallelPoll: assign work items to all approver simult made only after all approvers have provided their input.

approvalMode

serial

any: assign work items to all approvers simultaneou the first responder is acted upon as the final decision In the poll modes, the workflow is responsible for assimilati decisions and determining the action to take; the out of the precedence to rejection, so if any approver rejects a line ite

CSV list of approvers to include in the approval process. Va

manager: the target user's manager is prompted for items are submitted together in one approval work item

securityOfficer: the identity named in the variable se prompted for approval; all requested items are submitted t approval work item none: disables approvals

approvalScheme

securityOfficer

If more than one of these are specified together in this list, according to the approvalMode. In serialPoll mode, they wi manager, security officer. Including none in the approval s overrides any other approval schemes, turning off approva


LCM Registration Approval

Email template to use when sending notification emails to a

fallbackApprover

spadmin

Name of the identity who will be assigned any approvals w cannot be resolved (e.g. an "owner" approval where the ap attribute)

securityOfficerName

-

Name of the identity to use in a securityOfficer approval (if securityOfficer)

approverElectronicSignatu re -

Name of the electronic signature object to attach to the ap text to which the approver is agreeing when they sign off o


Default Value

ticketManagementApplica tion ticketId

-

Purpose

Name of the application that can handle ticket requests and w opened and kept updated throughout the provisioning process often with this workflow as with others.

ID of the ticket generated by the ticketManagementApplicatio (this is set in a subprocess of the LCM Create and Update work

Variable Name

Default Value

Purpose this workflow).


Default Value

Purpose

CSV list of users who should be notified of t provisioning request once its processing is c include:

user: notify the target user (the pers altered)

manager: notify the target user's ma

securityOfficer: notify the user specifi securityOfficerName workflow variable

notificationScheme

user, manager

none: disables notification (can also disable notification) As many of these four may be specified as d Notify subprocess sends emails to the speci

userEmailTemplate

LCM Registration User Notification

Email template to use when notifying the ta of the provisioning request


LCM Registration Manager Notification

Email template to use when notifying the ta final status of the provisioning request

securityOfficerEmailTempl LCM Registration Security Officer ate Notification

Email template to use when notifying the se status of the provisioning request


Default Value

Purpose

displayName of the identiy named in identityName

Display name of the identity being updat workflow, but can be provided as an inpu Create and Update workflow or will be au displayName of the identity named in the that workflow.

LCM

Source indicating where the request orig representation of the sailpoint.object.Sou Javadocs for an up-to-date list of valid va

Normal

Attribute to mark on the work items gene which designates their priority relative to attribute can be used to sort work items list; it does not affect the order in which system-driven parts of the processes. Va and Low.

trace

false

This attribute turns on trace logging for t workflow handler. When trace is set to tr workflow variables is printed when the w indicating the start and end of each step as well. This can be extremely helpful in workflow development, as it helps isolate occurring. These statements are written

confirmationForm

-

Form displayed for confirming the registr

identityDisplayName

source

workItemPriority

SailPoint Workflow

Recommend Documents