I am working on the create account operation of the webservice connector and currently facing some difficulties.
There is a new joiner and an identity cube has been created.
Account and group type entitlements of the target source have been aggregated successfully.
The target source generates a unique ID when an account is created, which is different from the identity’s UID.
There is a separate API to update entitlements using this generated ID.
I am having trouble implementing the step where the generated target source ID is used to add entitlements.
I have searched for various solutions mentioned in the ISC discussion and obtained advice on implementation methods such as:
a. Creating two ‘Create Account’ operations, first operation returning $response.ID$, and then second operation calling the entitlement addition endpoint API.
b. When Create Account operation finished, call single account aggregation using parent endpoint setup.
Here are my questions:
Q1. In the target source account schema, how should the Account ID be set?
Should it be configured the same as the HR ID, or should it be set as the target source ID?
The account correlation should definitely be tied to the identity UID.
Q2. In the Create Account HTTP Operation, it appears that the identity attribute information required for account creation and the all Entitlement values are both payloaded to the plan according to the provisioning policy.
However, since there is a separate endpoint for adding entitlements with the issued ID after the account is created, how can the API calls for account creation and entitlement addition requests be managed separately?
Any advice on how to resolve this situation would be greatly appreciated.
I may be misunderstanding the required endpoints, but you may just need a single create account operation, entitlement add operation, and get object operation. These will be three separate operations.
If the generated ID is returned in the create account response, you can map that to an account attribute. The Account ID should be the unique generated ID account attribute. You can define the correlation logic from any account attribute to the identity UID.
In the entitlement add request, you can use $plan.nativeIdentity$ for the generated ID that was mapped from the create account operation. This will pull the account attribute set as the Account ID. In the body of this request, you can use $plan.<account-attribute>$ (where you replace <account-attribute> with the account attribute used for the entitlement).
On a Web Services connector, the operations will run as follows:
Create Account Operation
Add Entitlement Operation (depending on how many entitlements are added during creation, this may fire multiple times)
Get Object Operation
Note: Be sure to order the Get Object operation after the others in the operation configuration page.
I’m doing good. I hope you are as well. This is an interesting yet tricky use case. I’d recommend opening a new topic for this as it is different than this and this has already been solved. Once a new topic is opened, others can more easily find the help specific to their issues if they run into this.
Please tag me and I can provide some input to this.
