Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.
Please consider addressing the following when creating your topic:
What have you tried?
When assigning multiple Access profiles (one entitlement each) during CREATE account or ADD ENTITLEMENTS of a SaaS source, errors are coming. Below is how API is accepting the roles -
“roles”: [“Role1”,“Role2”]
What errors did you face (share screenshots)?
When using in body of Create and Add - “roles”: $plan.roles$, below error is coming -
After Create account or Add Entitlement, there is no Response (blank response) only success code from API.
Share the details of your efforts (code / search query, workflow json etc.)?
Created a before provisioning rule - But it was taking two access profiles at two different grant instances.
But then Before provisioning rule was changed as to take two entitlements from access profiles, but then first one is requesting to CREATE account and below error is coming -
What is the result you are getting and what were you expecting?
Wanted to create a provisoning like [“Role1”,“Role2”] using Before PRovisioning Rule, but it is only taking one entitlement at a time. LIke it is also creating roles in source incorrectly like - [“Role1”], which should only be Role1.
Expected result - Multiple Access profiles should be assigned to the SaaS source during CREATE Account and ADD Entitlements with or without Before Provisioning Rule.
From the errors, this looks more like an entitlement handling issue than an Access Profile limitation.
For Web Services SaaS source, I’d first try the OOTB settings instead of combining values in a Before Provisioning Rule:
Enable createAccountWithEntReq=true
Enable addRemoveEntInSingleReq=true
Make sure the roles account attribute is configured as multi-valued and entitlement
The request body should be:
{
"roles": $plan.roles$
}
Not:
{
"roles": "[$plan.roles$]"
}
Otherwise multiple roles can be sent as one string instead of a proper array.
Also, the missing output error is important. It looks like the first Create call may actually be creating the user in the target, but ISC is not getting enough response data to complete/link the account properly. Then the next Access Profile request tries another Create and you get the 409 duplicate user error.
I would fix the Create response/account linking first, then test the multi-role provisioning again before adding any custom rule.
Since the Create API is returning a blank body, I don’t think adding Response Mapping there will help because there is nothing to map.
I’d configure/test the Get Object operation instead. Make sure the account identity attribute (username/email/ID) is available in the create plan and that Skip getObject Call during Create Provisioning is disabled.
After Create, ISC should use Get Object to fetch and link the newly created account. I’d first verify whether single account aggregation is working correctly for the same user.
Once the account is linked, the second Access Profile should go through Add Entitlement instead of trying another Create, which should also avoid the 409 duplicate error.
You can keep createAccountWithEntReq=true, addRemoveEntInSingleReq=true and "roles": $plan.roles$.
If Get Object also cannot identify the account because the target generates the ID and Create returns nothing, then the target API would need to return the account ID or provide a lookup using username/email.
Hello Suyatra. Your Add Entitlement body already looks correct:
{ "site_id": "abcd1234", "roles": $plan.roles$ }
That matches the documented format when “Add or Remove Entitlements in a Single Request” is enabled, so I would not change the body again. The next thing I would check is what value ISC is actually sending for $plan.roles$, because the invalid_json error happened even with the correct template. I would test Create and Add Entitlement separately.
For the Create test, request one temporary Access Profile containing both roles for a test identity that does not already have an account on this source. Since “Create Account With Ent Request” is enabled, check the actual Create request received by the target and see how the roles are sent.
For the Add Entitlement test, use an identity that already has a linked account and request an Access Profile containing both roles. Check whether the request contains "roles": ["client_admin", "api_user"]. If it does, the multi-valued roles configuration is working correctly, and we only need to understand why the two separate Access Profiles are being processed separately.
If either test still gives invalid_json, I would check the actual request received by the target or API logs rather than change the template again.
One more thing I would check separately is the missing output / 409 issue.
In your screenshot, "Skip getObject Call during Create Provisioning" is enabled while your Create operation returns a blank response. I would disable that setting and let Get Object run after Create.
The important part here is the account ID. Get Object needs a value it can use to find the account that was just created. Your single-account aggregation working tells us the endpoint can retrieve an existing account, but after a new Create, ISC still needs the account ID (native identity) to find that new account. So make sure that value is already available in the provisioning plan. If the target generates the only usable account ID and does not return it in the Create response, turning off Skip getObject alone will not be enough.
Then test the original two Access Profiles again. If the first request creates the account and Get Object links it, check what ISC does with the second Access Profile. If it still tries another Create, the problem is how ISC is processing the two separate grants, not the roles JSON.
If missing output still happens even after Get Object finds the new account, I would compare the attributes in the Create Profile with what the Create Account operation actually sends.
Your existing Before Provisioning Rule is fine to keep using. It is different from Web Services Before/After Operation rules, which are not supported by the SaaS Web Services connector. The SaaS connector supports Connectivity Customizers instead, but I would finish the tests above before going down that path.
Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.
