Skip to main content
  1. Learn
  2. Project management
  3. How-tos
  4. Backlog’s user access basics every administrator should know

Backlog’s user access basics every administrator should know

How-tosProject managementBacklog
Backlog Staff

Backlog Staff

August 18, 2020

When using Backlog for your projects, you may wish to add members from other departments or external partners (e.g. vendors, freelancers, clients) to your project. To help you manage your projects securely, we’ll use this article to introduce some user access basics:

Three basics of user privileges that administrators should know:

  1. ‘Member/Guest’ versus ‘Administrator’
  2. Appointing a member as ‘Project Administrator’
  3. Further user restrictions: “Add issue only” or “View only”

Three patterns to apply information/project access:

  1. Internal / external projects
  2. Project for all users
  3. Access control and IP address restrictions

‘Member/Guest’ versus ‘Administrator’

Let’s begin with the differences between Member, Guest, and Administrator roles.

Invite member as admin, member or guest
When you invite a new user to your organization, you can invite them as Administrator, Member, or Guest.
  • Member: Project members have access to the information in their participating projects and they can collaborate using the available features under their Backlog plan, e.g. Issues, Boards, Files, Git, Wiki, Gantt Chart, etc.* If a user is not a member of a project, they will not be able to access that project.
  • Administrator: Besides having member privileges, Administrators can manage the Space and add users via the Space/Organization settings. Administrators can also create/archive projects, and manage members in projects.
  • Guest: Guests can operate and use Backlog features (Issue, Wiki, Files, Repositories, etc) just like members, unless restrictions are put on their account by the Administrator.* However, the main difference is guests are prevented from viewing the organization’s member list. They cannot view other teams in the organization, nor members of those teams, but they can view the team they are in (if any), and its members.

*Administrators can further restrict members’ and guests’ actions to “add issue only” or “view only” within the Space; this will be introduced below.

By understanding that members can only access and collaborate within their participating projects, we can plan how to set up a project and its members so that information is secure and visible only to relevant users.

Use Case: A company with multiple departments

For a company with multiple departments, e.g. IT, HR, Sales, etc, each department can create their own separate projects. This way, only department members can view and collaborate in their projects, and information access is controlled.

Additionally, staff can focus on their relevant tasks and issues without being distracted by another department’s work.

Separate projects for different departments

What you want to achieve:                                To control or limit information access to relevant users only, and minimize any potential information leaks. 
What you can do:  Create projects for different departments, teams, or work projects, and add members to give them access. If you have an external partner like a freelancer or your client and you wish to keep your list of organization members private, you can add them as guests. They will still be able to use normal Backlog functions like Issues, Wiki, and Git.
Useful links for more details: Manage organization users and teamsManage project members and teams

Backlog user roles and restrictions

Appoint member as ‘Project Administrator’

A Project Administrator is a user with the added privilege to administer or manage a project.

With more users and projects being managed in Backlog, it can become difficult for the administrator to manage who is involved in which projects. In situations like this, the administrator can delegate a member to manage the project by assigning them as a Project Administrator. 

As a side note, guests cannot be assigned as Project Administrators.

Project settings that can be accessed by members:

Project settings that can be accessed by members
For project settings, ordinary members can only access the project’s Issue Types, Categories, and Versions/Milestones.

Project settings that can be accessed by project administrators:

Project settings that can be accessed by project administrators
Project Administrators can access more project settings, as well as manage project members.

Use Case: Delegating project responsibilities to other members

For department or project managers, you can add them as a member and assign the Project Administrator title and privileges, so under their own initiative, they can manage their respective projects and project members.

Marketing project administrator cannot access another's project settings

What you want to achieve:                                To delegate project management responsibilities to other users — e.g. project or department managers — within their respective projects.
What you can do:  First, create a project or use an existing project. Then, assign a member as the project administrator, so they can add/manage project members and adjust the project settings accordingly to fit the project’s needs.

Note: Project administrators can only add existing users to projects. To add new users to the Space/Organization, the project administrator needs to have inviting privileges. This can be granted to project administrators and members under Organization Settings.

