Project Visibility & Access Control

Visibility defines who can see a project. Access control defines who can actually work inside it. In AXQA, these two concepts are intentionally separated to give you flexibility without losing control.

Why it matters

• Protects sensitive test data and client environments.
• Prevents unauthorized executions or changes.
• Allows controlled collaboration across teams.

When to use it

• You want a project to be visible to many users but editable only by a few.
• You need strict control over who can execute tests.
• You’re working with external stakeholders and need limited access.
• You’re reorganizing teams and adjusting access levels.

Core concepts

• Visibility – determines who can see a project in the platform.
• Access Level – determines what actions a user can perform.
• Owner – the primary responsible user for the project.
• Team Member – a user explicitly added to collaborate on the project.
• Execution Permission – separate control that governs whether a user can run tests.

How it works

1. Each project has a visibility mode (Private, Team-based, or Public).
2. Visibility determines whether a user can view the project.
3. Access rules then determine what the user can do (edit, manage, execute).
4. Execution rights are validated separately to prevent unintended test runs.
5. If a user attempts an unauthorized action, the system blocks it and returns a clear message.

How to use it

Step 1: Choose the appropriate visibility level

When creating or editing a project, select:

Private – only specific authorized users can see it.Team-based – visible to selected members added to the project.Public – visible to a broader audience inside the organization. 

Step 2: Add or review team members

For controlled collaboration, explicitly add users who need access. Visibility alone does not automatically grant full permissions.

Step 3: Verify execution permissions

Running tests is a sensitive action. Even if a project is visible, only authorized users can execute test cases or plans.

Step 4: Test the access scenario

If unsure, log in as a test user and verify what actions are available. The platform clearly blocks restricted actions.

Best practices

• Default to controlled access unless openness is intentional.
• Review permissions regularly when team structure changes.
• Separate “visibility” decisions from “execution” decisions.
• Document who owns and manages each project.

Common mistakes

❌ Assuming Public means everyone can execute tests
✔ Visibility does not equal execution rights — these are handled separately.

❌ Adding users without clarifying their role
✔ Define clear responsibilities before granting access.

❌ Forgetting to remove access after a team change
✔ Periodically review and clean up project memberships.

Security & permissions

• All sensitive actions are validated before execution.
• Unauthorized actions are blocked and logged.
• Execution rights are strictly enforced to prevent accidental or malicious runs.

Related documentation

• Creating a Project
• Managing Project Settings
• Security & Permissions Overview