TestHub project name dependency for Automate

Understand how TestHub project name uniqueness affects your BrowserStack Automate projects, including error behavior and migration guidelines.

TestHub groups BrowserStack Automate runs by project name. This page explains how that works when project name uniqueness is enforced for your account and what to do if your organization currently uses duplicate project names.

In this guide, you learn how to:

• Understand TestHub project name uniqueness and when it is enabled
• See how Automate behaves when you pass project names
• Interpret errors related to project name conflicts
• Plan migration if your organization uses duplicate project names

Overview of project name uniqueness

TestHub uses the project name to group and report your Automate runs. To avoid conflicting or ambiguous results inside a group, BrowserStack can enable group-level project name uniqueness for your account.

When group-level project name uniqueness is enabled:

• A project name can belong to only one team within a group.
• Other teams in the same group must use a different project name.
• Test runs that use a conflicting project name are blocked with an error instead of silently creating or reusing a project.

Currently, using Automate does not change how you set the project name in code or configuration. The change is in how TestHub validates and accepts those names for certain groups.

Behavior for Automate

When BrowserStack enables group-level project name uniqueness for your group, Automate enforces the following rules at run time:

• If you pass a project name that another team owns in your group:
  • The test session does not start.
  • No new project is created.
  • An error appears in your console, terminal, or CI/CD logs that indicates the project name is already in use.
• If you pass a project name that is not owned by another team in your group (that is, a unique project name for your group):
  • The test session runs normally.
  • A new project is created for the project name you passed (if it does not already exist for your team).

Groups without existing duplicate project names

If your organization does not currently have duplicate project names within a group, BrowserStack can safely enable group-level project name uniqueness for you.

When uniqueness is enabled for such groups:

• Using a project name that another team in your group owns can cause your Automate session to fail with an error, preventing the creation of a new project.
• Using a project name that is not already owned by another team allows the session to run and, if needed, creates a new project for your team.

No additional configuration is required from your side beyond ensuring that each team uses a distinct project name within the group.

Groups with existing duplicate project names

If your organization already uses the same project name across multiple teams or projects within a group, BrowserStack treats this as a non-compliant configuration that you must correct.

For such groups:

• BrowserStack enforces group-level project name uniqueness as part of its enterprise readiness standards.
• Your BrowserStack account team works with you to define a concrete migration plan and timeline.
• You must rename or consolidate impacted projects so that each project name is unique within the group.

Typical migration steps include:

• Identifying all projects that share the same name across teams.
• Choosing a unique project name per team or per logical project.
• Updating your Automate configuration (capabilities, environment variables, or framework config) to use the new names.
• Running a small set of builds to validate that results appear under the correct projects in TestHub and that your CI pipelines remain healthy.

During the agreed migration window, BrowserStack may temporarily maintain existing behavior to avoid blocking critical builds. After that window, TestHub strictly enforces project name uniqueness and runs that use conflicting project names can fail or be rejected.

What you need to do

Use the following checklist to prepare for or respond to TestHub project name dependency changes:

1. Review current project names in TestHub. List all Automate projects and note any names that are reused across teams in the same group.
2. Decide on a naming convention. For example, use a pattern such as <application>-<team>-<environment> so that names stay unique.
3. Update Automate tests. For each test suite or CI job, set the project name according to your convention and avoid using a project name that is already owned by another team.
4. Align App Automate tests. Even where stricter validation is not yet enforced, update AA tests to follow the same naming convention so that web and mobile results align.
5. Monitor for errors. After changes roll out, watch your console or CI/CD logs for errors related to project name conflicts, and adjust names if needed.
6. Coordinate with BrowserStack. If you have complex or large-scale duplicates, work with your BrowserStack account team to agree on a safe migration window.

Following these steps helps you avoid blocked sessions, keeps your projects uniquely identifiable within TestHub, and prepares your Automate setups for stricter project name dependency rules.