TestHub project name dependency for App Automate

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

TestHub groups BrowserStack App 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 App 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 App 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 App 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 App Automate

From the App Automate side, there are no explicit code changes to how project names are handled. The project name continues to be passed from your App Automate tests in the same way as before.

At this stage:

• The runtime validation described in the previous section is owned by Automate engineering.
• In some cases, the stricter uniqueness validation might not yet apply to App Automate runs, even when it is enabled for related Automate projects.

As a result of this, you may notice stricter enforcement for Automate and more permissive behavior for App Automate in the short term. BrowserStack will gradually align behavior, but you should already follow the same naming guidance for both to avoid future conflicts.

If you are unsure whether project name uniqueness is enabled for your App Automate projects, contact BrowserStack Support or your account 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 App 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 App 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 App Automate setups for stricter project name dependency rules.