Attribute Sync With Mandatory Attributes

[gauravsatyawanb (Gaurav Bachhav)]

Hi Team,
I have a use case where we have a webservices connector and want to sync attributes, such as firstName, lastName, email and phone. The firstName, lastName and email are mandatory attributes in the update user API.
I have created an update account provisioning policy where we have firstName, lastName, email and phone mapped to an identity attribute. However, when the provisioning is triggered for only one attribute, lets say for phone, the provisioning plan contains only phone, hence the API fails with mandatory attributes required error.
My understanding is that when we have an update account policy configured, all configured attributes should also be present in the provisioning plan.
Could someone help me with this issue.

[MuhammadMustafa]

Hi @gauravsatyawanb, this behaviour is expected in ISC, and even in IIQ.
When a provisioning policy is configured for attribute sync, ISC generates a provisioning plan that includes (only the attributes that have changed) since the last aggregation or provisioning event. Therefore, if only the phone attribute is modified, the plan will not include firstName, lastName, or email unless they were also updated.

Since your target system’s API requires firstName, lastName, and email as mandatory fields - even for partial updates - you’ll need to ensure those fields are always included in the provisioning plan.

To address this, you can implement a rule tied to the Update operation that inspects the identity object and programmatically adds the mandatory attributes (firstName, lastName, email) to the provisioning plan - even if they haven’t changed. This ensures the target system receives all required fields.

Check these links out:

BeforeProvisioning Rule for a web-service application

I would consider checking out the Rule Development Kit provided by the Developer Advocates, which can be found here: Rule Development Kit | SailPoint Developer Community The kit provides tools to help you develop the rules before submitting them for review. I assume that since you are asking about before Provisioning that you are using the Web Service SaaS connector. Looking over your code, I am not sure it is doing what you intend. It looks like you are getting the attributes off of the Acco…

Using WebService connector rules to streamline and accommodate “interesting” sources

[Using WebService connector rules to streamline and accommodate “interesting” sources] Description Continuing the conversation of connectivity, Stephen will provide you with a walkthrough of using WebService Before and After Operation connector rules to aggregate data when the provider’s data is in a state that is hard or impossible to tie to the Account itself, as well as to cache data from aggregation start to aggregation end to reduce network use and avoid API rate limits. API L…

Hope that will help/support you, and in case you need anything further, don’t hesitate to let us know please!

Regards,
Mustafa

[gmilunich (Geoff Milunich)]

There are 2 options i have seen used here, depending on which WebService Connector you are using (VA-Based/Direct or SaaS. ) Let us know which to help provide better answers.

In a VA-based one, you could use a beforeOperation rule to look up the user if you have enough information for that, then add the additional values returned from that call as attributes to be provisioned. Just be aware this would increase the call rate if your API has Rate Limiting.

You could do something similar in a BeforeProvisioning rule for a SaaS connector, but you may have access to the Identity object in that one.