Introduction to user management
Control access to Moody's for Compliance with users and roles. Learn how roles define permissions and how identity provider integration works for federated accounts.
User management in Moody's for Compliance keeps your account organized and secure. It's how you decide who gets access and what they can do.
Access is defined using roles and permissions. These apply across the platform, from assessments and entities to configuration and admin features.
At a glance:
Users are assigned one or more roles.
Roles group permissions together.
Permissions control actions on specific resources.
A user's access is the sum of everything they're granted.
About users
Users are the people who can sign in to the platform.
Each user can be assigned one or more roles. Roles define permissions, and permissions decide what a user can see and do. This setup lets you give the right level of access without opening more than you intend.
About roles
A role is a named set of permissions. Roles make permissions easier to manage and reuse.
If you're a federated user, meaning your login is managed through your corporate SSO, roles can link to your identity provider (IdP) groups using an external ID. When group membership changes in your identity provider, the platform updates access automatically. Because of this synchronization, you can't manage IdP group members directly in the platform.
About resources
A resource is something that you can control access to, such as assessments, entities, or tasks.
If something needs permissions, it must exist as a defined resource in the platform.
About permissions
Permissions describe what actions a user can take on a resource.
The platform supports these permission types:
Permission | What it allows |
|---|---|
View | View or open the resource. |
Create | Create new instances of the resource. Create permission implies that View permission is granted. |
Edit | Modify existing instances of the resource. Edit permission implies that View permission is granted. |
Delete | Delete instances of the resource. Delete permission implies that View and Edit permissions are granted. |
Share | Grant others access to a specific instance of the resource. Access is granted based on your own permission levels. Share permission implies that View permission is granted. |
Not every resource supports every permission type.
Permissions can apply at different levels, depending on how specific access needs to be:
All: Permissions apply to every instance of a resource, for example, View all assessments, Edit all entities, and so on. This is the baseline access to the resource.
Per qualifier: Permissions can be applied to a specific subset of a resource, such as one assessment template or configuration type. This lets you give extra access in some cases without changing a user’s general access to that resource.
Per instance: Permissions can be applied to individual resource instances by sharing access with a user. For example, sharing a single assessment.
Shared access applies only to that specific instance and is added to the user's role-based permissions. Only users who already have permission to share an instance can grant access to others, and they can only grant permissions they already have.
A user's effective access is calculated by combining all the permissions they're granted:
Permissions from all roles are combined.
If any role grants a permission, the user has it.
Shared permissions add access for specific instances.
Implied permissions are applied automatically.
Permissions never cancel each other out. More specific access can add rights, but it can't remove broader access.
Default roles
The platform provides a small set of default roles to help you get started.
These roles are broad by design and intended to work across many use cases. You're free to customize them, rename them, or delete them entirely. They're a starting point, not a rulebook.
For a detailed breakdown of the default roles and the permissions they include, see Default roles.