Role-Based Access & Project Membership in AXQA

Projects are not just containers for test cases — they’re collaborative workspaces. Membership and roles define who is involved, who is responsible, and who can perform specific actions inside the project.

Why it matters

• Creates clear ownership and accountability.
• Prevents unauthorized changes or executions.
• Keeps collaboration structured instead of chaotic.

When to use it

• You’re onboarding new testers to a project.
• You need to delegate responsibilities.
• You want to restrict editing or execution to specific users.
• A team member changes department or leaves the company.

Core concepts

• Project Owner – The main responsible person for the project. Has full control.
• Team Member – A user explicitly added to collaborate on the project.
• Role-based actions – Different users may have different capabilities depending on their role.
• Membership – The connection between a user and a specific project.

How it works

1. When a project is created, the creator becomes the owner.
2. Additional users can be added as team members.
3. Each member gains access according to the project’s visibility and access rules.
4. Execution and editing rights are validated before any sensitive action.
5. If a member is removed, their access to the project is immediately revoked.

How to use it

Step 1: Add team members

Open Project Settings and select the users who should collaborate on the project. Save your changes to grant them access.

Step 2: Define responsibilities

Clarify internally:

Step 3: Review memberships regularly

If someone moves to another team or leaves the company, remove their access. Keep project memberships clean and intentional.

Best practices

• Keep the number of owners limited to avoid confusion.
• Add only necessary members — avoid “just in case” access.
• Align project roles with real organizational structure.
• Review access during major project milestones.

Common mistakes

❌ Giving broad access without clear responsibility
✔ Assign clear ownership and define who does what.

❌ Forgetting to remove access after role changes
✔ Audit memberships periodically.

❌ Assuming visibility automatically grants full control
✔ Membership and execution permissions are validated separately.

Security & permissions

• Only authorized users can modify project membership.
• Sensitive actions (editing, execution) are validated against access rules.
• Access changes take effect immediately.

Related documentation

• Creating a Project
• Project Visibility & Access Control
• Managing Project Settings