Hello everyone,
I am working with a Web Services Connector Source in SailPoint ISC, and I am facing an issue during an Add Entitlement provisioning operation.
To assign the entitlement, the target API requires both the account identifier (id / nativeIdentity) and the user’s email in the request body.
The payload expected by the target application is similar to:
{
"id": "{{userId}}",
"email": "{{email}}",
"roles": [
"{{role}}"
],
"merchantId": "10101010"
}
The issue is that, during the Add Entitlement operation, I am unable to retrieve the email attribute from the ProvisioningPlan.
When inspecting the plan inside a Web Services Before Operation Rule, I can identify an AccountRequest with the Modify operation, but the AttributeRequests only contain the entitlement-related attribute (roles). The email attribute, although it is part of the Source Account Schema, is not present in the plan.
For example, the rule logs show:
AccountRequests: 1
AccountRequest operation: Modify
Attribute: roles
email not found in ProvisioningPlan
I have already tried several approaches to make the email available during this provisioning flow:
1. Using $plan.email$ directly in the request body
Initially, I tried:
"email": "$plan.email$"
However, during Add Entitlement, the value is not resolved. My assumption is that this happens because email is not included as an AttributeRequest in the ProvisioningPlan for this operation.
2. Creating an ASSIGN Provisioning Policy
I also created a Provisioning Policy to try to add the email to the plan using an Identity Attribute:
{
"name": "emailadd",
"transform": {
"type": "identityAttribute",
"attributes": {
"name": "email"
}
},
"attributes": {},
"isRequired": false,
"type": "string",
"isMultiValued": false
}
The expectation was that I could then access this value through emailadd.
However, during the Add Entitlement operation, emailadd was also not present in the AttributeRequests of the ProvisioningPlan.
3. Configuring two sequential ADD operations
Another approach I tried was configuring two separate calls as part of the ADD operation.
The first call would query the existing Get Object/Get Account endpoint to retrieve the current account information.
Then, in the second call, I tried to reuse a field returned by the first response with something similar to:
$response.email$
However, I was also unable to make the email available this way for the second request body.
There is an additional limitation with this approach: the target application’s Get Account endpoint itself requires the email address as one of its query parameters.
The endpoint follows approximately this format, exemple:
GET /users/merchantId=10101010?email={{email}}
In the existing and functional Get Account configuration, the parameter is populated using:
?email=$plan.email$
Therefore, using an additional GET request through restClient to retrieve the email creates a circular dependency: in order to query the account and retrieve its email, I already need to know the email.
4. Using a Web Services Before Operation Rule
Finally, I created a Web Services Before Operation Rule to iterate through:
ProvisioningPlan
-> AccountRequest
-> AttributeRequest
and attempted to retrieve both email and the auxiliary emailadd attribute.
However, the logs confirmed that during the Add Entitlement operation, only roles is available in the AttributeRequests.
My main question is:
Is there a supported/recommended way in the Web Services Connector to make an account or identity attribute, such as email, available in the ProvisioningPlan during an Add Entitlement operation, even when that attribute itself is not being modified?
Alternatively, is there a recommended way to access the Identity Attribute email from a Web Services Before Operation Rule in this context?
The final goal is simply to generate the following payload:
{
"id": "<nativeIdentity>",
"email": "<user's current email>",
"roles": [
"Manager"
],
"merchantId": "10101010"
}
without having to perform an additional external lookup just to retrieve the email address.
In another project with a similar requirement, we worked around this by making a call to the SailPoint ISC Search API to locate the corresponding identity and retrieve its email address. However, before following the same approach again, I would like to understand whether there is a more appropriate solution using the ProvisioningPlan, a Provisioning Policy, or another object/context already available to the Web Services Before Operation Rule.
Has anyone encountered a similar scenario with an Add Entitlement operation using the Web Services Connector? Is there a SailPoint-recommended approach for making additional identity/account attributes available during this type of provisioning operation?
Thank you!