Team Management

Who is this for? Engineering Managers, IT Administrators, and VPs of Engineering configuring team access, authentication, and enterprise security controls.

ContextQA uses workspaces to organize testing projects. Each workspace is an isolated environment with its own test cases, environments, settings, and team members. This page covers how to create and manage workspaces, invite and manage users, and configure workspace-level settings.

---

Workspaces

What Is a Workspace

A workspace is the top-level organizational unit in ContextQA. Everything in ContextQA — test cases, test suites, test plans, environments, execution history, integrations, and user access — lives within a workspace.

Each workspace is completely isolated from others. Test cases in Workspace A are not visible from Workspace B. Users must be explicitly invited to each workspace they need access to.

Typical workspace patterns:

Pattern	Example
One workspace per product	Acme Web App, Acme Mobile, Acme API
One workspace per team	Frontend Team, Backend Team, QA Platform
One workspace per environment	Staging Tests, Production Monitoring
One workspace per client (agencies)	Client A, Client B

There is no fixed rule — organize workspaces in the way that matches your team's boundaries and access control requirements.

Creating a Workspace

1. Click the workspace selector dropdown in the top-left of the sidebar (it shows the current workspace name)

2. Click New Workspace (or + Create Workspace)

3. Enter a workspace name

4. Select the workspace type:

   • Web Application — browser-based UI testing

   • Mobile App — iOS and Android testing via device farm

   • API — REST API contract and integration testing

   • Salesforce — Salesforce-specific testing configuration

   • SAP — SAP testing configuration

5. Optionally add team members during setup by entering their email addresses

6. Click Create Workspace

After creation, you are switched to the new workspace automatically.

Switching Workspaces

Use the workspace selector dropdown in the top-left of the sidebar to switch between workspaces your account has access to. Click the dropdown, then click the workspace name you want to switch to.

If your account belongs to many workspaces, use the search field in the dropdown to filter by workspace name.

The workspace switcher feature requires a multi-workspace plan. If you do not see other workspaces in the dropdown, contact your workspace owner about plan access.

Workspace Settings

Navigate to Settings → Organization Settings to configure workspace-level settings:

Setting	Description
Organization name	Displayed in the workspace header and in shared report links
Default time zone	Used for scheduled test plan display and audit log timestamps
Default browser	Pre-selected browser when creating new test plans
Notification email	Fallback email for system notifications and scheduled test results

---

Managing Users

Viewing All Users

Navigate to Admin Settings → User Management to see a table of all users in the workspace. The table shows:

• Name

• Email address

• Role (Admin, QA Engineer, Developer, Viewer, or custom role)

• Status (Active, Invited, Suspended)

• Date joined or date invitation was sent

• Last active date

Use the filter controls to narrow the list by role or status.

Inviting Users

1. Navigate to Admin Settings → User Management

2. Click + Invite User

3. Enter the user's email address

4. Select their role from the dropdown (see Roles & Permissions for details on what each role can do)

5. Click Send Invitation

The invited user receives an email with an activation link. The link is valid for 7 days. After clicking the link, they set their password and are immediately active in the workspace.

If the invitation expires: Find the user in the User Management list (they appear with status "Invited") and click Resend Invitation.

Editing a User

1. Find the user in the User Management list

2. Click Edit (pencil icon) next to their name

3. Change their role or update their display name

4. Click Save

Role changes take effect immediately on the user's next page load.

Suspending a User

Suspending a user disables their login without deleting their account or any test cases they created. Use this when a team member leaves the organization.

1. Find the user in the User Management list

2. Click the Actions menu (three dots) next to their name

3. Click Suspend

4. Confirm the action

A suspended user cannot log in and will see an error message if they try. Their test cases, execution history, and contributions to the workspace are preserved.

To reactivate a suspended user: find them in the list (filter by "Suspended"), click Actions → Reactivate.

Removing a User

Removing a user permanently revokes their workspace access. Test cases and results they created remain in the workspace.

1. Find the user in the User Management list

2. Click Actions → Remove from Workspace

3. Confirm the action

This action cannot be undone. If you think you might want to restore access later, use Suspend instead of Remove.

---

System Audit Log

The audit log is the complete record of every action taken in the workspace. Admins can access it at Admin Settings → System Audits.

What the Audit Log Records

Every significant action generates an audit entry:

Action Category	Examples
User management	Invited user, changed role, suspended user, user logged in
Test case operations	Created test case, edited step, deleted test case
Execution operations	Executed test case, executed test plan, applied healing
Integration changes	Connected Jira, disconnected Slack, changed API token
Settings changes	Changed organization name, updated default browser
Workspace changes	Created workspace, modified workspace settings

