Access control guide

V12 4:24 Ent.svg

 

Robust access control is the key to managing business segments that require different tiers of data security. Productboard can be configured so that certain parts of your workspace are hidden by default and visible or editable only by authorized users.

The best way to do this depends on several factors, including your Productboard pricing plan, your workspace experience type, and the elements you intend to restrict (teamspaces, boards, or products).

Generally, teamspace and board controls are better for preventing users from seeing or interacting with everything in a particular area of your workspace, while product controls are better for restricting access to one specific thing across all areas of your workspace.

In this article:

Relevant to both new and legacy boards

Controlling access to teamspaces

A teamspace is a group of boards. Access to a teamspace (and therefore the boards within that teamspace) is governed by teamspace type. Teamspace type is set during teamspace creation and cannot be changed afterward. When choosing a teamspace type:

  • To allow anyone to join a teamspace, set its type to Open.
  • To allow anyone to ask permission to join a teamspace, set its type to Closed.
  • To make a teamspace invisible to non-members, set its type to Private.

See New board sharing: Teamspace types and member access levels for details. 

Controlling access to boards

How you control access to an individual board depends on which type of board it is. Each features board and Legacy roadmap has its own set of authorized users, while grids, timelines, columns boards, and documents inherit permissions from the settings of their parent teamspaces (as outlined in the previous section).

Open the sections below for board-specific instructions.

Features boards and roadmaps (Legacy board access controls)
Click the Share button in the top right corner of a Legacy board to open the board’s Share menu. From here, you can determine how individuals, teams, or entire roles can interact with the board.

See Legacy board sharing: Individual board options for details.

Grids, timelines, columns boards, and documents (New board access controls)
Access controls for New boards are determined by the settings of their parent teamspaces, which apply to all New boards within that teamspace.

Board visibility is governed by teamspace type. Moving a board into a Closed or Private teamspace will prevent users from being able to see that board unless they're members of that teamspace.

To move a board to a different teamspace:

  1. Open the board. 
  2. Click ••• More actions in the top right corner. 
  3. Select Move to.
  4. Select the destination teamspace.
Note: It is impossible to change an existing teamspace's type. If you need to hide boards but don't have a Closed or Private teamspace, you'll need to create one. 

Board editability is governed by member access level, which is a value set at the teamspace level for each individual member of that teamspace. To adjust a member's access level:

  1. Hover on the teamspace in the main menu.
  2. Click the ••• More actions button that appears to the right of the teamspace name.
  3. Select Teamspace members.

  4. Find the member you wish to adjust and use the dropdown beside their name to indicate whether they Can edit or View only. This setting determines how that individual member can interact with all boards in the teamspace.
Note: The lowest member access level an admin can have is Can edit. Makers can be set to Can edit or View only.

See New board sharing: Teamspace types and member access levels for details.

Certain members of a teamspace may be able to override board access to specific boards for selected members. See Board access overrides for details.

Insights boards (Legacy or New board access controls)
If your workspace was created before July 1, 2024, your insights boards use Legacy board access controls. Otherwise, they use New board access controls.

Controlling access to products

V12 4:24 Ent Plus.svg

 

You may wish to hide certain products from people across all boards and teamspaces (for example, if there’s a secret project that most of the company isn’t supposed to know about).

Controlling access to a product also restricts access to its subordinate items. That means if you render a product invisible, all its components, features, and subfeatures will also be invisible.

The method for controlling product access depends on whether your workspace includes the New Productboard experience. If you’re unsure, click here for instructions on how to check which experience(s) you have access to.

