> 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 {% 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. **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 **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](/administration/roles-and-permissions.md) 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**. ### Password requirements When you create a user with a password, the password must meet all of the following requirements: * Be 8 to 128 characters long * Contain at least one uppercase letter (A–Z) * Contain at least one lowercase letter (a–z) * Contain at least one number (0–9) * Contain at least one special character (any non-alphanumeric character, such as `!`, `@`, or `#`) The password and the confirmation password must match. The form shows an inline message listing any unmet requirements until the password is valid, for example: *Must be at least 8 characters with an uppercase letter, a lowercase letter, a number, and a special character.* These requirements apply only when you set a password. Editing an existing user's role or display name does not prompt for a password and does not change it. {% hint style="info" %} Password requirements apply to ContextQA-managed accounts. If your workspace uses single sign-on, your identity provider manages passwords and these rules do not apply. See [SSO and authentication](/administration/sso-and-authentication.md). {% endhint %} ### 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](/reporting/test-results.md#result-retention-policy). ### 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. {% 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 %} {% hint style="info" %} **Enterprise-ready: SSO, RBAC, and centralized access management.** {% 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=&goal= ``` `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.