Where a User's Roles Came From

When a user can see something they shouldn't - or can't see something they should - the question is always the same: where did that role come from? A role can arrive in one of three ways in CloudRadial UCP - assigned directly, granted by a type mapping, or inherited from a legacy user group - and the portal records which one for every assignment.

This article covers where to look and how to read what you find.

• Where to Look
• Reading the Attribution Column
• Reading the Scope Column
• Why Some Rows Can't Be Deleted
• Working Out Why a Mapping Granted a Role

Where to Look

1. Go to Partner > Clients and select the Users tab.
2. Select the user.
3. Select the Role Assignments tab.

The tab lists every role the user holds, with three columns: Role, Scope and Attribution.

There is also a partner-wide list at Partner > Security > Role Assignments. That one is for finding who holds a role across all your clients - it does not show attribution. For "where did this user's roles come from", use the per-user tab above.

Reading the Attribution Column

Attribution answers one question: what put this role on this user?

"Inherited from Type Mapping" with no type name is not an error. Role assignments made before per-type attribution existed were not recorded against a specific type, and they are not retroactively labelled. If Automatically revoke roles when a contact's type no longer matches the PSA is on, the next sync that still justifies the role will stamp it with the granting type; with that setting off (the default), a role granted by a type mapping stays unnamed. Either way, a mix of named and unnamed type-mapping rows on one user is expected.

A role that used to come from a type mapping and now reads Direct is also normal, and is worth recognising. By default, when a contact stops matching the type that granted a role, the role is not removed - it is reclassified as Direct and stays (if your portal has the automatic-revoke setting turned on, it is deleted instead). So a Direct role is not proof that a person assigned it; it may be a type mapping's leftover. See Automatically Revoking Roles When a PSA Type Changes.

Reading the Scope Column

Scope says where the role applies:

• The client's name - the role applies to that client. This is the normal case.
• Partner - the role applies at partner level, across your portal. Type mappings cannot create these.
• A partner group name - the role applies through that partner group.

Scope matters when you are chasing access that a per-client setting won't explain. A role scoped to Partner will not be removed by anything configured on a type mapping, no matter what that mapping says.

Why Some Rows Can't Be Deleted

There is a delete control on this grid, and whether you see it depends on three things:

• It is not shown at all if the user has only one role assignment. A user is never left with none.
• It is not shown if you do not have Delete permission for that client.
• On the rows themselves, it only appears against Direct assignments.

Anything attributed to a type mapping or to a group has no delete control, because deleting it here would not hold - the next sync, or the user's continued group membership, would put it straight back. To remove a type-mapping role you have to remove the cause: change the contact's type in the PSA, or change the mapping. A role inherited from a user group has no screen to change it any more; contact support, and see the migration article linked under Related.

Working Out Why a Mapping Granted a Role

Once the Attribution names the type, the rest is a straight lookup:

1. Note the type name in the Attribution - for example Internal IT Staff.
2. Go to Partner > Settings > Type Mappings and open the mapping with that exact name.
3. Its Role Assignment(s) list is where the role came from.

Two things to keep in mind while you do this:

• A user can hold the same role from two types at once. If Automatically revoke roles when a contact's type no longer matches the PSA is on, and a contact carries both Internal IT Staff and Power User and both mappings grant the User role, you will see two rows, one per type. With the setting off, the role is a single unnamed row. That is deliberate - it is how the portal knows the role is still justified if only one of the types goes away.
• A user's roles are the combination of every matched type, not just one. If the roles on the user don't match the mapping you're looking at, check whether the contact carries other types in the PSA as well. Type Mapping: Mapping PSA Types to CloudRadial Roles covers how multiple types combine.

If the Attribution says a type mapping granted the role but no mapping by that name exists any more, the mapping was deleted after the grant. The assignment stays until the next sync reconciles it.

Related

• Type Mapping: Mapping PSA Types to CloudRadial Roles - every control on a mapping, and multi-type behaviour
• Automatically Revoking Roles When a PSA Type Changes - why a role may read Direct when a mapping granted it
• Understanding Security Roles
• Understanding the User Groups to Roles Migration

If you are still having trouble, we're here to help!

Submit a ticket here for assistance, and don't forget to check our status page to ensure there are no outages in your area.