Permissions & Responsibilities
Permissions and Responsibilities Rules in Trivvo
Creating a task or record does not automatically grant its creator permission to view it. An exception applies to users who create records through a portal: they may view and follow up on the records they created through their own portal.
To view a record or task, a user must be specified in one of the following fields:
• Responsible
• Assignee
• Viewers
A user listed in the “Viewers” field may view the record only and cannot edit it unless separately granted editing permission. A user designated as Responsible or Assignee may edit, close, and perform other available actions on the record.
For all record types, the permissions system includes a “User” field, set to “All” by default.
If no user is selected, the employee cannot view records created by any user.
If one or more users are selected, the employee can view all records created by those users or records in which those users are listed as Responsible, Assignee, or Viewer.
If “All” is selected, the employee can view all records regardless of who created them.
If “Current User” is selected, the employee can view only records they created.
The “Group” field in permissions operates in the same manner as the “User” field.
Applying distribution rules when creating a record
When a new record is created, the system first applies any distribution rules defined for that record type. After creation, the Responsible, Assignee, or viewing permissions may be modified manually, subject to the user's permissions.
Inheriting responsibilities and permissions from the source record
When a new record is created from another record, the system inherits the Responsible, Assignee, and viewing permissions from the source, unless a distribution rule exists for the new record. In that case, the distribution rule takes priority.
Project Responsible on tasks
When a task is created within a project, whether manually or automatically, the Project Responsible is added as Responsible for the task. An exception applies when a distribution rule specifies a different method of assigning responsible users.
Priority of distribution rules
Distribution rules take the highest priority when determining Responsible, Assignee, and viewing permissions. If no distribution rule exists, inheritance and other rules associated with the record apply.
Illustrative example:
A task is created from a ticket within the “Software Issues” project.
• Responsible for the “Software Issues” project: Ammar.
• Responsible for the ticket: Bassam.
• No task-specific distribution rule exists.
When the task is created:
Bassam is assigned as Responsible for the task through inheritance from the ticket.
Ammar is also added as Responsible for the task because he is the Project Responsible.
Thus, Bassam and Ammar are both Responsible for the task.
Exceptions to inheritance rules:
This feature defines situations in which the Responsible, Assignee, or viewing permissions should not be transferred from a source record to a record created from it.
Configure the exception by specifying:
Source record: the record from which the new record is created.
New record: the record being created.
Enable the “Prevent Inheritance” option.
When enabled, responsibility, assignment, and viewing information is not transferred from the source record to the new record. Instead, it is determined by other system rules, such as distribution rules or manual selection, subject to permissions.
Example:
If inheritance from ticket to task is prevented, creating a task within a ticket does not automatically transfer the ticket's responsibilities or viewing permissions to that task.
Team membership grants viewing and control rights dynamically. When an employee leaves the team, they lose the viewing and control permissions granted through membership, except for tickets in which they are personally listed as Responsible or Assignee.
The “Display” permission column works as follows: it permits a record to appear in lists and workflows without allowing the user to open it or see its details.
The “Display” permission column works as follows: it permits a record to appear in lists and workflows and allows the user to view its details.
The “View” and “Display” options are not available in all permissions for tickets, projects, tasks, opportunities, leads, and subscriptions.
The “Edit” column is available in all permissions for tickets, projects, tasks, opportunities, leads, and subscriptions. A record for which Edit is enabled can be edited even if the user is listed only as a Viewer.
Unified Ownership, Responsibility, and Action Rules
All Trivvo record types—lead, opportunity, task, and ticket—follow the same administrative structure, without exception:
Rule analysis
Responsibility fields:
Record creator: the identity of the person who created the record is stored in the record history.
Record Responsible: the “Responsible” field identifies the person accountable for fulfilling the record's requirements.
Assignee: when the record requires an employee to perform the work, the “Assignee” field is used.
Viewers: an employee may view records in which they are listed as a Viewer, but cannot edit them unless granted editing permission.
Referral / Transfer:
Location: the Transfer action is available under Actions for all record types that contain Responsible and Assignee fields (leads, opportunities, subscriptions, tickets, projects, and tasks).
Purpose: to change the Responsible and Assignee when the record moves entirely outside the scope of an employee or branch—for example, moving a customer between branches, replacing an employee who left the company, or correcting assignment to an unrelated employee.
Effect: Responsible, Assignee, and Viewers may be changed. The action is recorded in the history and is subject to permissions.
History log: every Transfer is recorded with the user name, timestamp, and reason to prevent responsibilities from being lost between employees.
Assignment:
Location: the Assignment action is available under Actions for all record types that contain Responsible and Assignee fields (leads, opportunities, subscriptions, tickets, projects, and tasks).
Purpose: to delegate operational work to another employee while the original Responsible remains accountable for the final outcome—for example, a project or team manager remains Responsible while assigning execution to another employee.
Technical effect: the record remains on the Responsible person's reporting dashboard and appears on the Assignee's daily task list.
History log: every Assignment is recorded with the user name, timestamp, and reason to prevent responsibilities from being lost between employees.
Projects and Tasks
A user designated as Project Responsible can view the project and all its tasks, and can control and edit those tasks even when not personally listed as Responsible, Assignee, or Viewer on them.
A user listed as Viewer on a project may view that project and the tasks associated with that user (that is, tasks on which the user is Responsible, Assignee, or Viewer), but cannot control or edit them.
If an employee is neither Project Responsible nor listed as Viewer on the project, it will not appear in their project list or workflow. Nevertheless, they can view tasks within that project if listed as Responsible, Assignee, or Viewer on those tasks.
The permissions system for projects and tasks includes a “Group” field, allowing users to view the activities and records of users specified in that field even if the viewing user is not a Responsible, Assignee, Viewer, or creator of the record.
Project and task privacy: the settings for each project include:
• Project Privacy
• Task Privacy
Each field has two options: Public and Private.
First: Project Privacy
Public: all users with access to the Projects module may view the project, even if they are not its Responsible, Assignee, or Viewer.
Private: only users listed as Responsible, Assignee, or Viewer on the project may view it.
Second: Task Privacy
Public: all users with access to the Projects module may view all tasks within the project, even if they are not Responsible, Assignee, or Viewer on individual tasks.
Private: a user may view a task only if listed as its Responsible, Assignee, or Viewer.
Project Privacy and Task Privacy are independent settings. A project can therefore be Public while its tasks are Private, or vice versa, depending on the project's requirements.
Comprehensive-permissions exception: precedence depends on whether “Override Project and Task Privacy Within Permission Scope” is enabled:
When disabled: Public/Private settings take precedence. Public projects and tasks are visible under the public-access rules; Private projects and tasks are visible only to their Responsible, Assignee, or Viewer, even if the User or Group scope covers other users.
When enabled: the viewing scope defined in the “User” and “Group” fields takes precedence. The employee may view projects and tasks associated with users within that scope, whether Public or Private, without being individually listed as Responsible, Assignee, or Viewer. Viewing is restricted to that scope only.
This rule applies only to viewing, requires existing module-access and viewing permission, and does not grant additional create, edit, or delete permissions.
Tickets
When a team is assigned to a specific ticket type, every member of that team may view all tickets of that type, even if not listed as Responsible, Assignee, or Viewer on the individual ticket.
A ticket type has a Team and multiple Responsible users. A Responsible user for that ticket type can view all tickets of the type, regardless of whether they are Responsible, Assignee, or Viewer on a particular ticket.
A ticket includes the following fields:
• Team
• Responsible
• Assignee
• Viewers
A user listed in the “Viewers” field on a ticket can view tickets associated with that user.
The ticket permissions system includes a “Group” field, allowing a user to view the activities and records of the users specified in that field even when not listed as Responsible, Assignee, Viewer, or record creator.
When a ticket type uses Round Robin or Workload-based distribution and a Team is selected, the Team Leader becomes Responsible, the Assignee is selected according to the distribution rules, and the remaining team members become Viewers.
When a ticket type uses Round Robin or Workload-based distribution and one or more users are selected without a Team, no Responsible is set. One of the specified users becomes Assignee according to the distribution rules; the remaining users become Viewers.
When a ticket type has “No Distribution” and a Team is selected, the Team Leader becomes Responsible, the Assignee remains blank, and the other team members become Viewers.
When a ticket type has “No Distribution” and one or more employees are selected, neither Responsible nor Assignee is set; all selected users become Viewers.
If no employee is assigned, the “Claim” action is enabled. Once a ticket is claimed, the claimant becomes its Assignee.
Subscriptions
Subscriptions include the following fields:
• Responsible
• Assignee
• Viewers
These fields may be set manually or by distribution rules.
A user specified in the “Viewers” field on projects can view tickets associated with that user.
The project permissions system includes a “Group” field, allowing users to view the activities and records of users selected in that field even if they are not Responsible, Assignee, Viewer, or record creator.
Customer Relationship Management (CRM)
Opportunities and leads include the following fields:
• Team
• Responsible
• Assignee
• Viewers
These fields may be set manually or through distribution rules; distribution rules always take precedence.
A user specified in the “Viewers” field on projects can view opportunities and leads associated with that user.
The permissions system for leads and projects includes a “Group” field, allowing users to view the activities and records of users selected in that field even if they are not Responsible, Assignee, Viewer, or record creator.
Direct Manager and Team Permissions (Not Active in the Current Version)
An employee's direct manager, as defined in the organizational structure, automatically inherits viewing or management permissions for all records on which the subordinate employee is Responsible or Assignee, unless the “Exclude Manager from Viewing Subordinates’ Records” option is enabled in permissions.
The Direct Manager exclusion option is available in all system permissions.