Managing Project Members
Invite team members, assign roles, control project access, and understand the permission model for collaborative SIP testing.
CallMeter uses a role-based access control (RBAC) system to manage who can access projects and what actions they can perform. Members are managed at the organization level, and their access to individual projects is controlled through project assignments.
How Project Access Works
Member access in CallMeter follows a two-layer model:
- Organization membership -- A user must first be a member of your organization
- Project access -- The organization admin then grants them access to specific projects (or all projects)
Each organization member has:
- A role that determines their permissions (Viewer, Tester, Editor, Admin, or Owner)
- A project access setting that controls which projects they can see
| Access Type | Behavior |
|---|---|
| All Projects | The member can access every project in the organization, including any projects created in the future |
| Specific Projects | The member can only access the projects explicitly assigned to them |
Inviting Members to Your Organization
Before a team member can access a project, they must be part of your organization.
- Navigate to your organization Settings
- Click on the Members tab
- Click Invite Member
- Enter the invitee's email address
- Select their role (see the role permissions table below)
- Choose their project access: All Projects or Specific Projects
- If you selected Specific Projects, check the boxes next to the projects they should access
- Click Send Invitation
The invitee receives an email with a link to join your organization. Once they accept, they gain immediate access to their assigned projects.
Pending invitations
Invitations remain pending until the recipient creates a CallMeter account (or logs in with an existing one) and accepts. You can revoke pending invitations from the Members page at any time.
The Five Roles
CallMeter provides five roles with progressively broader permissions. Each role inherits all permissions of the roles below it.
| Role | Description |
|---|---|
| Viewer | Read-only access. Can view test results, probe health, and dashboards but cannot create, modify, or execute anything |
| Tester | Everything a Viewer can do, plus the ability to run existing tests. Cannot create or modify test configurations |
| Editor | Everything a Tester can do, plus full create/edit/delete permissions on tests, registrars, probes, media files, and other project resources |
| Admin | Everything an Editor can do, plus organization-level management: inviting members, managing roles, configuring billing, and deleting projects |
| Owner | Full control. One per organization. Can transfer ownership, manage all billing, and perform all administrative actions. Cannot be removed |
Detailed Permission Matrix
The table below shows exactly which actions each role can perform within accessible projects:
| Action | Viewer | Tester | Editor | Admin | Owner |
|---|---|---|---|---|---|
| View test results and metrics | Yes | Yes | Yes | Yes | Yes |
| View probe health status | Yes | Yes | Yes | Yes | Yes |
| View registrars and SIP accounts | Yes | Yes | Yes | Yes | Yes |
| View project settings | Yes | Yes | Yes | Yes | Yes |
| Run existing tests | No | Yes | Yes | Yes | Yes |
| Stop running tests | No | Yes | Yes | Yes | Yes |
| Create and edit tests | No | No | Yes | Yes | Yes |
| Create and edit registrars | No | No | Yes | Yes | Yes |
| Manage SIP accounts | No | No | Yes | Yes | Yes |
| Upload and delete media files | No | No | Yes | Yes | Yes |
| Create and edit probes | No | No | Yes | Yes | Yes |
| Configure webhooks | No | No | Yes | Yes | Yes |
| Create and edit status pages | No | No | Yes | Yes | Yes |
| Delete tests, registrars, probes | No | No | Yes | Yes | Yes |
| Invite organization members | No | No | No | Yes | Yes |
| Remove organization members | No | No | No | Yes | Yes |
| Change member roles | No | No | No | Yes | Yes |
| Manage project access assignments | No | No | No | Yes | Yes |
| Delete projects | No | No | No | Yes | Yes |
| Manage billing and subscriptions | No | No | No | No | Yes |
| Transfer organization ownership | No | No | No | No | Yes |
Granting Project Access to Existing Members
If a member is already in your organization but needs access to additional projects:
- Go to organization Settings then Members
- Find the member in the list
- Click on their name or the edit icon
- Change their project access setting or add/remove specific projects
- Click Save
Changes take effect immediately. The member sees the newly accessible projects in their sidebar on next page load.
Removing a Member's Project Access
To revoke a member's access to a specific project without removing them from the organization:
- Go to organization Settings then Members
- Find the member
- Edit their project access
- Uncheck the project you want to revoke
- Click Save
The member loses access to that project immediately. They can no longer view tests, results, or any resources within it.
Removing a Member from the Organization
Removing a member revokes all their access across every project:
- Go to organization Settings then Members
- Find the member
- Click Remove
- Confirm the action
Active tests
If the removed member had running tests or active probes, those continue to execute normally. Removing a member does not affect in-progress operations.
Role Selection Guide
Choosing the right role for each team member depends on their responsibilities:
| Team Member | Recommended Role | Rationale |
|---|---|---|
| QA engineer running tests daily | Tester | Needs to execute tests and view results, but should not modify configurations |
| VoIP engineer configuring tests | Editor | Needs full control over test configurations, registrars, and probes |
| Management reviewing dashboards | Viewer | Only needs to review results and probe health |
| Team lead managing the workspace | Admin | Needs to invite members, manage access, and oversee project settings |
| Customer stakeholder (MSP scenario) | Viewer | External stakeholders should only view results for their project |
Organization-Level vs. Project-Level Access
It is important to understand that roles are set at the organization level, not per-project. A member with the Editor role has Editor permissions in every project they can access. You cannot give someone Editor access in one project and Viewer access in another.
To limit what a member can do, choose between:
- Restricting their role -- Give them a lower role (e.g., Tester instead of Editor) that applies everywhere
- Restricting their project access -- Keep their role but limit which projects they can see
This design keeps permissions simple and predictable across your organization.
Next Steps
- Roles and Permissions -- Full RBAC reference with additional details
- Project Settings -- Configure project metadata
- Creating a Project -- Set up a new project workspace