Child Hierarchy

Feedback Documentation Feedback Connectivity Documentation Feedback
1

The Web Services SaaS connector supports child hierarchy for entitlements. To achieve this, perform the following:

This is the companion discussion topic for the documentation at https://documentation.sailpoint.com/connectors/saas/web_services/help/saas_connectivity/web_services/child_hierarchy.html
2

Hi, :slight_smile:

There is little documentation visible here on child hierarchy. Can we perhaps get an example of what it looks like in the following two examples:

  1. We have a source whose groups are listed in the API GET ../groups. Besides this some groups here refer to other groups here to show an hierarchy. The reference goes from the child to the parent. AKA. each group has a field parentId which points to the parent.
  2. We have a different source whose groups are listed in the API GET ../groups. Besides this some groups here refer to other groups here to show an hierarchy. The reference goes from the parent to the child. AKA. each group has a field childrenIds which points to the children (can be an empty array).

In both cases, If you call GET .../users, it will contain a field groups, that only shows the most top level groups each user has. For example if you had a group for Belgium and then got the group for Europe, at that point it will only show the Europe group. After all Belgium is inherited through this hierarchy. If you now try to add the group for France, it will give an error saying you already have Europe. So we need ISC to understand that provisioning is not needed for France due to the hierarchy.

4

Hello again Angelo. Thanks for your input on this. I’ve created a Jira issue to track the effort and we’ll update the comment thread when it’s been addressed: CONDOCS-6671

5

Note that documentation is also showing XML, but IIQ is XML specific, for ISC it is just JSON we see and can manage.

Due to lack of documentation I am also trying trial and error to figure it out. I noticed by creating a ServiceNow source that it has "childHierarchy": "true" in the source schema for the corresponding entitlement type, and specifically under the configuration key. This can also be used for this source, and if you put false instead of true, you are not saying that there is no hierarchy, you are just saying that the hierarchy is flipped (Entitlement → Parent(s) instead of Entitlement → child(ren)). This is also good to document. And perhaps document what happens if you use this hierarchy. Suppose I request a role that amongst others contains an entitlement that is a child or lower offspring of an entitlement that I already have. Will ISC then know not to provision this child entitlement?

6

Through trial and error, I managed to get the hierarchy visible, but I now notice that if I have a parent entitlement and put a child entitlement in a role and request that role, that ISC is still trying to provision this entitlement, even though I already have this entitlement indirectly as I have the parent entitlement, which results in a 409 conflict error, where the server mentions I already have a parent entitlement. Shouldn’t ISC deduce that adding the entitlement is not needed if I am already assigned an entitlement that is considered its parent entitlement according to the hierarchy?