Sailpoint IIQ Dropdown / LOV functionality with Key-Value pair

It was surprising to find out that Sailpoint do not provide a key-value pair / code-decode LOV/Dropdown functionality OOTB till IIQ 7.2 (Please feel free to differ as I literally have 24 hrs of experience with the tool at the moment, however I did research the community and it seems it's an issue a lot of people are facing).
Sure you can use the 'Allowed Values' functionality with the actual 'Value' , but that does not solve the problem of showing 'key' or 'decode' values in the front end.

So without further ado, here's how we can achieve it (taking Salesforce Profile IDs for example ) -

Prob - I need to show 'System Administrator' to the user in the application account request form , while sending '00e2v000002Xj74AAC' to the target (Salesforce in this case).

Solution :

STEP 1. Create a custom object which holds this Key-Value pairs of a dropdown, you can add multiple dropdown values in the same custom object by storing the Map in the value, and specifying a unique Key for each Map value -

Go to "Debug" page  -> Find Custom objects -> Click on 'New' -> Paste your custom object and save.

<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE Custom PUBLIC "sailpoint.dtd" "sailpoint.dtd"> <custom name="List of Values"> <attributes> <map> <entry key="getProfileCode"> <value> <map> <entry key="System Administrator" value="00e2v000002Xj74AAC"/> <entry key="Chatter Free User" value="00e2v000002Xj75AAC"/> <entry key="Read Only" value="00e2v000002Xj7aAAC"/> <entry key="Standard User" value="00e2v000002Xj7gAAC"/> </Map> </value> </entry> </Map> </Attributes> </Custom>

STEP 2. Create a 'Allowed Value' rule for returning the key set of the mentioned custom object from debug page -

<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd"> <rule language="beanshell" name="SF Profile values" type="AllowedValues"> <source> import java.util.List; import java.util.Map; import sailpoint.object.Custom; List orgList=null; Custom custom=context.getObjectByName(Custom.class,"List of Values"); if(custom!=null) { Map orgMap=custom.get("getProfileCode"); orgList = new ArrayList(orgMap.keySet()); } return orgList; </Source> </Rule>

STEP 3. go to your application definition -> Configuration -> Provisioning Policy -> Create Policy ->Edit the dropdown attribute -> Select 'Rule' under 'Allowed Value' section, and select the rule you created in last section. (alternatively, you can use 'Script' )

So now, you have your desired user-friendly list of values showing in the dropdown , however, you need to change those Key/Decode/Front end values to the value/code/backend values before actually pushing the user account data in the target.


Hence, STEP 4 - Create / Add to an existing 'Before Provisioning Rule' for the data modification  :
Application definition -> Rules -> Before Provisioning Rule -> Select the rule

<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd"> <rule language="beanshell" name="SF Profile values decode beforeProv" type="BeforeProvisioning "> <source> import sailpoint.object.*; import sailpoint.tools.*; import sailpoint.object.ProvisioningPlan; import sailpoint.object.ProvisioningPlan.AccountRequest; import sailpoint.object.ProvisioningPlan.AttributeRequest; import sailpoint.object.ProvisioningPlan.Operation; import java.util.List; import java.util.Map; import sailpoint.object.Custom; AccountRequest acctReq = plan.getAccountRequest("Demo Salesforce integration"); List attributeRequests = acctReq.getAttributeRequests(); List orgList=null; String valueCode = ""; Custom custom=context.getObjectByName(Custom.class,"List of Values"); Map orgMap=custom.get("getProfileCode"); if ( attributeRequests != null ) { for ( AttributeRequest req : attributeRequests ) { String name = req.getName(); if ( name != null && name.compareTo("ProfileId") == 0 ) { if(orgMap.containsKey(req.getValue())) { req.setValue(orgMap.get(value)); } } } } </Source> </Rule>

and voila ! you can now leverage the LOV/Dropdown functionality with key-value pairs.

Also, alternatively you can add an additional step in the workflow to achieve this data modification.

Thanks for reading !