We are currently using SailPoint IdentityIQ version 8.4p2, and for the OOTB Salesforce connector, the customer has requested to implement license management, specifically for Salesforce, Identity, and Salesforce Integration, with the possibility of adding more licenses in the future.
We understand that license assignment in Salesforce is handled through the Profile object. Based on this, we have the following question:
What is the recommended way to handle a license change when an identity requests access that requires a Profile change?
After consulting an AI, the following approach was suggested:
Perform a validation in a BeforeProvisioning Rule to detect whether the licenses associated with the current Profile and the new Profile to be assigned are different.
If they are different, deactivate the identity’s existing Salesforce account.
From the same rule, trigger a workflow that creates a new Salesforce account with the correct Profile and the corresponding Permission Sets / Permission Set Groups / Roles.
My questions are:
Is this approach valid and recommended in IdentityIQ?
Is there any alternative or more standard way to manage license changes via Profile in Salesforce without deactivating and recreating the account?
Thank you in advance for any guidance or experience you can share.
Edit: I forgot to add that we need this approach to handle license conflicts when an error occurs after an Access Request.
@mlucero15 Salesforce connector considers Profiles as entitlement and you can easily replace them using Access Request. this is an standard/OOTB feature, doesn’t need any customization.
If your requirement can be handled by add/remove the profile, you can enable access management and give it a try.
Note: Found a fix?Help the community by marking the comment as solution. Feel free to react(,, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.
Thank you for your response.
I forgot to add that we need this approach to handle license conflicts when an error occurs after an Access Request.
Error: User’s Profile can’t be set to ‘Identity User’ because it’s derived from a license that doesn’t require the following permission(s): ChatterInternalUser. Select a different profile.
@mlucero15 I don’t think IIQ supports it via connector. You can try making API calls to validate if user needs a different license or not.
I would recommend doing it even before you generate the access request. Other wise it would unnecessary create an approval item or access request and then skip or fail the request. In one of the implementation, we have handled these kind of pre checks in a subprocess which we used to call before caliing Identity Request Initialize.
Thank you for the recommendation, that makes sense.
Do you happen to have an example or reference (even a high-level one) of how you implemented these pre-checks in a subprocess before calling Identity Request Initialize?
@mlucero15 No. I don’t have it handy. Either you do it in subprocess or in a step, is up to you and how you want to maintain such pre validations in future. Keeping it in workflow, actally keeps the main workflow light and easy to read.
In case you are using a subprocess, then what you can do is, you can transition to a subprocess before transitioning to Identity Request Initialize. Pass “plan” as an argument.
Here in sub process, you can get the profile selected by user and apply your validation logic. Then make changes to your plan, if you feel we should keep the profile, return the plan as is. Else modify the plan and remove the attribute request, then return the plan.
If you want to use a step, then you can apply above steps in the script and return the plan to workflow.
Once plan is returned back, you can validate if plan is empty or not and transition to rest of the next steps. If plan is empty, you can send an email or print the message and exit the workflow.
Note: Found a fix?Help the community by marking the comment as solution. Feel free to react(,, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.
