How Teams and permissions work in Simana

Your ability to do things in Simana is controlled by the combination of Permissions settings and Team membership. This article explains how those elements work and lays out the most common setups used by customers.

Teams

A Team is a set of members associated with an organisation, Space, Board or Card. Adding someone to a Team lets you give them permissions for that area of Simana.

Someone may also have access without being directly added to that Team. For example, a Board's permission settings can allow all organisation members to view it, while allowing its own Team members to edit it.

See Invite people to your organisation to add colleagues to your organisation's Team.

Permission levels

Permissions determine what a user can do with content: view it, comment on it, edit it or administer its Team and permissions.

• View - gives users the ability to view and open content, but not change it.
• Comment - users can post comments in the Threads panel.
• Edit - users can create and modify content; generally change any content that isn't related to the Team or permissions.
• Admin - gives control over the Team and permissions, including adding and removing users and changing their permissions.

The permission levels build on one another: Comment includes View, Edit includes Comment and View, and Admin includes all three.

How permissions apply

Default member permissions

Default member permissions initialise a member's permissions when they join a Team. Once they have joined, you can change their permissions on their individual member record. The defaults are a starting point, rather than a shared permission setting that continually controls existing members.

See Configure default Team permissions to set the defaults, or Change a member's permissions to update an individual member.

Permission boundaries

Where an area does not have its own permissions enabled, access is determined by the nearest permission boundary above it. Enabling permissions creates a new boundary, where access is determined using that Team's member permissions and its settings for other audiences, such as organisation members.

For example, a Board can allow organisation members to view it while allowing members of its own Team to edit it.

Inherited memberships

Inherit to child teams carries a member's membership and permission set into child teams, including across a Board's permission boundary. A member can therefore receive access through an inherited organisation membership as well as through their individual record on the Board's Team.

Consider a Board where Organisation members can View:

Important: To reduce someone's access, check every membership that provides it. Setting their individual Board permissions to View does not remove Edit supplied by an inherited membership.

Organisation level permissions

When a user is added to the organisation team they are granted some combination of the permissions outlined above. In most cases their permissions are initialised from the organisation's default member settings. You can then change their permissions on their individual member record, for example if they need to be an Admin user.

The standard permission set on an organisation team is Edit (which also includes View and Comment). This typically allows a user to access Spaces that use the organisation's permission settings and create content in those Spaces. For example you can view the Ideas and Projects spaces and create an idea board and project board within them.

Organisation permissions apply within the organisation until another permission boundary is reached. Inherited memberships can still provide access beyond that boundary, as shown in the example above.

Space level permissions

By default Spaces do not have Team or Permissions enabled. This means the organisation-level team and permissions apply to the space.

For example:

• If you have view permissions on the organisation team, you will be able to view the space.
• If you have edit permissions on the organisation team, you will be able to create new content in the space.

See Create and configure Spaces to manage your organisation's Spaces and their features.

Board level permissions

Boards tend to be things like Project, Ideas, Audits or Dashboards. The default setting is that these will have Team and Permissions enabled.

Enabling permissions at this level allows you to control who can view and edit the content (e.g. project). The Organisation members settings determine what access people receive because they belong to your organisation. The Default members settings initialise permissions for people added to the Board's own Team; those permissions can then be changed on each member's record.

For example:

• If the Organisation member permission level is set to View, all users in your organisation will be able to open and view your board. This is the default setting most commonly applied.
• If the Default members permission level is set to Edit (which includes View and Comment), users added to the board team initially receive permission to edit the board and add to its contents. Their individual permissions can subsequently be changed.

When reviewing Board access, consider inherited memberships too; see the worked example under How permissions apply.

Card level permissions

Team and permissions can be applied to individual cards in the same way they are to boards.

In many cases cards are located on boards and so teams do not need to implement card-level controls as the board-level controls suffice. But if/when required they can be used.

Related guides

• Create and manage Team roles
• Assign a role to a member