Hi,
In Webservice connector, During add entitlement operation, I want to pass the manager email in the JSON body. Is this possible to achieve without Cloud rule?
Requirement : For a particular role: CSR, I need to send managerEmail as mandate field in the payload.
I tried using UPDATE POLICY AND ASSIGN POLICY, it is not working
Hello @chandramohan27
If you don’t want to use a rule you can add multiple Http Operations to pre-load the manager information as a first Add Entitlement and then use the response in the second Add Entitlement Operation.
I hope it helps!
Yes, but only if the manager email is already available in the provisioning plan or identity attributes.
Without a Cloud Rule, the Web Services connector cannot dynamically perform an identity lookup to fetch the manager’s email during provisioning. However, you can try:
Adding the manager email as an Identity Attribute.
Using provisioning policy field mappings or request templates to populate the value.
Referencing the identity attribute in the request body using connector placeholders, for example
`{
“role”: “CSR”,
“managerEmail”: “$identity.managerEmail$”
}`
If the manager email is not available in the provisioning plan/account request payload, then a Before Provisioning Rule (Cloud Executed Rule) or connector customization will be required to retrieve and inject the manager’s email before the Add Entitlement operation.
For the specific requirement of sending managerEmail only when the CSR role is assigned, a Before Provisioning Rule is typically the most reliable approach, as it can inspect the role being provisioned and conditionally add the required attribute to the request payload.
Hi Chandra. $identity.managerEmail$ is not a documented Web Services connector placeholder. The supported contexts are $plan, $response, $application, $getobject, and $authenticate. Also, $plan.managerEmail$ works only when that value already exists in the provisioning plan. Reference
@WhiteBat multiple-operation approach can work if the target API has an endpoint that returns managerEmail. The next operation can then use $response.managerEmail$.
If managerEmail exists only as an ISC identity attribute, use:
plan.getIdentity().getStringAttribute("managerEmail") and store it using accountRequest.addArgument("managerEmail", value).accountRequest.getArgument("managerEmail") and add it to the request body.Using an account-request argument is preferable because additional AttributeRequests may be filtered before reaching the connector rule.
So, without a Cloud Rule, this is possible only when the value can be retrieved from the target API or another connector response. Otherwise, the Before Provisioning Rule is the appropriate solution
Hi Chandra,
you can use parent-child chaining to achieve this without the cloud rule.
use https operation to fetch manager metadata Then the Add Entitlement operation with the target application.
In response mapping that manager’s email path to be added.
In the child operation - assign the role with response .
looks like - “managerEmail”: “$response.managerEmail$” in the JSON body. Check something like that if that works with CSR Role assignment.
Thankyou.. I think I can use Service Standard Before Provisioning rule to add the arguments in plan. Will that work?
[
{
"op": "add",
"path": "/connectorAttributes/cloudServicesIDNSetup",
"value": {
"eventConfigurations": \[
{
"eventActions": \[
{
"Action":"AddArgument",
"Attribute":"identityManagerEmail",
"Value":"#{identity.managerEmail}"
}
\],
"Entitlement Update Triggers":\[
{
"Attribute":"group",
"Operation":"Add",
"Value":"CSR"
}
],
"Operation": "Modify"
}
\]
}
}
]
Yes, the Services Standard Before Provisioning Rule supports AddArgument, so this approach should work.
Your configuration looks correct. Just verify that:
group is the exact entitlement attribute name on that source.CSR is the entitlement’s actual value, not only its display name.managerEmail is a populated identity attribute.You can then retrieve identityManagerEmail from the AccountRequest arguments in the Web Services Before Operation Rule and add it to the request body.
If the email exists on the manager’s identity rather than as managerEmail on the user’s identity, use:
"Value": "#{manager.email}"
Otherwise, your current value is correct:
"Value": "#{identity.managerEmail}"