We are configuring a web service connector .During create operation we are able to pass all field from the create profile.
However during update operation or enable operation all fields are not populating in the body due to which the api call is failing.
We have also tried to add the fields in the Account Profile for all the operation but still the data does not pass.
But when we try to update it via API it never gets updated to isRequired as true even after successful response
Is there any API which can help to update this.
I donât think there is anyway to circumvent this behaviour of connector. The new api to set provisioning policy is also not updating the field. I also tried another field from old doc and itâs also not working.
https://ideas.sailpoint.com/ideas/CONN-I-66 Created idea to make plan arguments available in connector end point.
Also created this: https://ideas.sailpoint.com/ideas/PLAT-I-68
BTW, you do not need to write before provisioning rule to add arguments. You can use âservices standard before provisioning ruleâ and configure your source json based on your requirement.
Iâm experiencing a similar issue in which, when executing an Update operation, the only attributes Iâm able to retrieve using â$plan.xxx$â are nativeIdentity and group. Since the Create operation is never executed, the Provisioning Policy (create account) is never executed either. Doesnât really matter if I change the attributes to âisRequiredâ or not.
Is there a way to pass account attributes in the body/parameter without the need of using the create account? Something thatâd look something like: â$account.xxx$â (xxx in this case is an attribute only available in the account).
Hey all - looking at everyone struggling on this thread, I would like to clarify some incorrect information. Iâm a SailPoint employee that is familiar with this, and have been around since this configurations inception.
The parameter isRequired is used to validate if a particular field in a provisioning policy / profile should have a value or not. Itâs used by the UI and API to make sure fields are filled out. If isRequired is true then it should have a value for transform (i.e. be configured in the UI), otherwise youâll get an error. If isRequired is false then it essentially is optional field to configure. These fields are set on out-of-box provisioning policies / profiles so admins know they have to configure this or not.
If you are trying to force attributes into provisioning downstream, you will not be able to do that in provisioning policy / profiles; youâll need to use a Before Provisioning rule. Whatever you put in a provisioning policy / profile is subject to provisioning engine filtering, and will get filtered and removed if you already have that value. Before Provisioning rules execute after provisioning plan expansion and filtering and thus whatever you put in there will get sent to your connector.
We have a bunch of explanations of this behavior in internal, partner, and training materials - hopefully everyone has seen it.
1: Does the isRequired parameter only enforce that the transform attribute has been set, or does it also enforce that the output of this configured transform is not empty in order for the provisioning plan to be send to the next phase?
2: You said âIf you are trying to force attributes into provisioning downstream, you will not be able to do that in provisioning policy / profiles; youâll need to use a Before Provisioning rule.â
Regarding this. We had to onboard a web services source, where in order to disable the account, the API body did not need the nativeIdentity (Like NL.AMekenkamp01), but instead needed the domain (NL) and name (AMekenkamp01) separately like domain=$plan.domain$, plan=$plan.name$. When I first added these two values name and domain (as account attribute transforms) to the DISABLE profile, disabling the account was not successful because these $plan.domain$ and $plan.name$ values were not appearing. Probably because of the provisioning engine filtering as you mentioned. But using the same account attribute transforms, but then assigning them to $plan.domainToDisable$ and $plan.nameToDisable$ was working and the account got disabled properly. Probably because these variable names are not used elsewhere and will therefore not be removed by the provisioning engine filtering. Based on this I would say that the statement âIf you are trying to force attributes into provisioning downstream, you will not be able to do that in provisioning policy / profilesâ is wrong. You just need to make sure that you are using variables that are different than the account attributes.
Could this be correct, or am I missing something?