Currently we’re aggregating a webservices connector that can only pull in entitlements for accounts based on a chain of aggregations.
The below is a basic idea of how its setup
Account Aggregation (accounts)
Account Aggregation (look up groups for individual user assignment. only provides a list of ids)
Group Aggregation (looks up information on each individual entitlement in the second call)
We get the name of the group in the group aggregation call. So we have the group id from that label as an entitlement with group type from our entitlement schema. In the entitlement schema we have the id, name, and description defined. The id is set as the entitlement id, and the name is defined as the entitlement name. This is done so it makes our entitlements human readable when we do our certification reviews.
The problem is, when we go to remove an entitlement from the user if we use $plan.id$ in the call it passes the entitlement name, rather than the entitlement id which is needed for the entitlement to be removed. Is there anyway to actually get that entitlement id in the provisioning plan with the way we have it setup? Trying to avoid manually having to set information on the entitlements, or creating a rule unless absolutely necessary.
Hi @ccraft - In the account schema, which attribute provides information about the entitlements associated with the account? Is that specific attribute marked as an entitlement, or is the id marked as an entitlement?
The attribute marked as entitlement in account schema appears in the plan. For example, during account aggregation, if the id attribute or a groupnamed attribute contains the entitlement names associated with the account, then that attribute should be marked as an entitlement. After doing so, you can reference it using variables such as $plan.id$ or $plan.group$ to retrieve the required entitlement values
In the account schema, the id of the group is marked as the entitlement with the entitlement type defined.
$plan.id$ is what we’re using in the call, however its passing the entitlement name. Which our entitlement type, in the entitlement schema has the id set as the Entitlement id, and name as the Entitlement Name. However, out of curiosity, does the entitlement flag need to be set on the specific item in the entitlement schema? I know we have another source that’s almost setup identical, however it doesn’t have that flag set on the object. in the entitlement schema.
Account schema example
accountId - string (Account ID)
accountName - string (Account Name)
groupId - group (set as entitlement and multivalued)
Entitlement Schema:
group type:
groupId - string (Entitlement ID)
groupName - string (Entitlement Name)
description - string
Hopefully that helps to picture how we have it setup. When we do the call I just do $plan.groupId$ and this is passing the groupName, rather than the groupId which is what I need.
@ccraft - Yes, this helps! By any chance, do you receive the groupName in the account aggregation response, or is it only the groupId? If the groupName is available, add it to your account schema, mark it as an entitlement, and then try using it.
If the groupName is not returned, there’s a possible workaround while keeping a similar configuration:
Create two ‘Remove Entitlement’–type HTTP operations. In the first operation, use $plan.groupid$ to call an API that retrieves the corresponding groupName. In the second operation, use $response.groupname$ from the first call to perform the actual ‘remove group’ API call, connect them by adding first remove entitlement HTTP operation as parent endpoint to the second one
If you have changed the Entitlement ID or name after aggregation then it would cause the noise. IF possible then try resetting the entitlements and check.
.