A service request category determines what information is collected in a request, who handles it, and how transferring it to a task affects its completion. Additional field definitions are shared: the same field can be linked to several categories, but the field order and required status are defined separately for each category.

Configure the settings in the browser using an account with permission to create and edit service request categories and change service request settings. Permission to handle requests alone is not sufficient. The service request feature must be enabled before you can save a test request.

Create the additional fields you need

Open Manage tasks → Service requests → Service request settings. Select the Field keys tab. This view is used to create shared field definitions; the category's own Additional fields section is where you link them to the category.

  1. Select Create new field key.
  2. Give the field a clear, unique Name and select its Input type.
  3. If you select a drop-down menu, define its options.
  4. Save the field using the form's Create new field key button. Create any other fields you need in the same way.

Choose the type based on the information you want to collect:

  • Short text field: a short answer, such as a device identifier or further details about the fault type. Also use this for identifiers whose leading zeros must be preserved.
  • Long text field: a free-form description spanning several lines. The maximum length of a saved text value is 4,028 characters.
  • Number: information handled as an integer, such as a quantity. The decimal portion is discarded when the value is read; the value is not rounded to the nearest integer. This field is therefore unsuitable for measurements that require decimal precision.
  • Checkbox: a yes/no choice, such as confirmation that a device has been stopped. Note the platform differences in required selections described below.
  • Drop-down menu: one answer from predefined options, such as a fault category.
  • Date: the date of an event. In the browser, the field also includes a time; on the Android creation form, you select a date. Before using this field for information that requires an exact time on every platform, check how the forms work.

Enter drop-down menu options on separate rows. Add a row using the plus icon in the option list. You can also use Paste values as list and separate the options with line breaks or commas. Each option must be unique, no more than 50 characters long, and contain no commas within it. A comma separates one option from another.

Changing a shared field's name or options affects every category that uses it. The field name shown on an old request also comes from the shared definition. You cannot change an existing field's type in the standard edit form. If you need a different type, create a new field and link it to the relevant categories. Before deleting a drop-down menu option that is in use, consider existing answers: a deleted option is no longer a valid selection when the field value is saved again.

Create a service request category and define its basic information

Select the Service request categories tab in the settings, then Create new category.

  1. In the Basic info section, enter a unique Name and, if needed, a Description. The maximum length is 128 characters for the name and 4,096 characters for the description.
  2. Set the Order. A category with a lower order number appears before one with a higher number in the category selector. If you leave the number blank, the category is placed after the current highest order number. In the standard browser and mobile category selectors, the default category appears before the other categories; categories on a separate public form are sorted by order number.
  3. Select Is default if needed. To change the default category, open the other category you want to use, select it as the default, and save. The previous category's default selection is cleared. You cannot simply clear the selection on the current default category, and you cannot delete the default category; it remains active.
  4. Select Selecting a Spot is a required field if needed. You cannot combine this with Used on public form, because the system's default form does not have a Spot selector. On a separately configured public form, Spots are selected for each form individually.
  5. Configure After transferring to tasks, the responsible roles, settings, and additional fields as described below.

Select responsible roles and access channels

In the Basic info section, Manager role defines the role that handles requests in this category in the browser. User role is the mobile role used as the default responsible worker role for a new request. If a new Open request has a responsible worker role, it moves to In progress.

Executor managers can view requests, comment, add attachments, and mark requests as complete without any other editing permissions. Manager observers and Mobile observers are separate observer selections; permission to comment and add attachments is granted separately for each. Limit rights to create service requests and Roles with rights to create requests restrict creation. Permission to create requests does not itself grant permission to handle them. Mobile permissions for Open and On hold requests are defined separately. For detailed conditions, see service request visibility and permissions.

Before saving, note: if the category's User role is set, saving the category may also replace the responsible worker roles on previously created requests with this role. The update affects all requests other than Completed requests, including cancelled and forwarded requests. It happens even if you only change another category setting. With large numbers of requests, the update runs in the background. This responsible role update does not change request statuses. Clearing the role selection does not clear the responsibilities on old requests.

In the Settings section, Usable in mobile application makes the category available on Android and iOS according to the user's permissions. Used on public form applies to the system's default form. For separately created forms under Public forms, categories are selected individually for each form. Selecting an access channel alone does not guarantee that a mobile user has permission to create or view requests.

In the same section, you can hide the target tag surface number field on the public form or change its label. The form's category and target selections are described in public service request form settings.

Link fields to the category

  1. Open the category's Additional fields section and select Add new field. The button adds a selection row; it does not create a new shared field definition.
  2. Select a previously created field for the row. The field type comes from its shared definition. You cannot add the same field to a category twice.
  3. Select Required field if needed.
  4. Add the other fields and drag the rows into the order you want.

