Workiva SaaS Connector

[amvaseem2025 (Muzeer Vaseem Abdul)]

IdentityNow has a direct connector available to integrate with Workiva. While the integration is achievable, I have noticed a few issues, I wanted some suggestions from the community.

Workiva has different workspaces, and each workspace has got different entitlements. For a user to be assigned a Workiva entitlement, he should already be a part of the workspace. This is a known limitation from Workiva.

" When using SCIM groups to add a user to a workspace role or workspace group, the user being added must already be a member in the workspace (see Step 5: Manage user roles and groups for more details). If they’re not already a member in the workspace, our system will hold for up to 30 seconds before failing while we wait for your identity provider to request the user be added to the workspace. If they’re added before time runs out, this action will be resumed and completed successfully."

If we create one access profile to one entitlement in IdentityNow the access profile assignment will fail with below error:
“[“openconnector.ConnectorException: Please make sure User is a member of Workspace : workspace:QWNjb3VudB8xMTgzODAxMTg0OQ before adding them to Workspace Group: workspace:QWNjb3VudB8xMTgzODAxMTg0OQ:group:V0ZHcm91cB5XRkdyb3VwOmUyYTQ0OTNiLTI1YWEtNDFjMS1iNWQwLWU1OGQyMzQzNWE4MA”]”

Instead, we can add the workspace entitlement along with the actual entitlement in the access profile. So that, when the entitlement is being assigned, the user will be made part of the workspace, if he is not already part of it.

Although, this type of design works well when user is requesting multiple access profiles from same workspace, it fails when any of the existing access profiles are being revoked from the user. i.e., When user has two access profiles say “Editor” and “Viewer” from Workspace1 and “Viewer” is being revoked, the user is completely being removed from the workspace.

This is against my understanding of IdentityNow dealing with access profiles / entitlements:

IdentityNow uses a cumulative model for entitlements:

** It tracks entitlements based on access profile membership.*
** If an entitlement is provided by multiple access profiles, it is only removed when all profiles that grant it are revoked.*

This ensures that users don’t lose access prematurely due to overlapping entitlements..

Please suggest.

[udayputta]

@amvaseem2025

** If an entitlement is provided by multiple access profiles, it is only removed when all profiles that grant it are revoked.*

I believe this is the behaviour with access profiles. Why don’t you go with roles and have seperate access profiles with workgroups and the access that you need. That way if one role is removed SailPoint will validate and then skip the common entitlement.

[amvaseem2025 (Muzeer Vaseem Abdul)]

Thanks for the reply Uday.

We already have a process that triggers these access profile assignments from ServiceNow. So, creating a combination of role + access profile for this one particular application may not be feasible in our case.

The main question is when the below is our understanding, why would it not work in my case and how to fix it.

" If an entitlement is provided by multiple access profiles , it is only removed when all profiles that grant it are revoked."

I can see IdentityNow triggers two Revoke Events when I revoke an access role with two entitlements (one common and one specific) from user. One Revoke Event for each of the above entitlements gets triggered and can be seen from Users events tab.

Thanks
Vaseem

[zachm117 (Zach Mullins)]

Hey @amvaseem2025!

I have a few different thoughts you can consider to see what might work best for your situation.

I think an important question when considering these options is, how many workspaces and other entitlements are available for provisioning?

1. Create a Role that assigns the workspace entitlement
   Using my environment as an example, you can see my Workiva account has the base workspace entitlement and some others.
   
   

You could then build a role to assign the base workspace entitlement if an account has any of the other more granular workspace entitlements. Some thing like this:

The value is “workspace:w_44ba046f2b884945a7778832c462280f” in my case (yours will be different). But this will check to see if the account has any entitlements that correspond to that workspace, and will add the base workspace entitlement.

However, once this base workspace access is added, it will never be removed by the role, even if all of the other workspace entitlements are removed since the criteria will always match the base access. I’m not sure if this is acceptable for your situation or not, and you would probably have to build our separate roles or use dimensions for each workspace so the correct base entitlement is added.

2. Use a Before Provisioning rule
   I don’t think the Standard Services Before Provisioning rule would work in this case since it doesn’t have an Add Entitlement action, but you could write your own custom Before Provisioning Rule that checks if a user is being added to a group that starts with “workspace:w_44ba046f2b884945a7778832c462280f*” (using my example from above), it then adds the base workspace entitlement. Similar to my first suggestion, you would have to build out a condition for each workspace.

3. Use a Workflow
   You could use something like the Provisioning Completed trigger to trigger on any entitlements being added in the Workiva source. This could get a bit complex, depending on the number of your workspaces, but it can then check which workspace entitlement is being added by looking at the first part of the entitlement that was provisioned, and then add the respective base workspace entitlement.

Please let me know if any of these suggestions were helpful!

• Zach