Useful links for more details: Manage project members and teamsGrant a member inviting privileges

Further user restrictions; “Add issue only” or “View only”

To further restrict the actions a user can perform in the Backlog Space, you can set restrictions such as “Add issue only” or “View only”.

Further restrict user permissions
These further user restrictions can be applied to both members and guests of the Space.

Add issue only: Users can add issues and view/post comments, but they cannot edit issues. They can view Board, Wiki, and Gantt Chart.

View only: Users can view issues and comments, but they cannot post, edit, or comment on issues. They can view Board, Wiki, and Gantt Chart.

Table of permissions for “Add issue only” and “View only”:

Table of permissions for "Add issue only" and "View only"

Use Case: External users

For example, you might be working with a client or vendor on a project, and you wish to prevent them from accidentally changing or editing the issues in Backlog, you can set up these user restrictions.

Diagram of restricting permissions for members and guests

What you want to achieve:                                To restrict a member’s or guest’s actions in the Space and projects so they can’t accidentally change or edit an issue.
What you can do:  After inviting the user as a member or guest to the Space, you can further restrict their actions to “Add issue only” or “View only”.
Useful links for more details: Further Restrict User Permissions

Three Patterns for information and project access

Pattern 1: Internal / External projects

If you are planning to use Backlog with many members or external partners, consider dividing the projects into “internal/external” projects.

As introduced above, projects can be separated based on departments (like marketing, support, development, etc). This is effective for controlling user access to information and can also be applied to joint projects with members of other departments or customers.

For example, we can consolidate interactions with external partners in an external project, while internal coordination and research are carried out in an internal project that’s only accessible by relevant team members. This way there are no worries about confidential information leaking outside of the team. Since information is kept organized in both internal and external projects, we can still track our issues and tasks smoothly.

Diagram of external partners not added to internal projects

Scenario: Working on a project with external partners or customers.
Usage pattern / recommendation:  Consider splitting the project into internal and external projects so that confidential work or research information is accessible only by team members or internal members. In the external project shared with customers, you can also consider adding further restrictions on specific users, such as the “Add issue only” or “View only” restrictions introduced above.

Pattern 2: Project for All Users

Although it’s important to limit user access on a per-project basis, there are also situations where we want to communicate work information and issues to all users in the Space. In this case, it’s best to create an all-users project.

By having a project in which everyone can participate, you can inform everyone about important updates, discuss work in issues, share Wikis, files, etc — to ensure that information is communicated smoothly within the organization.

Diagram of project accessible for all users

Scenario: To have a common place for sharing information to all users and all users can communicate and share information smoothly.
Usage pattern / recommendation:  Create a project and add all users in the Space as members so everyone has access.

Pattern 3: Access control and IP address restrictions

Finally, we’ll introduce the IP address restrictions feature that you can use to restrict user IP addresses that can access Backlog.

For example, an organization may want its users to access projects from the office network and prevent access from home or other unsecured networks. In such cases, the Backlog Space can be set to only allow access to a list of permitted IP addresses.

access control and ip address restriction settings

The Access Control feature is available in Standard plans or higher. We recommend it as a way to prevent unauthorized access by third parties in advance.

In addition, 2FA login is available for all users (including free plans) and administrators can also enforce two-factor authentication (2FA) for all users (available for Premium plans and above). This requires all users to enter a 2FA code in order to log in.

Diagram of access allowed for permitted IP address

Scenario: Limiting Backlog user access to permitted connection sources or networks, i.e. IP addresses.
Usage pattern / recommendation:  Use the Access Control setting, which can be found under Space settings; enter the permitted IP addresses into the allowlist.


We’ve come to the end of this article on managing your projects securely. As a quick review, we covered the three basics of user privileges and the three patterns for applying information/project access

Be sure to keep this article in mind as you set up your projects and members, so together you can enjoy more collaboration and productivity in Backlog!


Subscribe to our newsletter

Learn with Nulab to bring your best ideas to life