GET /api/v2/workgroups

[tyler_mairose]

Replaced by

list-workgroups | SailPoint Developer Community

[nhassan (Noor Hassan)]

Hi @tyler_mairose

The documented schema of responses from beta/workgroups is not what we are getting.

When we list governance groups, we are getting different result for the owner i.e along with getting type, id, name, we’re getting dislplayName and emailAddress too.

Can you please check this and then advise? Thanks

[nhassan (Noor Hassan)]

Hi @tyler_mairose

Another thing we found (related to the list-workgroups API), ‘Patch a Governance Group’ API patch-workgroup | SailPoint Developer Community doesn’t seem to be working as it returns below error message.

Status code: 405
errorName: “NotSupportedException”
errorMessage: “RESTEASY003065: Cannot consume content type”

Can you please try this at your end?

Thanks in advance for your help with these two APIs.

[colin_mckibben]

@nhassan

doesn’t seem to be working as it returns below error message.

That error occurs when you don’t explicitly set the Content-Type header to application/json-patch+json. Please make sure your request header is set properly.

[colin_mckibben]

@nhassan

When we list governance groups, we are getting different result for the owner i.e along with getting type, id, name, we’re getting dislplayName and emailAddress too.

Thanks for pointing this out @nhassan . I have confirmed that emailAddress and displayName are returned in the response. This is expected behavior. A fix for the spec will be published shortly.

[nhassan (Noor Hassan)]

Thanks @colin_mckibben for the updates. Appreciated!

A few more things as mentioned below.

1. List Governance Groups - As shown in attached screenshot, for owner name, I think this should be ‘name’ instead of Owner’s display name.

2. The owner schema is inconsistent from other resources e.g List Access Profiles and List Roles. Is there any plan to make the owner schema consistent across other resources?

3. List Identities - The schema here doesn’t define displayName.

Thanks

[colin_mckibben]

I’ll get the name description fixed. As for points 2 and 3, our object refs usually have at least an id, name, and type, but each endpoint may add more information as needed.

[nhassan (Noor Hassan)]

Hi @colin_mckibben

I have been advised to feedback on this.

We are sorry but making the owner schema consistent across different resources is very important for us as we are managing changes to IDN PROD via Terraform.

If the owner schema isn’t consistent, it means when creating a client we are required to maintain 2 separate types now to accommodate the inconsistency.

The ‘name’ isn’t providing a name though. If ‘name’ and ‘displayName’ was providing the same info then that’s fine but in our case, ‘name’ can be an employee ID (numbers value). So, it’s not consistent with the schema defined in 3 other resources. If I use myself as an example, when creating a new governance group via create-workgroup | SailPoint Developer Community name would be Noor Hassan, but on retrieval this would be my ID e.g 1897.

Thanks

[angelo_mekenkamp]

Hi @nhassan,

We have observed the same issues. I have created a document last year on the inconsistencies of beta and v3 APIs and how this impacts us. You can find this one and more here:

Discrepancies IdentityNow APIs

Introduction Hi everyone! I have noticed inconsistencies among the different IdentityNow APIs. I have created a list of discepancies between different IdentityNow APIs (see attachment). We would prefer to see consistent behaviour among these APIs for the following reasons: Predictability IDN developers will be able to adopt/use new (or to them new) APIs easier if they behave in a similar way as the APIs they have already worked with. As example consider pagination. With parameters like offset,…

[nhassan (Noor Hassan)]

Thanks @angelo_mekenkamp for the update.

This is very useful to know all this Great work.