# Roles & Permissions (Team app)
## Introduction
There are two main ways of assigning access and usage rights to platform users; the **Team App** and the **Rights Designer**.
The Team App allows you to define user groups, for example for projects or departments, while the Rights Designer allows to granularly specify the access rights of single users on specific data fields on a per-application basis.
This documentation will go through setting up application roles for the Team App and setting rights and permission using the Rights Designer.
## The Team App
As introduced, the Team App allows TIVITY platform administrators to define groups for members of projects or organizational departments. Each group can be given access to a specific set of projects and data.
This allows members of each group to have access only to the projects relevant to them, and prevent others from accessing data they should not.
## Users
In the Users section, all active users are listed alphabetically along with the groups they belong to. To see the details of a user or edit it, you can click on it.
The Users Section in the Teams App
A user's detail view contains relevant information about such as his contact information and group memberships.
### Inviting a new user
To invite a new user to the team, click on the green **Invite User** button on top of the Teams App.
On the next window you can enter the emails of the users you want to invite to the team and assign them to groups in advance.
### Viewing & modifying invitations
To view all pending invitations, click on **Invitations** in the Teams App.
If you want to delete **Resend** or **Delete** an invitation, click on the invitation to access the invitations's details. Next open the Actions menu by clicking on the 3 dots the top to access those functionalities.
## Groups
The Groups section gives an overview of all created organisational groups within your TIVITY Workspace. It allows you to get a quick overview of which administrator own each group and is responsible for it.
Groups section in the Team app
### Creating a new group
To create a new group, click on **Add new group** on top of the Groups window.
Under **General**, each group must be given a name, an owner and optionally a description.
#### Setting Application Roles
Next, you can set the application roles using the from the drop-down menu under **Group Rights**. Setting the drop-down to **Read** will connect all users of the group to the default **Viewer** application role for all applications, which has read-only permission . By setting it to **Write** on the other hand will connect users in the group to the default **Editor** application role which has both read and write permissions.
To allocate application roles a per-application basis, you can select **Custom** and individually select for each application which role you want to assign to the group.
For example, the Demo Group in the figure above has Editor and Viewer application roles for the Projects application, but not to the Documents and Ledger applications
#### Adding users
Next to add members to the new group, under **Members** click on the **Add new member** field and select the users from the drop down menu.
### Modify an existing group
The steps to modify an existing are similar to creating a new group, firstly, click on the group you want to modify to access the group's details.
Depending on if you want to modify the application roles or add a new user , refer to [Setting Application Roles](/managing-users-and-collaboration/roles-and-permissions.md#setting-application-roles) or[ Adding users ](/managing-users-and-collaboration/roles-and-permissions.md#adding-users)sections above and follow the instructions.
## Collaboration
The Collaboration feature provides the foundation for controlling **who can see and collaborate with whom** inside the platform.\
With Collaboration Visibility, administrators can tailor the platform to support different types of user portals—such as customer portals, partner portals, internal departments, or restricted external access.\
By enabling or disabling Collaboration globally or per workspace, administrators can define completely isolated environments, shared collaboration spaces, or selective visibility between specific groups.\
This ensures that each workspace can be configured according to its target user type, security needs, and communication structure.
The second tab of the Team app is **Collaboration**.
* Collaboration: the umbrella feature covering both, visibility and communication.
* Visibility: Specifies who can see who. It is not required that the visibility is mutual, meaning that a user A can see a user B, even if user B can not see user A.
* Communication: A superset of visibility. A user can only be a communication partner if the visibility is mutual. Two users, A and B, can only communicate with each other if B is visible for user A and user A is visible for user B.
This section allows you to configure who can collaborate with whom.
Groups can define **rules** to grant or restrict access to users, features, or apps.
Each group defines a set of users, members of that particular group can see. The set of users is build by specifying one or more rules. Each rule is defined by two parameters:
* An operation (Add or Subtract)
* A group
Rules are evaluated from top to bottom.
\
The set of visible users starts empty. Then for each rule, the members of the group specified within the rule are either added or subtracted from the set of of visible users.
\
The outcome of processing all rules for a single group is set of visible users, each member of the owning group can see.
To manage exceptions, groups are assigned **access levels**:
* **Default** – standard access rights.
* **Priority** – overrides Default access when needed.
This structure enables both simple and complex scenarios:
* By default, **Everyone** can collaborate with all users.
* Special groups can be restricted from seeing others.
* Exclusive groups can be configured so only they collaborate among themselves.
A user can see another user if **any** of the groups they belong to indicates that the other user is visible. In other words, a user’s groups are effectively combined using a logical **OR** — if even one group allows visibility, the user can see the other person.
However, the set of groups that need to be evaluated can be narrowed down by considering the **Access Level**.
When a user belongs to multiple groups, only the groups that share the **same access level** are evaluated together. For example, if a user is part of one or more groups where the access level is set to **Priority**, then any groups with the access level **Default** will be **ignored** during visibility evaluation.
### **Example setup**
* **Everyone** → Default access with Everyone.
* **Managers** → no specific rules, but can collaborate through Everyone.
* **Developers** → no specific rules, but can collaborate through Everyone.
* **Externs** → Priority access, collaborate only with Managers and Developers.
* **Customer A** → Priority access, collaborate only with Managers and Customer A.
### Testing Configurations
The **Test** section makes it possible to validate configured collaboration rules.
Two users (User A and User B) can be assigned to specific groups. Based on these memberships, the following results are shown:
* **Visibility Result** – whether User A can see User B, and vice versa.
* **Communication Result** – whether both users are able to communicate.
This ensures that group rights and collaboration rules behave as expected before being applied in real usage.
### Collaboration Visibility
Learn how to manage the Collaboration feature globally and per workspace.
#### Overview
The **Collaboration Visibility** feature allows platform administrators to control whether the **Collaboration** functionality is available globally or within specific workspaces.\
This provides flexibility in managing collaboration access and ensures consistency across the platform.
The configuration can be accessed in the **Admin Center, more info** about the **Admin Center** can be found under the [**Platform**](/administration/platform.md).
#### Global Collaboration Configuration
The **Collaboration Availability** setting offers three configuration options:
* **Disabled**\
Disables the Collaboration feature globally across all workspaces.\
When this option is selected, all collaboration features and filters are turned off, but existing configurations are **not deleted**.\
This is also the **default setting** for new installations of the platform.
* **Available (Workspace default: Disabled)**\
Enables the Collaboration feature globally but keeps it **disabled by default** for newly created workspaces.\
Administrators can enable it manually per workspace.\
The default state does affect all workspaces - new or existing ones - which use the UseDefault setting for the collaboration.
* **Available (Workspace default: Enabled)**\
Enables the Collaboration feature globally and sets the **default state to enabled** for newly created workspaces.\
The default state does affect all workspaces - new or existing ones - which use the UseDefault setting for the collaboration.
#### Workspace-Level Collaboration Management
When Collaboration is available globally, administrators can manage it per workspace.
To do this:
1. Open the **Admin Center**.
2. Go to the **Workspaces** tab.
3. Select and open the desired workspace.
In the workspace view, open the **Settings** tab.\
Under the **Features** section, there will be an option to enable or disable **Collaboration** for this specific workspace.
If Collaboration has been disabled globally, a **warning message** will appear.\
This message indicates that no matter what is being selected under the workspace settings Collaboration will be disabled because of the global setting.
#### Example Scenario
If the global setting **Available (Workspace default: Disabled)** is selected:
* New workspaces will have Collaboration **disabled** by default.
* Administrators can later open a workspace and **enable** Collaboration manually via its **Settings → Features** section.
This structure ensures centralized control over the platform’s Collaboration capabilities while allowing workspace-level flexibility.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.tivity.one/managing-users-and-collaboration/roles-and-permissions.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.