SailPoint why you should NEVER open any OOTB or cloned OOTB workflow in UI

Here's a good suggestion

Unless you authored a workflow in the Business Processes UI in SailPoint, don't open it in the UI.  This includes any OOTB workflow - you should NEVER modify any OOTB workflow.  It also includes any workflow that you cloned from OOTB.

How do you clone a workflow?  How to you clone any replicatable object?  Open it in the Debug Page, then change the Name, and then remove the created, id, and (if there) modified tags from the first line (actually line 3).  Also then search for and remove any created, id, or modified tags anywhere in the file.

Why don't you want to open an OOTB workflow in the UI?  Because the UI will reorganize the workflow in a way you don't want to happen.  It will reformat the descriptions, it will add or remove arguments to steps, and you will not be able to make comparisons to the OOTB workflows.  It also adds the explicitTransitions tag which is not wanted.

Here's what it does to LCM Provisioning:

Reformats the Descriptions to remove line feeds - they are ugly

In the Initialize step, it adds the following arguments:

• <Arg name="identityRequest">
• <Arg name="asyncCacheRefresh">

It also confusingly shuffles the remaining arguments.

In the Create Ticket step, it adds the following arguments:

• <Arg name="ticketProject">
• <Arg name="ticketPlan">

In the Pre Split Approve step, it adds the following arguments:

• <Arg name="dontUpgradePlan"/>
• <Arg name="clearApprovalDecisions"/>
• <Arg name="workItemDescription"/>

In the Approve and Provision Split step, it adds the following arguments:

• <Arg name="clearApprovalDecisions"/>
• <Arg name="requesterEmailTemplate"/>
• <Arg name="approvalEmailTemplate"/>
• <Arg name="endOnProvisioningForms"/>
• <Arg name="enableRetryRequest"/>
• <Arg name="endOnManualWorkItems"/>
• <Arg name="userEmailTemplate"/>
• <Arg name="batchRequestItemIId"/>

In the Approve and Provision step, it adds the following arguments:

• <Arg name="approvalEmailTemplate"/>
• <Arg name="batchRequestItemId"/>
• <Arg name="clearApprovalDecisions"/>
• <Arg name="enableRetryRequest"/>
• <Arg name="endOnManualWorkItems"/>
• <Arg name="endOnProvisioningForms"/>
• <Arg name="requesterEmailTemplate"/>
• <Arg name="userEmailTemplate"/>

In the Finalize step, it adds the following arguments:

• <Arg name="autoVerifyIdentityRequest"/>
• <Arg name="ticketDataGenerationRule"/>

SailPoint which files should go in your comparison folder

 In the ExportXML class you have an option to compare against existing data and create a merge file for certain files.  Here are the files you will need to place in there and how to organize them.  You want to generate these files from a perfectly stock deployment so that the client's customizations are actually captured in the merge files.  If you don't, then the merge file will only contain modifications after the date you generated it.

Create a folder I normally call mine base (or Base for Windows based).

 Next create the following folders and put the shown files into those folders:

AuditConfig

    AuditConfig-AuditConfig.xml

Configuration

    Configuration-ConnectorRegistry.xml

    Configuration-IdentityAIConfiguration.xml

    Configuration-IdentitySelectorConfiguration.xml

    Configuration-SystemConfiguration.xml

ObjectConfig

    ObjectConfig-Bundle.xml

    ObjectConfig-Identity.xml

    ObjectConfig-Link.xml

    ObjectConfig-ManagedAttribute.xml

UIConfig

    UIConfig-UIConfig.xml

 

My normal ExportXML output is  $Class$-$Name$ that is why they are named that way.

IdentityAI is not found on lower versions of IIQ.

SailPoint saving AD values as a secondary auth source

 This post is primarily so I remember how I do every client's AD.  The point of saving AD values as Identity Attributes is twofold: first, to indicate if the user has an AD account (this can literally be done for any target, but AD is the one that almost everyone uses for their primary provisioning target).  Second, it allows you the OPTION of saving the values for all time, which would allow you to ensure that no duplicates be created.

 I create 5 Identity Attributes:

adLogin (AD Login) which derives from sAMAccountName

adEmailAddress (AD Email Address) which derives from mail

adDistinguishedName (AD Distinguished Name) which derives from distinguishedName

adUserPrincipalName (AD User Principal Name) which derives from userPrincipalName

adObjuctGuid (AD Object Guid) which derives from objectguid

 Any or all of these can be backed up with a global rule I normally call IdentityAttribute-PersistOldValue whose source is literally return oldValue;

You have to decide on your own which if any are sortable. Make a value sortable if you plan to do a search on it using any search method.

If you use the global rule then your values will not be removed if the user loses their AD Account.  Be careful and aware of this.