> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/administration/team-management.md).

# Team Management

## Quick answer

Manage workspaces, invite team members, and configure workspace settings in ContextQA for organized test automation across teams. Use this page to understand when the capability applies, complete its user-facing workflow, and verify the expected result.

## What this page covers

{% hint style="info" %}
**Who is this for?** Engineering Managers, IT Administrators, and VPs of Engineering configuring team access, authentication, and enterprise security controls.
{% endhint %}

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:

**General 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 |

**Test Execution Settings**

| Setting                      | Default | Description                                                                                                                                                                                                                  |
| ---------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Test case timeout            | 30      | Maximum execution time, in minutes, allowed for a single test case before it times out. Accepts a value from 1 minute up to your organization's maximum. The maximum is configured by ContextQA and defaults to 160 minutes. |
| Retry failed steps           | 0       | Number of times to automatically retry a failed step before marking it as failed. Set to 0 to disable retries.                                                                                                               |
| Capture all step screenshots | Off     | When enabled, captures a screenshot after every step — not only on failure. Useful for visual regression review but increases storage usage.                                                                                 |
| Video recording              | Off     | When enabled, records a video of the browser session during test execution. See [Video & Screenshots](/execution/video-and-screenshots.md).                                                                                  |

The Organization Settings page groups these settings into tabs at the top — **Company Information**, **Test Execution**, **AI Configuration**, **Notifications**, and **Viewport**. Click **Save Settings** to apply your changes.

### Company logo

Upload a company logo to brand your workspace. Once saved, the logo appears at the top of the sidebar in place of the default ContextQA mark. The logo lives on the **Company Information** tab of the Organization Settings page.

**Supported formats and size**

* PNG or JPEG only. GIF is not supported.
* Maximum file size: 2 MB.
* A PNG with a transparent background is recommended, and a light or white version reads best against the sidebar.

**Uploading a logo**

1. Navigate to **Settings → Organization Settings** and open the **Company Information** tab.
2. In the logo upload box, either click **Click to upload or drag and drop** to pick a file, or drag an image file onto the box.
3. Wait for the upload to finish. The logo appears as a preview card showing a thumbnail, the file name, and its dimensions and size.
4. Click **Save Settings** to save the logo.

The preview is live: as soon as the upload completes, the sidebar shows your logo — you do not need to save to see it. The change is only persisted when you click **Save Settings**. If you leave the page without saving, the sidebar reverts to its previous logo.

{% hint style="info" %}
When the sidebar is collapsed, branding is hidden and the logo does not appear.
{% endhint %}

**Replacing or removing a logo**

* To replace the logo, click **Replace** on the preview card and select a new image.
* To remove the logo, click **Remove** on the preview card. Click **Save Settings** to apply the removal — the sidebar then returns to the default ContextQA mark.

**Default Viewport**

The **Viewport** setting under **Test Execution** sets the default browser viewport for new test plans. Select a mode — **Desktop**, **Laptop**, **Tablet**, **Mobile**, or **Custom** — then choose a **Resolution** (or, for **Custom**, enter a width and height and click **Add**). If you don't select a desktop resolution, runs use the default of 1280×720.

### Viewport configurations

The **Viewport Configurations** section — reachable from the **Viewport** tab on the Organization Settings page — lists the reusable viewports your organization has saved. Viewports are grouped by category: **Mobile**, **Tablet**, **Laptop**, and **Desktop**. Each viewport appears as a chip showing its label and dimensions, for example `My Custom Desktop (1920×1080)`. If no viewports exist yet, the section shows "No viewport configurations found."

To remove a viewport, click the **×** on its chip.

**Adding a viewport**

1. Click **Add Viewport** to open the **Add Viewport** dialog.
2. Enter a **Label** — a descriptive name such as `My Custom Desktop`.
3. Enter the **Width (px)** and **Height (px)**, for example `1920` and `1080`.
4. Review the **Category** chip. ContextQA assigns the category automatically from the width:

   | Category | Width range  |
   | -------- | ------------ |
   | Mobile   | 320–480 px   |
   | Tablet   | 481–1024 px  |
   | Laptop   | 1025–1600 px |
   | Desktop  | 1601–3840 px |

   When the width is greater than the height, the chip also appends **(Landscape)**.
5. Click **Add Viewport** to save.

{% hint style="info" %}
Width is the primary classifier for the category. Boundary widths (480, 1024, and 1600) fall into the lower category — for example, a width of 1024 is classified as **Tablet**, not **Laptop**.
{% endhint %}

The dialog validates your entries as you type:

* **Width below 320px** is rejected with "Below minimum supported width (320px)" — you can't save until you raise it.
* **Width above 3840px** is allowed but flagged with "Exceeds standard display range (max 3840px)", and the category chip shows **Custom / Unknown**.
* A **height that's unusual for the derived category** shows the warning "Unusual height for this category — double check". This is a reminder only; you can still save.

Saved viewports become available wherever ContextQA offers viewport or resolution choices, such as the default viewport selector in the viewport panel and cross-browser test machine configuration. See [Cross-Browser Testing](/execution/cross-browser-testing.md).

***

## Organizations and sessions

A single ContextQA account can belong to more than one organization. Each organization is a separate tenant with its own subdomain (for example, `acme.contextqa.com` and `globex.contextqa.com`), its own workspaces, and its own data. You sign in to each organization independently, and your session in one organization is separate from your sessions in the others.

### Switching organizations

Use the **organization switcher** to move between the organizations your account belongs to.

1. Click your **profile avatar** at the bottom of the sidebar. (You can also open the profile menu and select **Switch Organization**.)
2. The **Switch Organization** popover opens, showing your name and email at the top and the list of organizations your account belongs to.
3. The organization you are currently in shows an **Active** badge.
4. Click the organization you want to switch to.

