Skip to end of metadata
Go to start of metadata

On this page:

Creating New User

The Administration | Users page provides the Create user account option.

When creating a user account when several authentication modes enabled on the server, only a username is required.

If only the default authentication is used, the password is required as well. Any new user is automatically added to the All Users group and inherits the roles and permissions defined for this group.
If you do not use per-project permissions, you can specify here whether a user should have administrative permissions or not. Otherwise, you can assign roles to this user later.

Editing User Account

To edit/delete a user account, click its name on the Users tab of the Administration | Users page and use the corresponding option. The page provides several tabs allowing you to modify various user account settings


The General tabs allows modifying the user's name, email address and password if you have appropriate permissions. Users can change their own username only if free registration is allowed. The administrator can always change the username of any user.

Authentication Settings

The Authentication Settings section appears if several authentication modules are enabled on the server. Here you can edit usernames for different authentication modules such as LDAP and Windows Domain.

VCS Usernames

This tab allows viewing and editing default usernames for different VCSs used by the current user.
Multiple usernames are supported for a VCS root type and for a separate VCS root: several newline-separated values can be used for each VCS username.

The names set here will be used to:

  • show builds with changes committed by a user with such a VCS username on the Changes page
  • highlight such builds on the Projects page if the appropriate option is selected,
  • notify the user on such builds when the Builds affected by my changes option is selected in notifications settings.


Use this tab to review the groups the user belongs to, and add/remove the user from groups.


This tab is available only if per-project permissions are enabled on the server Administration / Authentication page. Use this tab to view the roles assigned to the user directly and those inherited from groups. The roles assigned directly can be modified/removed here. See also Assigning Roles to Users below.

Assigning Roles to Users


To be able to grant roles to users on per-project basis, enable per-project permissions on the Administration | Authentication page.
The Administration | Roles page lists all existing roles detailing their permissions.

There are several ways to assign roles to one or several users:

  • To assign a role to a specific user, on the Users tab for the user click View roles in the corresponding column. In the Roles tab, click Assign role.
  • To assign a role to multiple users, on the Users tab, check the boxes next to the usernames and use the Assign roles button at the bottom of the page.
  • To assign a role to all users in a group, on the Groups tab click View roles for the group in question, then assign a role on the group level.
    When assigning a role, you can:
  • Select whether a role should be granted globally, or in particualr projects.
  • Replace existing roles with the newly selected. This will remove all roles assigned to user(s)/group and replace them with the selected one instead.

Notification Rules

This tab displays notification rules for the user.

Own rules

The rules configured by the user are displayed here and can be modified.

Inherited rules

This section displays the rules inherited by the user from the groups they belong to.

Managing User Groups

Creating New Group

Open the Administration | Groups page and сlick Create new group. In the dialog, specify the group name. TeamCity will create an editable Group Key, which is a unique group identifier.

When creating a group, you can select the parent group(s) for it. All roles and notification rules configured for the parent group will be automatically assigned to the current group. To place the current group to the top level, deselect all groups in the list.

Editing Group Settings

To edit a group, click its name on the Groups tab. You can modify the group name and description as well as parent group(s), and change the list of users, roles and permissions, and notification settings for the group.


The All Users group includes all users and cannot be deleted. However, you can modify its roles and notification settings.

The Roles tab allows you to view and edit (assign/unassign) default roles for the current group. These roles will be automatically assigned to all users in the group.
Default roles for a user group are divided in two groups:

  • roles inherited from a parent group. Inherited roles can not be unassigned from the group.
  • roles assigned explicitly to the group

To assign a role for the current group explicitly, click the Assign role link.
To view permissions granted to a role, click the View roles permissions link.
You can also specify notification rules to be applied to all users in the current group. To learn more about notification rules, please refer to Subscribing to Notifications.

Adding Multiple Users to Group

On the Users page, select users, click the Add to groups button at the bottom, and specify the groups  to add the users to. Note that all these users will inherit the roles defined for the group.

See also:

  • No labels


  1. Is there anywhere a complete list of permissions and precisely what they grant access to? Can someone add a link to it from here and anywhere else that talks about permissions?

    For instance, 'Administer build agent machines (e.g. reboot, view agent logs, etc.)' doesn't tell me what 'etc' includes.

    I need to allow develpers to reboot agents before a particular build, to help ensure that phones physically connected to that agent are accessible (Apple's USB stack drops Android devices unpredictably), so I need developers to be able to activate curl "http://MyTeamCityServerURL/remoteAccess/reboot.html?agent=${AGENT_ID}&rebootAfterBuild=true" in a dependency task, but I don't want them creating new agents and whatever else.

    1. Tim, the TeamCity Web UI lists all available permissions grouped by roles on the Administration | Roles page (in the User Management section). You can modify the existing roles and create new ones using this page.

      However, the description of the  'Administer build agent machines' permission may indeed be not the most fortunate. To clarify, this permission allows users to:

      • Clean sources on this agent
      • Reboot Agent Machine
      • Dump threads on agent
      • View agent logs.

      As for creating new agents, you need the System Administrator role to install and authorize new agents. 

      1. Thanks for getting back to me. On review, it was only the 'Administer build agent machines' permission that was unclear - I made the incorrect assumption that others in the list might be similarly unclear.

        It's odd that granting that permission to (for example) the guest user doesn't also allow the guest user to navigate from the Agents page to the page of each individual agent, in order to perform a reboot. I'll add that to my ticket about the reboot link not working for such a user with that permission.

  2. How can i change the Group Permissions to allow a user the access to the Notification Rules?
    Currently i have a Group with a Subgroub for the Admins

     > MyAdmins

    Now all Admins should have the rule to change the Notifications in "MyGroup".

    (Currently the Admins can change the settings of MyAdmins group but not from the MyGroup, but i dont know how to fix this)


    Is the "Notificatin admin role" the way to go? But i cannot assign a Project there

    N/ANotification admin role