For Legacy experience workspaces
  1. Click Products near the top of the Main menu.
  2. Click on the product you wish to restrict to open its details sidebar.
  3. Click the product access button that appears to the right of the product’s name in the sidebar to open the product’s access control panel. This button changes appearance depending on the product’s current access level.
  4. Click the dropdown beside Everyone at your company to set the default access level for all members of your workspace. Choose Read-only to prevent makers from being able to edit the product, or Restricted to prevent all members from even seeing the product.
  5. Use the search bar to add exceptions to the default access level for specific members and teams. You can adjust individual access levels for each member or team, meaning some may have Full Access while others have Read-only access. If you remove a member or team from the exception list, their access level will immediately revert to that product’s default (from Step 4).

See Legacy product access management for details.

For New experience workspaces
  1. Near the bottom of the Main menu, under Data, click Products to open the Product data page.
  2. In the list, find the product you wish to control access to.
  3. Click the button in the Shared with column to open that product’s access control panel.

  4. Most products are shared with Everyone in your workspace by default. Check the box labeled Set everyone’s access to “view only” to prevent makers from being able to edit the product, or select Specific teamspace(s) to prevent all members from even seeing the product.
  5. If you’ve selected either the View only or Specific teamspace(s) option, a search bar will appear at the bottom of the panel. Use the search bar to add exceptions to the default access level for specific teamspaces. All members of any specified teamspace will be able to interact with the product according to their individual member access level within those teamspaces, but within any other teamspace will be restricted by the default access level set by you in Step 4.

Note: Admins always have the ability to edit products, but regular makers may not be able to edit a product even if they can see it.

See New product access management for details.
For workspaces with both Legacy and New experiences
  1. From Main menu > Data, click Products to open the Product data page.
  2. In the list, find the product you wish to control access to.
  3. Click the buttons in the New access and Legacy access columns to open that product’s access control panel for each experience. See the other sections above for details on how each experience’s access control panels work.

Setting access controls for a specific experience will only affect a product on board types related to that experience. For example, if you change a product’s Legacy access to Restricted, it will only be hidden on features boards and Legacy roadmaps, and anyone who visits a grid will be able to see or edit it.

If you want to ensure a product is completely hidden on all boards, make sure to adjust both access types.

Here’s more information about which boards are part of the Legacy experience and which are part of the New experience.

See New product access management for details. 

Video walkthrough

Relevant to new boards only

 

Use cases & examples

In this section, our own PM Niall Cochrane demonstrates a set of scenarios detailing the more common configurations of teamspace types and product settings you might consider implementing within your own workspace. 

Full transparency

Best for when you value all members of your workspace having access to boards and content.

Example: Marketing team

The Marketing team has their own Jobs-to-be-Done product, and they need to build boards that visualize upcoming releases across the organization. They want everyone to be able to see these boards to foster alignment on marketing and release plans. 

Recommended teamspace type: Open teamspace

Open teamspaces are visible and accessible to everyone in the workspace, and any new board that resides in an Open teamspace is accessible to any member of the workspace without them having to join that teamspace.

Recommended product access level: All teamspaces

If you have full trust in the members of your workspace and value transparency, use the All teamspaces product access level. Products created with this setting are available to all teamspaces to use, and any maker in the workspace can update and edit those products. 

 

Board governance

Best for when you have certain boards that you don't want workspace members to have full visibility into.

Example: Collaboration team

The Collaboration team has a set of product document boards where they plan future product enhancements. These early-stage plans aren't meant to be seen by the rest of the business, as they could create difficult expectations among other team members were they to be circulated prematurely.

Recommended teamspace type: Closed teamspace

Closed teamspaces are visible to everyone in the workspace, but they are not accessible; any board that resides in a Closed teamspace is invisible and un-searchable to any member of the workspace who isn't a member of the teamspace. Members must request access to join a Closed teamspace, or else be added by an admin or teamspace owner. 

Recommended product access level: Case dependent

In this example, no product settings need to be adjusted, as document boards are particularly product-agnostic (they are essentially long-form text files). In your workspace, however, you may wish to lock down access to certain products depending on the boards within this Closed teamspace.

 

Data governance

In this case, "data governance" refers to product data and controlling access to it. Use this approach when you need to restrict edit access to a product, but you aren't concerned with letting people see it.

