With resource groups, your team can group related resources in your mabl workspace and apply more granular role-based access control (RBAC).
By giving different users different degrees of access to resources in your workspace, resource groups make it possible to…
- Comply with the security requirements of your organization by restricting access to protected resources to certain users.
- Ensure that workspace members only have access to the resources that are relevant to their work.
This article explains how resource groups control access to resources in your workspace.
Resource groups are available for all mabl Core customers and trial users. If your team is not on a mabl Core plan, reach out to your customer success manager for more information.
Resource groups
Workspace owners can create a new resource group by going to Settings > Resource groups. After creating the resource group, the workspace owner can add resources and decide who can access them.
At present, only credentials can be added to resource groups. At a later date, we will support adding other resources to resource groups.
Resource groups for managing credentials
Depending on your team's requirements, you can create resource groups that align with different team roles. For example, if the QA members of your team need access to all credentials, but the engineers only need access to credentials A and C, you can create two separate resource groups: one for the QA members of your workspace and another for the engineers.
Shared resources
Resources that are not part of a resource group are considered shared resources. All members of the workspace can access them to the extent that their workspace role allows. Unless a resource is added to a resource group, it becomes a shared resource.
Role assignments
When you join a mabl workspace, you are assigned a user role within the workspace. These roles define the permissions for interacting with shared resources.
When a workspace owner creates a resource group, they also assign and manage user roles at the resource group level. Resource group roles define the permissions for interacting with the resources that are part of that resource group.
Granting access to a resource group
Only workspace owners can create, update, and delete role assignments at the workspace level and the resource group level.
For a breakdown of permissions by role, see the reference on roles and permissions.
Restricting access
If a user is not a member of a resource group, they can see that the resource exists, but they cannot view, edit, delete, or use the resources in that resource group.
A restricted resource group
For example, if you are an editor of shared resources, you can create and manage all credentials that are not part of a resource group. If the credential is part of a resource group, your access depends on whether you were granted access to the resource group:
- If you have an assigned role in the group, you can access the credential.
- If you do not have an assigned role in the group, you can see that the credential exists, but you do not have permission to view, use, or interact with that credential.
In practical terms, not having access to credentials has the following implications:
- The credential is not available when you create, edit, or run tests and plans
- If a test run uses the credential, buttons to view the test output are disabled
- If another user shares a link to a test result that uses the credential, you will see an error if you visit the page.
Deleting resource groups
If a workspace owner deletes a resource group, the resources that belonged to that deleted resource group will still remain in your workspace. If the resources do not belong to any other resource groups, they will become shared resources.
Workspace owners can restore a resource group from the activity feed: Settings > Activity feed. When a resource group is restored, its associations with resources and users are restored as well.