Project Roles
Head to Admin > Infocapture > Your Project > Project Permissions > Project Roles
Project roles are the collections of users who have the same level of rights across the project.
Think about how many different 'levels' of access your users will need to be separated into. An example would be:
Users: A role that has all staff in. They can submit new forms but not amend existing ones.
Managers: A role with managers, who have permission to handle and edit existing forms.
Admin: A role with full permission to make any changes they like and manage the form.
An ideal number of roles would be no more than 3.
As a general rule, if you are creating more than 5 roles, it's likely that you are overthinking things, and adding unnecessary complexity which could make the form harder for your team to manage.
The order of project roles is important for creating field visibility rules later on (if applicable). Read more about this here.
Use the arrows next to each role to change its order as required.
For now, a guideline is to ensure the role with the most rights e.g. 'Managers', 'form admin' is on the top and those with the least e.g. 'All staff', 'Users' are listed last.
When you are ready to create your roles, click the 'Add new project role' button:
Give the role a name indicative of its members and what they are going to be able to do:
Next, enter the users/roles/groups that will be members of this project role and get the abilities that are assigned to them in the next section. Click 'Apply permissions' to save this:
The new role will appear listed in the 'Project permissions' area.
Rights
Now click on the Rights tab.
The table used to give project roles different permissions is shown.
In a new project the table will be blank, it's easiest to fill out one column at a time whilst thinking about what you want the corresponding project role members to be able to do:
The level of rights can be defined for each project role, the submitter (aka reporter) and the handler.
An administrator can update these rights at any time from the admin side of the project.
| Rights | Description | Things to bear in mind... |
| View tickets | Users are permitted to view tickets | This will allow the user, in the specified role, to see all submitted tickets. You may wish to just allow the Submitter column view rights, rather than your 'all users/submitter' role. This would mean that users could only see tickets that they themselves have created, but not those created by others. |
| Update tickets | Users are permitted to edit the form after submission | A user may be able to edit a ticket but if field visibilities have been configured, they may not be able to update some or any fields. |
| Submit tickets | Users are permitted to submit new tickets | |
| Handle tickets | Users are permitted to be the handler of the ticket, i.e. the user the ticket is assigned to | Only users with handle ticket rights will appear in the list of possible ticket handlers. |
| Update ticket status | Users are permitted to change the status of the ticket | A user may be able to change the status but if a project workflow has been configured, there may be restrictions, including when they can change the status and what they are allowed to change the status to. |
| Assign tickets | Users are permitted to change the handler of the ticket (i.e. the user the ticket is assigned to). | |
| View notes | Users are permitted to view notes added to the ticket | |
| Add notes | Users are permitted to add notes to the ticket | |
| View files | Users are permitted to view files attached to the ticket | |
| Attach files | Users are permitted to attach files to the ticket |
The default file size upload limit in Infocapture is 15MB. Any file larger than this will fail to upload and cannot be uploaded unless the limit is raised or the file is made smaller. If you require larger uploads in your forms please raise a support ticket for our team to assist. |
| View history | Users are permitted to view the history of the ticket | This includes the full history log, which captures all changes throughout the ticket life cycle, and the history diagram, which displays a graphical representation of status and SLA changes. |
| Manage tickets | Users are permitted to delete tickets, delete files attached to tickets and delete notes added to tickets | |
| View reports page | Users are permitted to view the reports page | Usually reserved for administrative project roles only |
| View Statistics page | Users are permitted to view the statistics page | Usually reserved for administrative project roles only |
Users will have access to:
- All tickets OR…
- ...Only tickets of which they are the submitter AND/OR...
- ...Only tickets of which they are the handler
Rights can be defined for all tickets or only tickets of which the user is the submitter or handler. For example, users may be able to see all tickets submitted, but only be able to update those that they submitted themselves.
If you require more complex permissions than this, it may be possible by using a custom plugin. For more information, please see here.
An example rights table
Things to note:
- All staff don't have 'View tickets' rights so they can't view all the submitted forms...
- .... but 'Managers' can see everything submitted...
- ... It's important to allow the 'Submitter' of the ticket role view rights though. This means if a user creates a new ticket, they can see it, along with any others that they created themselves.
- Creating new tickets is the only right that the majority of users, within the 'All Staff' role, have.
- 'Managers' can handle tickets, meaning that tickets can be assigned to any individual within this role.
- Additionally, they can update the status of tickets. A user in the 'All Staff' role would be able to see the status of any ticket they've submitted, but not change it.
- Manage tickets gives users the ability to delete submitted tickets, files, and notes. It's important to untick this box so that a user can't delete other peoples' notes and files within the tickets that they submitted.
- Administrators can do everything so they are able to assist with any support issues or testing that may be required in the form. It's crucial they are able to see all tickets and perform every action for this purpose.
The options tab
This area allows for the configuration of private notes, which are optional to enable.
Notes in InfoCapture by default are public, meaning any user with permission to 'view notes' can see them.
Enabling private notes means the ability to create and view them can be given to only users within certain project roles.
It may not be required for every use case, so test this out to see how it could work for you.
Recommended next article:
Creating a form
