What is the best way (practice) to provision user attributes such as UserPermissionsMarketingUser, UserPermissionsOfflineUser, UserPermissionsInteractionUser etc. In our case, they are to be approved via a request and not tied to any identity attributes
Because these are Boolean attributes, you can check if you can have the salesforce team create a role in Salesforce for each one attribute. Create a before‑Provisioning rule to intercept requests for that public group and apply the logic needed to update the corresponding attribute on the user’s Salesforce account.
You could mark these boolean attributes as type string and sntitlement, make these requestable one by one if your access model allows that or club them into a Role.
If you’re marking them string, you have to make sure the value you’re passing is exactly what Salesforce expects.
I was thinking along the same lines. So, would we provision both the role and the user attribute to ensure Native Change detection issues are avoided?
Also, are beforeProvisioning rules limited to AD and AzureAD sources only? Before and After Operations on Source Account Rule | SailPoint Developer Community lists Source types. We are using Salesforce Saas Connector
You don’t have to enable NCD for this. You want to use below rule:
Web Services Before Operation Rule | SailPoint Developer Community
We are using Salesforce Saas Connector and that does not go through the VA. Can this still be used?
Generally recommend that access to the user in salesforce should be given via ProfileID , permisisonSet, PermissionSetGroup , PublicGroups , PermissionSetLicense , ManagedPackage, DelegateGroup , Role .
Check with team if the access can be coverted to any of these objects .