Users Roles
Users and roles
A user is a person on the team. A role is a job title that unlocks permissions. In everyday life a role is like “office manager” versus “staff.” In CROForge every workspace member is an Owner, Admin, or Member. Owners and Admins invite people from Settings → Users. Each user also has a status of Active, Inactive, or Terminated, which decides whether they can still open the workspace.
Words used on this page
| Word | Everyday meaning | Meaning in CROForge |
|---|---|---|
| User | A person who uses the product. | Someone with an account in this workspace. Managed under Settings → Users. |
| Role | A job title that unlocks permissions. | Owner, Admin, or Member. Chosen when inviting. Owner is usually not assignable via invite. |
| Permission | What you are allowed to do. | The actions a role can perform: invite users, change settings, create experiments, edit Data Vista, view activity logs, and so on. |
| Owner | The person who owns the office. | Full control: users, settings, experiments, and billing-adjacent decisions. Created when the workspace is created. Highest role (internal value 0). |
| Admin | A trusted manager. | Can invite users, run experiments, and manage configuration. Cannot do Owner-only billing or ownership transfer. Internal value 1. |
| Member | A regular teammate. | Can create and edit experiments and Data Vista objects within policy. Cannot invite or remove users. Internal value 2. |
| Invitation | A request to join the team. | Sent by Owners and Admins. Role on the invite is Admin or Member. See Invitations. |
| User status | Whether the person still works here. | Active, Inactive, or Terminated. Inactive and terminated users should not access the workspace. |
| Active | Currently working and allowed in. | User status value 0. The person can sign in and use this workspace. |
| Inactive | Paused, such as leave or a temporary offboarding. | User status value 1. Should not access the workspace until reactivated. |
| Terminated | Permanently removed from the team. | User status value 2. Should not access the workspace. Use this when someone leaves the company. |
| Deactivate | Turning access off without deleting history. | Set a user to Inactive (or Terminated) so they cannot open the workspace. Review activity logs afterward if needed. |
| Settings → Users | The staff list. | Where Owners and Admins invite by email, change roles, and manage statuses. |
| User activity | A diary of one person’s actions. | Per-user audit log under Settings → User activity. |
| Workspace activity | A diary of what happened in the whole office. | Workspace-wide audit log under Settings → Workspace activity. |
| Experiment | A controlled test. | All three roles can typically create and edit experiments. Members stay within policy; they do not manage the user list. |
| Data Vista | The place you define audience and measurement building blocks. | Attributes, segments, and metrics. All three roles can typically edit these objects. |
| Workspace | The team’s private work area. | Users and roles always belong to one workspace. Being Admin in workspace A does not make you Admin in workspace B. |
| Billing-adjacent | Decisions close to who pays. | Owner-only in the practical permission matrix (manage billing / ownership transfer). |
Screenshot placeholder for this page: workspace-users.png. Replace that file with a real screenshot and keep the same filename.
Where to manage users
Open Settings → Users. This list is for the current workspace only. Invite here, change a role when someone’s job changes, and set status when someone should no longer get in.
Roles
CROForge has three roles (USER_ROLES). Pick the smallest role that still lets the person do their job.
| Role | Everyday meaning | Typical powers in CROForge |
|---|---|---|
| Owner | Holds the master key. | Full control: users, settings, experiments, billing-adjacent decisions. |
| Admin | Trusted to run the office day to day. | Manage users (invite), experiments, and configuration. |
| Member | Does the testing work. | Create and edit experiments and Data Vista objects within policy. |
The practical matrix (product intent):
| Capability | Owner | Admin | Member |
|---|---|---|---|
| Manage billing / ownership transfer | Yes | No | No |
| Invite or remove users | Yes | Yes | No |
| Change workspace settings | Yes | Yes | Limited |
| Create or edit experiments | Yes | Yes | Yes |
| Edit Data Vista objects | Yes | Yes | Yes |
| View activity logs | Yes | Yes | Limited |
Treat the live API as the source of truth if a permission differs. The table above is product intent. Full numeric values and notes live in Roles and permissions.
User statuses
Status is separate from role. A person can be an Admin and still be Inactive. Role answers “what may they do.” Status answers “may they get in at all.”
- Active — allowed to use the workspace.
- Inactive — should not access the workspace (paused access).
- Terminated — should not access the workspace (left the company).
Internal values (USER_STATUS): Active 0, Inactive 1, Terminated 2.
Admin tasks
- Invite by email and role (Admin or Member). Owner is usually not assignable via invite. See Invitations.
- Change role when responsibilities change, for example promoting a Member who now needs to invite others to Admin.
- Deactivate users who leave the company (Inactive or Terminated) so they cannot open the workspace.
- Review User activity and Workspace activity after sensitive changes. See Activity logs.
