Skip to main content

Enabling the Bitrise Support Access for your project

Abstract

You can enable the Bitrise Support Access from the Project settings page. This way, our support team can have access to your project, specifically your Workflow, build log, project settings, and your bitrise.yml.

In this article we describe how you can enable the Bitrise Support Access so that our Support team can have access to your project, specifically your Workflow, build log, project settings or your bitrise.yml file. With the toggle function, you can easily turn the Bitrise Support Access on and off. No need to add us as a user to your project's Team.

The Bitrise Support user, when enabled, has Admin access to your project. That means it can do anything that a regular user with Admin access rights on a project can do: it has access to your builds and Workflows, to all the settings in the Workflow Editor and to the Project settings page.

No access to billing information

The Bitrise Support user can’t see your Account information or any Billing information. Only the owner of the account has access to this information and has the right to modify any account-related records.

The Support user can’t see your other projects where the Support user is not enabled. For details, see What the Bitrise Support user can/can't do?

How long does the Bitrise Support Access remain active?

Due to security reasons once you toggle the Bitrise Support Access on, it will remain active for two weeks after which it automatically gets revoked.

Let’s see how to set it up!

  1. Open your project on Bitrise with a user that has the Admin role on the project.

  2. On the main page of the project, click on the Project settings button.

    project-settings-button.png
  3. On the left, select General from the menu options.

  4. Scroll down to the Support Access and toggle the switch to the right to enable it. It might take a couple of seconds to work and you might need to refresh your page to see the enabled status.

    support_access.png

In case of a failing Workflow, our best practice is to create a new and correct version of the failing Workflow called support-testing. You can compare our support-testing with your own and update yours or keep the support-testing Workflow, rename it as you wish, and develop it further.