Example: Permissions team

The Permissions team has their own product, also called Permissions. This team interfaces with many other teams, and those teams need some visibility into the work done by Permissions, but they can't be allowed to make changes to the Permissions product.

Recommended teamspace type: Open teamspace

In this example, the Permissions team doesn't mind allowing other teams to freely look in on the boards they're using to do their work, so they use an Open teamspace. If a maker decides to join, their member access level will be set to View-only by default, so they won't be able to edit the product without someone allowing it in the teamspace member settings.

Recommended product access level: View-only

Setting the Permissions product to View-only allows members of other teams to see what the Permissions team is working on and visualize the product's items on their own boards without letting them change aspects of the product. And by specifying the Permissions teamspace as an exception, members can still edit this product within that teamspace. 

 

Cross-team collaboration

Best for when you have multiple teams that need to work on the same product while retaining their own spaces within Productboard.

Example: Collaboration & Permissions teams

There's a new initiative at the organization and the Collaboration team is being brought in to work with the Permissions team on their Permissions product. A lot of work has already been done, so creating a brand new product for them to share is not feasible. 

Recommended teamspace type: Case dependent

Each team already has their own teamspace, so we don't need to change or create anything here. This will be a product-control solution.

Recommended product access level: View-only

There's no need to change the type of product access either—all we need to do is add the Collaboration teamspace to the list of specific teamspaces that the Permissions product is associated with. This means that the product is View-only in all teamspaces except for the Permissions and Collaboration teamspaces. 

 

Multi-national corporation

Best for when your company manages several subsidiary companies and their products within a single Productboard workspace for reporting or administration purposes.  

Example: Productboard acquires an AI company

Productboard has recently acquired a new subsidiary called AI Mastery to increase velocity in the AI space. (This isn't a lowkey announcement, it's a fictional example.) This company was already using Productboard, and so already has its own product, components, and features. They will be added to our workspace and given their own teamspace, but they'll retain their own employees, roadmaps, and other constructs.

Recommended teamspace type: Closed teamspace

While your own organization may elect to have a subsidiary's teamspace type be Open for transparency or Private for complete confidentiality, in this example we recommend using a Closed teamspace so that everyone's aware of the acquisition without being able to actually view the new team's daily working boards. 

Recommended product access level: Specific teamspace(s)

Considering the nature of this recent acquisition, we don't want other workspace members to be able to look closely at what features the new team will be working on, so by limiting the AI Mastery product to a specific teamspace (AI Mastery's own teamspace), we can keep their work relatively siloed from the rest of the company. 

 

Confidentiality

When discretion is required and special clearance or NDAs are involved, you want to make sure as few people as possible within your workspace even know of a secret project's existence. 

Example: New product line development

The company has decided to break into a new market with a completely new product called Productboard Authorization as a Service (again, a fictional example, not an announcement). This product line is in discovery, so only authorized members will even be made aware of its existence at this early stage. 

Recommended teamspace type: Private teamspace

We don't want anyone finding out about this product line prematurely, so we've created a new teamspace in which to house all information pertaining to it. The only good option here is to make the teamspace Private, as that way it won't even show up for people who aren't already members.

Recommended product access level: Specific teamspace(s)

We've also created a product entity called Permissions AaaS, which should be invisible to everyone except those who have been authorized to work on it. Since the only people with authorization are those who have been added to the Private teamspace we just created, we'll set that as the only assigned teamspace for this product. 

 

See also

Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.

Articles in this section

See more
Our Support hours:
Monday to Friday from 9:00 am - 2:00 am CET. Monday to Friday from 0:00 am - 5:00 pm PST.
Productboard Academy
Become a Productboard expert with self-paced courses, quick tip videos, webinars and more.
Product Makers Community
Connect with product leaders, share and find product jobs, and learn how to approach similar challenges. Come join our Product Makers community.