ContextQA switches you to the selected organization and opens it on its own subdomain. You land back on the page you were viewing before the switch.

{% hint style="info" %}
If you belong to only one organization, the switcher lists that single organization. Another organization can add you through that organization's [user management](#inviting-users), not from the switcher.
{% endhint %}

### Signing out

You have two ways to end a session:

* **Sign out of the current organization** — Open the profile menu and select **Logout**. This ends your session in the organization you are currently in. Your sessions in other organizations stay active.
* **Sign out of all organizations** — In the **Switch Organization** popover, click **Sign out of all organizations**.

When you choose **Sign out of all organizations**, a confirmation dialog opens:

1. The **Sign out of all organizations?** dialog lists every organization your account belongs to, with the current organization marked **Active**.
2. Review the list, then click **Sign out of all** to confirm, or **Cancel** to keep your sessions.

Confirming ends your active sessions in all organizations at once. You must sign in again to access any of them.

{% hint style="warning" %}
**Sign out of all organizations** ends every session, including the one you are currently using. Use it on shared or public computers to make sure no organization stays signed in.
{% endhint %}

***

## Managing Users

### Viewing All Users

Navigate to **Settings → User Management** to see the organization user table. The current table shows **Name**, **Email**, **Roles**, **Verified**, and **Admin**, plus row actions. Use the search box to find a specific user.

### Inviting Users

1. Navigate to **Settings → User Management**
2. Click **+ Invite User**
3. Enter the user's **Name** and **Email**
4. Optionally enter a **Phone Number**
5. Select one or more **Roles** (see [Roles & Permissions](/administration/roles-and-permissions.md))
6. Click **Save**

![ContextQA User Management invite dialog showing name, email, optional phone number, and role assignment without exposing real user data](/files/b3COQNFWJxPvMoUiUh0Q)

If the role selector shows **No roles available**, create the required role on the **Roles & Permissions** tab before completing the invitation. Assign the least-privilege role that allows the person to do their job.

### Authentication and password ownership

The current invite dialog does not ask the administrator to create a password. This separation prevents passwords from being copied into onboarding messages or shared by an administrator.

* ContextQA-managed login behavior is controlled under **Settings → Authentication Configuration**.
* With Google SSO, password policy and account recovery are owned by the configured identity provider.
* Automation credentials belong in an approved secret manager, never in a user invitation or documentation screenshot.

{% hint style="info" %}
See [Authentication and SSO](/administration/sso-and-authentication.md) before changing a login method or handling the API credentials shown on the Authentication Configuration page.
{% endhint %}

### Maintaining user access

Use the row actions next to a user to review the operations available in your deployment. Before changing or removing access:

1. Confirm the request and the target user's email address.
2. Record the user's existing role and any owned automation or scheduled tests.
3. Reassign business-critical ownership where required.
4. Apply the least disruptive access change exposed by the current user action menu.
5. Verify the result in the **Verified**, **Admin**, and **Roles** columns.
6. Review the corresponding entry under **Settings → System Audits**.

Available actions and their labels can vary by deployment. Do not assume that removing a user transfers their resources or preserves scheduled execution; validate ownership before making the change.

***

## System Audit Log

Admins can review recorded platform activity at **Settings → System Audits**.

![ContextQA System Audits page showing Date, Module and ID, and Details columns with refresh and filter controls](/files/0uYIQkx5BNEYKX4qV2rm)

### Audit Entry Fields

The current table exposes these fields:

* **Date:** When ContextQA recorded the event
* **Module & ID:** The affected application area and associated identifier
* **Details:** The event description available for review

### Using the Audit Log

**For access reviews:** Correlate user and role changes with an approved onboarding or offboarding request.

**For change review:** Use the refresh and filter controls to locate the relevant module, ID, or date when the deployment provides that filter.

**For troubleshooting:** Use the module and resource ID to connect an audit event to the affected test, integration, or configuration object.

The observed page does not expose actor IP addresses or a CSV export control. If those are compliance requirements, confirm deployment-specific availability and retention with the ContextQA account team instead of assuming they are enabled.

***

## 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** exposes provider cards for **AWS S3** and **Azure Cloud** in the observed workspace. Use **View Details** to review a provider, and keep access keys or connection strings out of tickets, screenshots, and source control.

See [System Configuration](/administration/system-configuration.md#storage-configuration) for the current screenshot and a safe configuration checklist.

***

## Imports and Exports

The `/settings/backups` route is currently labeled **Imports and Exports**. It provides an **Import** action and lists available packages when they exist. In an empty workspace it displays **There are no Backups created**.

The observed page does not expose a scheduled daily/weekly backup configuration, retention period, or restore conflict policy. Treat an import as a controlled change: confirm the package source and target organization, record the pre-import state, and validate a small sample after processing. See [System Configuration](/administration/system-configuration.md#imports-and-exports) for the current screen.

***

## Single Sign-On (SSO)

The observed **Settings → Authentication Configuration** page exposes **No Auth**, **User Name and Password**, and **Google SSO**. Identity-provider availability can vary by deployment or subscription.

Use [Authentication and SSO](/administration/sso-and-authentication.md) for a screenshot-backed walkthrough, safe rollout sequence, and API credential handling. Confirm any required SAML or automated provisioning capability with the ContextQA account team when it is not displayed in the target deployment.

{% hint style="info" %}
**Enterprise-ready: SSO, RBAC, and centralized access management.** [**Book an Enterprise Demo →**](https://contextqa.com/book-a-demo/) — Get a walkthrough of enterprise controls, SSO setup, and compliance features for your organization.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://learning.contextqa.com/administration/team-management.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
