The service request category determines who can create, view and handle its service requests. Configure browser manager permissions and mobile permissions separately. Permission to create a request alone does not grant permission to view the saved request, and permission to view it alone does not grant permission to handle it.
Open the category's permission settings
In the browser, open Manage tasks → Service requests → Service request settings. Select the Service request categories tab and click the pencil icon on the row of the category you want to change. Making changes requires permission to edit service request categories. An administrator has extensive permissions, so their view is not suitable for checking an ordinary user's permissions.
The manager and mobile roles, creation restrictions, and roles for Open and On hold requests are in the category's Basic info section. Options for use in the mobile application and on the public form are in the Settings section. Select roles according to whether users need to view, comment on, complete or handle requests more extensively.
Roles for handling requests in the browser
Manager role grants permission to view, edit and forward requests in the category. It is the role responsible for handling requests in the browser and is distinct from the mobile User role. The Manager role's permissions apply to requests in the category, not just requests assigned to a particular mobile role.
Manager observers can view requests in the category and their attachments. If they also need to add comments and attachments, select Allow adding comments and attachments where Manager observers appears beneath the option. This option does not grant permission to mark a request as completed or change its basic information.
Executor managers can view requests in the category and their attachments, add comments and attachments, and mark requests as completed. These permissions also apply to previously created requests and do not require the comments and attachments option for Manager observers.
Executor manager permissions alone do not allow changes to, for example, the title, description, Spot, priority, responsible worker or additional fields. They also do not allow the user to forward, cancel or delete a request, or move it to On hold. Permissions from a user's different roles are combined: if they also belong to the category's responsible Manager role, they receive its broader permissions. Removing a user from one role selection therefore does not necessarily remove their permission.
The Manager role and Executor managers selections include manager roles with Right to complete tasks you are responsible for or Right to complete and edit own tasks. The Manager observers selection uses a broader set of roles. The actual service request permissions are still determined by the category's selections. See also defining a manager user's permissions.
A comment and an external message are different actions
An executor manager can read a request's existing external communication. However, executor manager permissions alone do not grant permission to start an external conversation or send a reply to an existing conversation.
The Allow adding comments and attachments option for Manager observers also grants permission to send external messages in the browser. If you want to allow commenting and completion without external communication, use the Executor managers selection and check that the user does not receive communication permissions from another role.
Adding an internal comment does not itself send an external message. However, completing a request may send the reporter a completion notification that includes comments, according to the settings. Sending messages is described in service request comments and communication.
Restricting permission to create requests
When Limit rights to create service requests is not selected, ordinary manager and mobile users' permission to create requests is not restricted by the category's creator roles. When the restriction is enabled, define the permitted manager and mobile roles under Roles with rights to create requests. The category's responsible Manager role also has permission to create service requests.
Executor manager permissions alone do not grant permission to create requests. A creator role alone, in turn, does not grant permission to view or handle a saved request. When selecting a category for a new request in the mobile application, users only see active categories that are allowed in the mobile application and that their creator roles or the unrestricted creation setting permit them to use.
This role restriction applies to creation by signed-in users. Categories and access for the public form are configured separately.
Responsibility and visibility in the mobile application
The browser's manager selections do not replace mobile role settings. In the Settings section, check Usable in mobile application. This option makes the category available in mobile category selections; clearing it alone does not hide requests that have already been saved. Their visibility and handling permissions depend on the request's status and the user's roles.
User role in the Basic info section is the default responsible mobile role. A new request receives this role if no responsible role has been explicitly set for it. When a new Open request has a responsible role, it moves to in progress when saved. Without a responsible role, the request may remain open.
The selections for the responsible User role, roles that can handle open requests, and editors of On hold requests include mobile roles with Role functions as a responsible for tasks and/or service request enabled. The selections for Mobile observers and observers of On hold requests use a broader set of mobile roles. An observer role alone may therefore not qualify as a responsible worker role.
- In progress, Completed and Cancelled: users belonging to a request's responsible worker role can see their role's requests. Mobile observers can see requests in the category that have these statuses. The responsible role grants handling permissions, but status changes from final statuses are restricted. Observers can be allowed to add comments and attachments using the option with Mobile observers beneath it; this alone does not grant permission to complete requests.
- Open: select Show open service requests on mobile and define Mobile roles with rights to open requests. Users belonging to these roles can see open requests and take them into progress under a responsible worker role. The ordinary Mobile observers selection or a responsible role saved on the request alone does not make the open requests queue available.
- On hold: Mobile roles that can see On hold requests can view them and add comments and attachments. Mobile roles that can edit On hold requests can also edit them and return them to in progress. An editor role includes visibility, so it does not need to be added separately to the observers. The responsible worker role alone or the ordinary Mobile observers selection is not sufficient to see an On hold request.
On Android and iOS, an Open or On hold request must first be moved to in progress before it can be marked as completed. In the request details, the action for doing this is Set to In Progress. On Android, open it using the Forward to another responsible button; on iOS, use the request's action button. For an Open request, the action requires a role that can handle open requests, and returning an On hold request to in progress requires an On hold editor role. The status is called In progress on Android, In Progress on iOS, and In progress in the browser's service request status selection.
Saving a category also changes existing mobile responsibilities
Check User role before every category save. If the field is filled in, saving replaces the responsible worker role on all requests in the category except Completed requests with this role. The change also applies to requests with explicitly assigned responsibilities and to Open, In progress, On hold, Cancelled and Forwarded requests. It also happens when you save only other category settings and leave the responsible role unchanged.
For example, if an individual In progress request is assigned to Maintenance but the category's User role is Property Maintenance, saving the category changes the request's responsibility to Property Maintenance. A Maintenance user may lose visibility and handling permissions unless they receive them from another role. The responsibility on a Completed request remains unchanged.
If there are at least 200 such requests with a status other than Completed, responsibilities are updated in the background and the change may not appear immediately. Clearing the default role does not clear responsibilities on existing requests. An empty field leaves their current responsibilities unchanged.
This update changes the responsible role but does not also change the request's status. For example, an existing Open request remains open even when it receives a role. The update does not generate the normal notification for a change of responsibility on an individual request or a responsibility change history entry. Therefore, check the actual responsibilities and mobile visibility of existing requests after saving; monitoring notifications or history alone is not sufficient.
Permission to complete requests does not override completion requirements
In the browser, an executor manager can mark an Open, In progress or On hold request as Completed. The request must have at least one saved comment. Mandatory additional fields and required signatures are also checked during completion. If, for example, an additional field is missing, a user with editing permissions must fill it in; executor manager permissions do not grant permission to change additional fields.
If After transferring to tasks in the category's Basic info section is set to Mark the service request complete when all tasks have been marked complete, all related tasks must meet the completion condition. Other task statuses, including a cancelled task, prevent completion. A task's In review status is accepted only if the shared setting allows it. The setting's UI label is Consider "In Review" tasks as "Completed" for Service Request settings; "In Review" in this label refers to this review status. The category's edit window shows information about the shared setting's current effect.
Automatic completion associated with transferring a request to tasks bypasses the service request's signature check: this applies both to immediate completion during transfer and to completion triggered by the completion of related tasks. A previously created task alone does not exempt a later manual completion from signature requirements.
A Cancelled or Forwarded request cannot be changed to Completed, and a Completed request cannot be reopened by changing its status. Marking a request as completed retains the request, comments and attachments, and records the completion time and, for manual completion, the user who completed it. It ends ongoing time entries, generates costs under the applicable conditions and starts warehouse product processing. Completion notifications may be sent to the reporter and responsible managers according to the settings. The public reply page closes when the request reaches a final status. See completing a service request for the detailed workflow.
Check the public form separately
Used on public form in the Settings section applies to the default form. Forms configured separately under Public forms use their own category and Spot selections. Also check the form's settings if a category unexpectedly appears or is missing for an external user.
Do not send communication link to reporter omits the link for further communication from the confirmation email for a public request in this category. It does not change access to the public form. See public service request form settings.
Save and verify permissions in practice
Click Save in the category's edit window. Reopen the settings and verify the role selections. Also check the responsible workers on previously created requests, after the background update has finished if necessary. Finding requests and changing individual responsibilities are described in searching for and assigning service requests.
Check different users' views for the same category and all of their roles. Use Open, In progress and On hold requests: separately verify that users can find and open requests, add comments and attachments, edit requests, and access the action for moving them to in progress. In the browser, also verify the executor manager's permission to complete requests and the observer's limitations. Do not complete an actual unfinished request just to test permissions.
Check Android and iOS if both are used, as well as category selection for a new request using the intended creator role. Refresh the lists and remove unnecessary search filters before drawing conclusions. In mobile lists for a specific Spot, permissions for the Spot and folder may also affect the results; appearing in such a list alone does not prove permission to open or handle the request. Check the public form at its own address. Successfully saving the settings does not yet prove that different users can see and do exactly what is intended.