Audit Entry Fields

Each audit log entry contains:

• Actor: The email address of the user who performed the action

• Action: A description of what was done (e.g., "Created test case 'Login - Happy Path'")

• Resource: The specific test case, user, or setting that was affected

• Timestamp: Exact date and time (in the workspace's configured timezone)

• IP Address: The IP address from which the action was performed

Using the Audit Log

For compliance: Export the audit log as CSV for inclusion in compliance reports (SOC 2, ISO 27001 access reviews).

For security: Filter by IP address to identify unusual access patterns (logins from unexpected locations, actions at unusual hours).

For troubleshooting: If a test case was unexpectedly modified or deleted, search the audit log by the test case name to see who made changes and when.

The audit log is read-only. Entries cannot be modified or deleted. Log retention follows your organization's contracted data retention policy.

---

iOS Provisioning Profiles

For mobile testing on iOS devices, Apple code signing certificates (provisioning profiles) must be uploaded to ContextQA before running iOS tests.

Uploading a Provisioning Profile

1. Navigate to Settings → Provisioning Profiles

2. Click + Upload Profile

3. Upload the .mobileprovision file downloaded from the Apple Developer Portal

4. The profile appears in the list with its expiration date

Profile Expiration

Provisioning profiles expire when the associated Apple Developer certificate expires — typically annually. ContextQA displays a warning when a profile is within 30 days of expiry.

Upload a renewed profile before the expiry date to avoid iOS test execution failures. The old profile can be deleted after the new one is active and verified.

---

Storage Configuration

Settings → Storage controls where test artifacts (screenshots, videos, Playwright traces, HAR logs) are stored.

Default Storage

By default, ContextQA stores all artifacts in its managed S3-compatible storage. Artifacts are retained according to the policy described in Test Results & Reports.

Custom Storage (BYOS)

Enterprise plans support Bring Your Own Storage — configuring ContextQA to write artifacts to your own S3 bucket, Google Cloud Storage, or Azure Blob Storage. This is useful for:

• Data residency requirements (data must stay in a specific geographic region)

• Extended retention policies (keeping artifacts longer than ContextQA's default)

• Integration with your existing observability and compliance tooling

To configure BYOS, contact the ContextQA enterprise team. Configuration requires providing storage credentials and confirming the bucket's regional location.

---

Backups

Settings → Backups provides tools to export and restore the workspace test library.

What Is Backed Up

Backups capture all test case definitions, test suite structures, test plan configurations, environment definitions, and test data profiles. Backups do not include:

• Execution history (pass/fail results)

• Screenshot, video, or trace artifacts

• User accounts or role assignments

Scheduled Backups

Configure automatic backups at Settings → Backups → Scheduled Backups. Options:

• Daily — backup runs at 2:00 AM UTC each day

• Weekly — backup runs at 2:00 AM UTC every Sunday

Backup files are retained for 30 days.

Manual Backup

At any time, click Export Backup to download the complete workspace test library as a JSON export file. Store this file externally (e.g., in version control or a shared drive) for additional protection.

Restoring from Backup

1. Navigate to Settings → Backups

2. Find the backup you want to restore (scheduled backups) or click Import Backup (for a manual backup file)

3. Choose whether to restore to the current workspace (merges with existing content) or to a new workspace (clean restore)

4. Confirm the restore

Restore operations do not delete existing test cases — they add or update test cases based on the backup content. If a test case with the same ID exists in both the workspace and the backup, the backup version takes precedence.

---

Single Sign-On (SSO)

Enterprise plans support SAML 2.0 SSO integration with identity providers including Okta, Microsoft Azure AD, Google Workspace, and any SAML 2.0 compatible IdP.

To configure SSO:

1. Navigate to Settings → Single Sign-On

2. Select your identity provider

3. Enter the IdP metadata URL or upload the metadata XML file

4. Configure attribute mappings (email, name, role)

5. Test the connection and enable SSO

Once SSO is enabled, users can log in with their organization credentials. Existing ContextQA-specific passwords continue to work for service accounts unless you configure SSO as the mandatory login method.

For SSO setup assistance, contact the ContextQA enterprise support team.

Enterprise-ready: SSO, RBAC, and centralized access management. Book an Enterprise Demo → — Get a walkthrough of enterprise controls, SSO setup, and compliance features for your organization.

**Enterprise-ready: SSO, RBAC, and centralized access management.**