The required status and order apply to this category. The same field can be optional and appear in a different position on another category's form. Required additional information is checked when a request is created and when it moves to Completed. A standard server update to an incomplete request does not perform the same check, but the mobile form may also require the mandatory information when saving edits.

A required yes/no field does not work consistently across all platforms. On the Android new request form and the public form, the selection must be on. The iOS creation form also treats an off selection as an answer, but when editing additional information on iOS, a required field previously saved as yes cannot be changed to no. Do not use a required Checkbox field assuming that it requires the same confirmation in the browser, on Android, and on iOS. If the respondent needs to be able to choose either Yes or No, use a drop-down menu with these options and check its behavior with a test request.

What happens when you transfer a request to a task?

For a new category, After transferring to tasks in the Basic info section defaults to immediate completion. Select the option that suits your process:

  • Mark the service request as complete immediately: the browser's transfer-to-task action marks the request as complete during the transfer if the conditions for saving are met. This does not mean that the task created is complete.
  • Mark the service request complete when all tasks have been marked complete: when a task is completed, all tasks related to the request are checked. The request can be marked as complete when none of them are incomplete and the request's other completion conditions are met. Manual completion is also prevented if the related tasks do not meet this condition. If there are no related tasks, this task condition does not prevent manual completion.
  • Do not do anything. The service request will later be marked as completed manually: transferring the request to a task does not change its status. The request is completed separately.

The option that waits for all tasks to be completed is affected by the shared setting Consider "In Review" tasks as "Completed" for Service Request settings. When it is enabled, tasks in In review are also accepted when checking the completion condition. Otherwise, only the Completed status is accepted. Other statuses, including a cancelled task, prevent the condition from being met. A task moving to In review alone does not trigger an automatic completion check.

On Android and iOS, a related task is added to the service request. This is a different action from transferring a request to a task in the browser, and immediate completion does not apply to adding a task on mobile. The check based on all tasks being completed also applies to related tasks added on mobile.

Completing a request generally requires a comment, required additional information, and required signatures. The completion processing performed when transferring a request to a task bypasses the request's signature check. You can configure signatures in the category's Signatures section using Add Signature. If you choose to transfer requests to tasks, do not assume that the request's signature requirement will prevent automatic completion.

The Completed status preserves the request's information and records the completion time. Completion can also trigger the processing of costs, inventory transactions, and notifications. See completion conditions and effects and forwarding a service request and transferring it to a task.

Notifications and the communication link in the confirmation email

In the category's Email notification settings section, enter the notification recipients for new requests in Email to send notification to. Separate addresses with a space, comma, or semicolon. Sending also requires the shared Send notification of a new service request selection on the Settings tab. You can define a category-specific email subject and message text and select Include additional fields in the email. In the new request email, the category-specific message text replaces the shared text; the request's basic information is still included.

In the Settings section, select Do not send communication link to reporter if you want to omit the reply link from the confirmation email sent for public service requests in this category. This setting applies to the category and is disabled by default.

The confirmation email is still sent to the email address provided in the request. When this selection is enabled, the email states that the service request has been submitted, but omits the reply link and the instructions for sending additional information through the link. When the selection is disabled, the confirmation email includes the communication link.

The setting does not change access to the public form or prevent the person handling the request from sending the reporter a message later. An email sent by the person handling the request may still contain a reply link. The setting also does not invalidate previously sent links; access to the reply page is affected separately by the request's status and the link's validity. See follow-up communication for a public service request.

Unlinking and deactivating a field

The trash icon on a row in the category's Additional fields section unlinks the field from this category when you save the change. It does not delete field values already saved on service requests or affect the field's use in other categories. The deletion warning refers to deleting values, but unlinking a field from a category preserves saved values. Preserving the values does not mean that the unlinked field can still be filled in on the category's form.

Deleting a shared field on the Field keys tab affects every category that uses it. If the field has saved values, it is made inactive and the values are preserved. The field is removed from active field selections and from the category's available additional fields. If there are no saved values, the field definition and its category links are deleted. Before deleting a field, also check any workflows that use it.

Save and verify the result

Save the new category using the form's Create new category button. Then reopen it by clicking its name or the pencil icon on its row in the Service request categories table. Changes to an existing category are saved using Save.

In the reopened category, check the fields, their order, and the Required field selections, as well as the roles, default category, and transfer-to-task selection. Create a new test request using the intended user role. Check separately in the browser, on Android, on iOS, and on the public form you use that the category is available, the fields appear in the correct order, and required fields are handled in a way that meets your needs. Test both answers in the yes/no field.

Open the saved test request and check its values, responsible role, and status. If you change an existing category, also check the responsibilities on previous requests whose status is other than Completed. After transferring a request to a task, check the statuses of both the request and the related task separately. For a public test request, also check the confirmation email and whether it includes the communication link.