Authorization and access control
Control Room Authorization Model
Users access Control Room via login or by using Access Credentials. Organizations and Workspaces are Control Room specific terms that describe the authorization layer. Robocorp Workforce Agent and Robocorp Assistant are the applications that execute robots.
User is used to log into Control Room via cloud.robocorp.com, or users may use Control Room via her or his access credentials. For optimal security, do not use shared accounts but allow each Control Room user to register with her or his account.
Access credentials grant programmatic access to Control Room and can perform actions such as uploading and downloading robots. For security purposes, it is important to note that these credentials should be treated with as much secrecy as login credentials, as they grant an equal amount of access to a Robocorp account. A user can have multiple Access Credentials.
Users can be a part of multiple Organizations that host many Workspaces. Other users can be added to an organization. Upon joining, the users can have access to all of the workspaces under the organization. One user can be a member of multiple organizations. Workspaces are smaller units inside an organization.
Robocorp Workforce Agent is always connected to a specific workspace and can access resources within that workspace. The same Robocorp Workforce Agent cannot be in multiple Workspaces simultaneously.
Robocorp Assistants link to Cloud users so that the Assistant user can see Assistants defined in all workspaces they have been invited to.
Role-based Access Control (RBAC) in Control Room
Control Room allows fine-grained role-based access control (RBAC) mechanisms on both the Organization and Workspace levels. These roles can be combined and leveraged to create efficient and secure ways of working with activities and processes in Control Room.
Organization
Owner
Owners have the most access over a Robocorp account. Most notably, they can access billing features and demote or promote other organization accounts to Admins or Owners. For optimal security, it is recommended not to use the Owner account for other tasks than account setup. It is good to consider the Owner account in an organization as the master or root account.
Each organization must have at least one account with the Owner role attached to it.
Admin
An Admin account can perform administrative actions in Control Room, such as create new workspaces and add users. Any Admin user can also promote other organization Members to Admins.
The Admin role cannot access features such as billing and compliance, which means it is better suited for daily activities than the owner role.
Member
The Member account has the least access in an organization. Users with the Member role can only view Workspaces they have been explicitly invited to in an Organization. If they are promoted to be a Workspace Administrator for a Workspace, they can add other Organization users to that specific Workspace.
The Member role is suitable for developers or consultants who do not need visibility into the configurations and other users in an Organization.
Data Analyst
The Data Analyst has the same permissions as the organization Member, but with the addition of being able to see the Organization Dashboard.
| Member | Admin | Owner | |
|---|---|---|---|
| View workspaces | ✔* | ✔ | ✔ |
| Add org users to workspaces | ✔** | ✔ | ✔ |
| Edit and view workspaces and permissions | ✔ | ✔ | |
| Add and remove users to organization | ✔ | ✔ | |
| Promote and demote member to Admin | ✔ | ✔ | |
| Promote and demote Admin to Owner | ✔ | ||
| Management, compliance | ✔ | ||
| Plan & Billing | ✔ |
* Only workspaces user has been added to
** Only when set as workspace administrator
Workspace
Workspace Administrator
Workspace Administrators have the most power over a Workspace and can invite new users, alter Workspace permissions for users, edit processes, unattended workers, and run processes.
The Administrator role in a Workspace is not equal to the Admin role in an Organization. To follow the principle of least privilege, your should assign to your Workspace Administrator the role of Member in the Organization.
Workspace Developer
The Workspace Developer cannot add users or modify permissions, but they can otherwise view and edit everything within the context of a Workspace. The Developer role should be used for robot developers whose task is to maintain and develop robots for unattended or attended automation, and users who require more access than run processes or view their results.
Workspace Operator
The Workspace Operator is a role suitable for users who need to run or schedule tasks and view the results of the processes, or run attended automations via the assistant application. The Operator role in a Workspace cannot alter any settings or invite new users, making it a good role to be used for daily tasks for running a premade process.
In the context of a Workspace:
| Operator | Developer | Administrator | |
|---|---|---|---|
| View processes | ✔ | ✔ | ✔ |
| Run, stop and schedule processes | ✔ | ✔ | ✔ |
| View and edit work items | ✔ | ✔ | ✔ |
| View robots | ✔* | ✔ | ✔ |
| List and Run Assistants | ✔ | ✔ | ✔ |
| Edit storage assets | ✔ | ✔ | |
| View storage assets | ✔ | ✔ | |
| Edit Assistants | ✔ | ✔ | |
| List and edit robots | ✔ | ✔ | |
| View and edit API keys | ✔ | ✔ | |
| View and edit vault | ✔ | ✔ | |
| Edit processes | ✔ | ✔ | |
| View and edit workspace permissions | ✔ | ||
| Add or remove users | ✔ | ||
| Link Workers | ✔ |
* Workspace operators can access the robots for running assistants, but cannot see the robots page in UI