Assigning a service request directs its handling to a mobile role. Select the role whose members will handle the matter, and after saving, check both the request's status and its visibility to the intended users.

Permissions and what Responsible workers means

Responsible workers is a mobile role, not an individual person. Members of the role receive permissions to handle requests assigned to that role. The service request type's Manager role, in turn, determines who is responsible for handling requests in the browser. Changing Responsible workers does not change the type's Manager role.

Assigning a request in the browser requires permission to edit the request. Permission only to view it or to add comments and attachments is not sufficient. Executor managers can add information to requests and complete them, but this permission alone does not allow them to change Responsible workers. Permissions from a user's different roles are combined.

The Responsible workers selection list shows the mobile roles allowed to act as responsible workers. A manager's selection is also limited by the mobile roles allowed for that manager and their own mobile roles. If the required role is missing, ask an administrator to check the role's settings and your permissions. See service request visibility and permissions.

Find a request in the browser

From the menu, open Manage tasks → Service requests → Service requests. The list includes requests covered by your permissions; you may not see every request in the organization.

  1. Filter the list using the search fields and selections beneath the column headings, for example by service request type, status or Spot. Search by title or request number. Multiple filters narrow the results together.
  2. Open the correct request using the pencil icon on its row.
  3. On the request's Basic info tab, check the title, description, submitter's details and Spot. Make sure you have the correct request before assigning it.

You can change how folders are sorted using the arrow menu in the Folder column heading. Full folder path sorts requests by folder path, starting from the root folder. Folder name only sorts them using the folder's own name.

Set or change Responsible workers

In the Responsible workers field on the Basic info tab, select the mobile role that will handle the work. Also check the Status. Save at the bottom of the window keeps the request open; Save and close closes the window after saving.

  • Open: when you set Responsible workers, saving automatically changes the status to In progress. Leaving Open selected does not prevent this. A new request may already have Responsible workers set through the type's default setting.
  • In progress: the request requires a responsible workers role. You can change the role, but you cannot simply clear the field in this status. If you want to return the request to Open without responsible workers, clear the role and select Open before saving.
  • On hold: select this status when handling is waiting for something such as additional information or a spare part. Fill in the required The reason for the on hold status field that appears on the same tab. Selecting Responsible workers alone does not return an On hold request to processing: also select In progress when work can resume.
  • Completed, Cancelled and Forwarded: requests in these statuses cannot be reopened using the status selection. These statuses do not mean that the request has been deleted.

With edit permission, you can also change Responsible workers directly in the list by double-clicking the Responsible workers cell. The cell change is submitted for saving when editing ends. After this, too, open the request and check the saved result.

Assignment and the In progress status do not mean that the work is complete. Marking a request as completed requires, among other things, a comment, completion of the required additional information and the required signatures. The statuses of related tasks may also restrict completion. See completing the handling of a service request. Routing a request to another service request type is a separate forwarding function.

Find a request and start handling it on mobile

Open Service requests in the mobile app. On Android, the status queues include Open, In progress, On hold and Completed; on iOS, they include Open, In Progress, On hold and Completed. The mobile In progress or In Progress queue corresponds to the browser's In progress status.

First select the correct status queue. On Android, open the filters using the filter icon at the top of the list. On iOS, use the filter icon on the right of the top bar. Filter by criteria such as request name, Spot, folder, type, priority or responsible role, and confirm with Save. Open the request you find in the list and check its contents.

In this version, the new iOS sorting options do not sort the list by the selected fields. Use filters to find requests; do not assume a request is missing based on the sorting option you selected.

  1. In the details of an Open or On hold request, open Actions. This opens the Service request actions window.
  2. Select the responsible role. The field's prompt is Select Responsible on Android and Select responsible on iOS, but for a service request, the selection refers to a mobile role.
  3. Press Set to In Progress. This saves the selected responsible role and changes the request to the In progress status.

Starting to handle a request requires a separate permission. When displaying open requests is enabled, open requests are visible only to the mobile roles allowed to view open requests in the type's settings. Permissions to view and edit On hold requests are configured separately: a viewer can add comments and attachments, but returning a request to processing requires permission to edit On hold requests. The request's responsible workers role alone does not grant visibility to an On hold request. A request may therefore disappear from a user's current queue when its status or assignment changes.

Find requests awaiting signatures

In the browser, show the signature columns, which are hidden by default, using the column icon in the table's header row, or by right-clicking a column heading and selecting the columns from the menu that opens.

  • Signatures required from: enter a signer's name or part of the name in the column's search field. For requests with a status other than Completed, the search targets active signature requirements. For Completed requests, it finds signatures that have been provided.
  • Signatures missing from: enter your own name or another signer's name to find requests missing that required signature. Signatures already provided and Completed requests are excluded from these search results.

The search primarily uses the service request type's active signature requirements. Only when there are none does it use the request's own active requirements. A result in the missing-signature search therefore does not, by itself, mean that the request is currently being handled: also filter by status if necessary.

If there are several signers, the column may display Multiple signatories. Searching by name still works with an individual signer's name. The list may also display No required signatures or All signed. Open the request and check the details on the Signatures tab.

Verify the saved result

Reopen the request and check the responsible role and status. With a user who belongs to the intended role, verify that the request appears in the correct mobile queue and that the necessary handling actions are available. Changing the assignment may remove access granted by the previous responsible role; the user may still see the request through other permissions. Assignment and status changes are recorded in the request's change history.

Saving may send assignment and status change notifications to the request's submitter and the type's responsible managers, according to the settings. These email notifications are not automatically sent to all members of the mobile responsible workers role. There is also a mobile notification for role changes, and receiving it depends on notification subscriptions. The absence of a notification is not evidence that saving failed.

If you cannot find the request, remove unnecessary filters and check the other status queues. If assignment fails, check the role, status, required information and permissions. Do not create a new request for the same matter just because the original is not visible with the current filters.