Displaying a feature, viewing its data and changing that data may require different settings. First identify which customer account and user are affected, whether they are using the browser or mobile application, and which action is blocked. For a service request, also check its category, status and responsible workers.
Start with all of the user's roles
Perform the check in the browser as an administrator. Open Manage user accounts → List of users and open the user's details using the pencil icon on their row. Check Permissions (roles) in admin portal and Permissions (roles) in the mobile application separately. Using the same login does not mean the user has the same permissions in both interfaces.
Open the role settings under Manage user accounts → User roles. Check all of the user's roles: permissions can come from several roles. Changing one role does not remove a permission granted by another. Administrators have extensive permissions to manage service requests and their settings in the browser, so a successful test as an administrator does not show that an ordinary user's permissions are correct.
For other features, check both whether the feature is enabled for the customer account and the permissions of the relevant browser or mobile role. Read, Create, Edit and Delete are separate permissions. For example, permissions for products and permissions to create warehouse events must be checked separately. For more detailed instructions, see manager user permissions and mobile roles and folder permissions.
Find the service request category settings
Open Manage tasks → Service requests → Service request settings. On the Settings tab, check Service request feature in use. Then open the relevant category on the Service request categories tab. Its Basic info section contains the responsible roles, observers, creation permissions and mobile roles for specific statuses. Changing the category settings requires permission to edit the category.
Distinguish between folder permissions for a Spot and permissions for a service request. Being able to see a folder or Spot does not grant permission to handle a service request. Permissions for the general service request list depend on the category and, on mobile, also on the request's responsible workers and status; they do not follow the general folder restrictions. Finding a request through a Spot also requires access to that Spot.
A service request category is missing when creating a new request
Check that the category is In use. On mobile, the category must also be enabled using Usable in mobile application.
If Limit rights to create service requests is selected, check Roles with rights to create requests. The category selector checks the user's manager roles in the browser and mobile roles in the mobile application. Without this restriction, this role selection does not restrict creation. The category's responsible Manager role also grants creation permission in the browser, but selecting Executor managers alone does not.
Creation permission alone does not grant permission to see or edit the saved request. If the category is visible but saving fails, check the error message, required information and access permissions for the selected Spot. The issue is not necessarily a permission affecting category selection.
A service request is missing from the list
In the browser, open Manage tasks → Service requests and remove unnecessary search and status filters. Check the request's actual category and status. If necessary, see searching for and assigning service requests.
In the browser, the category's Manager role, Manager observers and Executor managers grant permission to view requests in that category. Membership in a mobile role alone does not grant these browser permissions for handling requests.
On mobile, check the request's status separately:
- In progress, Completed or Cancelled: the user receives viewing permission through the category's Mobile observers selection or by belonging to the responsible worker role assigned to the request.
- Open: the category's Show open service requests on mobile must be selected, and the user's role must be included under Mobile roles with rights to open requests. The ordinary Mobile observers selection alone is not enough. Permission for open requests also grants permission to start handling the request.
- On hold: the user's role must be included under Mobile roles that can see On hold requests or Mobile roles that can edit On hold requests. The responsible worker role alone is not enough to make these requests visible.
The browser status In progress corresponds to a request being handled on mobile; iOS calls it In Progress. Permissions for Open and On hold requests do not replace each other.
The request is visible but cannot be edited
In the browser, the category's Manager role grants permission to edit and forward the request. Manager observers receive viewing permission. The Allow adding comments and attachments setting for them grants permission to add comments and attachments, but does not grant general editing or completion permission.
Executor managers can view requests, add comments and attachments, and mark a request as completed. This alone does not grant permission to change, for example, the title, Spot, responsible workers or additional fields, or to forward, cancel or delete the request or move it to On hold.
On mobile, permission to edit a request being handled is based on the request's Responsible workers role. The category's Mobile observers and their permission to comment do not grant this on their own. Editing an On hold request and returning it to handling require a separate role with permission to edit On hold requests; the observer role for these requests allows viewing, comments and attachments.
A comment and an external message are different actions. An Executor manager in the browser can read existing external communication, but this permission alone does not allow starting a new conversation or replying. The setting allowing Manager observers to add comments and attachments also grants external communication permissions. Therefore, check all roles if the intention is to allow comments and completion without external messages. See comments and communication.
Marking a request as completed is blocked
In the browser, completing a request requires permission to edit the request or Executor manager permission for its category. In Android and iOS, the completion action in the request details—Mark as done on Android and COMPLETE on iOS—is unavailable for an Open or On hold request: the request must first be taken into handling. This requires permission to start handling a request in that status and a responsible worker role. An Executor manager in the browser can also complete an Open or On hold request directly if the other conditions are met.
Permission does not bypass the conditions for completion. The request must have at least one comment, required additional information must be filled in, and required signatures must be provided. If the category's After transferring to tasks setting is Mark the service request complete when all tasks have been marked complete, the related tasks must also be completed. Tasks under review qualify only if the service setting counts them as completed. If an Executor manager cannot fill in missing additional information, a user with editing permission must do so.
Marking a request as completed records the completion time and the person who completed it, and retains the request with its comments and attachments. It may trigger the processing of costs and warehouse events based on the recorded information, as well as notifications according to the settings. Completed, Cancelled and Forwarded are separate statuses; requests in these statuses cannot be returned to another status by changing the status selection. Completing a request does not delete it. For more background, see service request category visibility and permissions.
A responsible role is missing from the selection
The Responsible workers field in a browser service request selects a mobile role. In the role settings, check Right to complete tasks you are responsible for under Responsibilities and rights in Tasks and Service Requests. This setting allows the mobile role to be used in the responsible worker selection; it does not determine all service request permissions on its own.
Also check Visibility to Mobile Users in the roles of the manager making the selection. The service request's Responsible workers selection uses the mobile roles allowed for the manager and their own mobile roles, and restricts them to roles permitted to act as responsible workers. Visibility in the selection list does not grant permission to edit the request.
The category's Manager role and Executor managers selections, in turn, offer manager roles with Right to complete tasks you are responsible for or Right to complete and edit own tasks. The restrictions on these selections do not follow the manager's Visibility to Manager Users restriction. Do not assume that all selection lists use the same visibility setting.
Check approval of work hours separately
Work time tracking has its own permissions. Approving an hour recorded against a task requires permission to edit the task, and approving an hour recorded against a service request requires permission to edit the request. Permission only to view or comment on a service request, or an Executor manager's permission to complete it, is not enough to approve work hours. Being able to view a report does not grant permission to approve all of its entries. A processed work hour entry is also locked against changes to its approval.
Save carefully and check the result as the user
Changing a role's permission also affects its other members. The category's viewing and handling roles also affect previously created requests.
Also note the effect of the category's User role selection: saving the category settings assigns the selected mobile role as the responsible workers for all requests in the category other than Completed requests. This may replace responsible workers previously selected for individual requests, even if you change another setting in the category. Large numbers of requests are updated in the background. An empty selection does not clear previously assigned responsible workers, and this update does not itself change the requests' statuses.
After saving, check the result with the affected user in the correct customer account. Refresh the view and test the browser and mobile application separately. Confirm that the user can see the correct category when creating a request and can see a previously created request, and that the required editing, commenting or completion actions work. On mobile, test an Open request, a request being handled and an On hold request separately. Also check that the user has not received unnecessary permissions from another role and that the responsible workers of earlier requests have not changed unexpectedly.