You can use the Update Provisioning Policy endpoint to add additional attributes during an account update operation. For example, if a user’s work address changes and this attribute is set up for synchronization, you can use this endpoint to include other information in the provisioning plan to update their city, state, and country information at the same time.
However, in most cases, SailPoint recommends using the BeforeProvisioning rule to perform such tasks because:
Attributes values in the Update Provisioning Policy that aren’t read back from a source account aggregation will be retriggered as provisioning events during identity refresh. This may result in repeated provisioning attempts or redundant tickets if your source is using a ticketing integration for provisioning.
Attribute values in the Update Provisioning Policy that are already set on the account will be removed from the final provisioning plan sent to the connector. By contrast, an attribute added through the BeforeProvisioning rule will always make it to the connector.
The Update Provisioning Policy is generally only recommended for situations where non-provisioning information needs to be included in the plan. This is normally only applicable for ticketing integrations where you may need to add human-readable information about the target account and activity so that another user can perform the necessary steps manually.
Isn’t this contradicting with the two bullet points you mentioned? Because if non-provisioning information is not part of the account schema, it will retrigger each identity refresh, and if it is part of the account schema, but happens to be the same (which I guess is most often the case), the value will be removed from the final provisioning plan?
In general we are being told by SailPoint that rules should be a last-resort when default functionality like transforms and provisioning policies are not sufficient. This new recommendation seems to contradict with that.
To me it seems that the update provisioning policy is not functioning as one might expect, which causes this recommendation of not using it, except for a small case involving non provisioning information for ticketing integrations, even though it has a lot of potential.
So apparently each identity refresh the values of the update provisioning policy are being recalculated to determine whether or not a change will occur. Shouldn’t the opposite happen? Whenever an update is needed the update provisioning policy should be checked to see if additional values should be added to the provisioning plan. I believe that the only thing that currently should trigger update account is because of performing attribute sync. I don’t see what else could trigger it since we have different policies for types like ENABLE, DISABLE, ASSIGN, UNASSIGN and ‘CHANGE_PASSWORD’ according to the documentation, some of which we also use successfully.
Isn’t this the reason why update provisioning policies have fields containing the attribute isRequired. What is this attribute used for otherwise? I would expect that when an update is needed, the update provisioning policy is being inspected and if a field has isRequired=true it will always send the value in the provisioning plan and if a field has isRequired=false, it will only send the value in the provisioning plan if it is different than the current value we received upon account aggregation. (sometimes with web service connector we can only update the account if we not only send the nativeIdentity, but also the email address, so we would want to add that in the update provisioning plan and mark it as isRequired=true.)
If the update provisioning policy is actually being as I would expect based on the API documentation, we would not need to use beforeProvisioning rules that often, which will be great, especially since it requires support from SailPoint to have beforeProvisioning rules deployed.
I agree with the sentiment regarding OOTB functionality (UpdatePolicy) being preferred to a rule.
However, what I have found very useful in the meantime is to use the Services Standard Before Provisioning Rule. The rule can be re-used on sources of different types and since the “UpdateAttribute” function is configured in the source’s connector attributes, the additional attributes can be updated easily at any time without changes to the rule’s code which would need re-deployment.
The only drawback I have found is that this method generates a “Modify Account” event for each additional attribute added, which can be a tad confusing in logs and audit when there may have only been one sync attribute that was truly modified. If anyone has found a way to work around this, I’d be curious to hear.
