Choose the workflow action according to whether you want to create new information or change existing information. Also check which Spot, task or service request the action applies to. A creation action creates a new record even if similar information already exists.
Prerequisites
Configuring workflows requires administrator rights and the workflow feature to be activated for your company. Configuration is done in the browser. An event saved on Android or iOS can also start a workflow when it matches the workflow's trigger and conditions. Results are viewed in the usual views for the target records, according to the user's access rights.
Select a trigger and narrow down the information to be processed before configuring the event. For example, a task created from a device observation message must have the correct Spot and responsible party. See creating a workflow and triggers and conditions.
Add and configure an event
- Open Workflow tool from the browser menu. Select Create a new workflow or open an existing workflow using the pencil icon on its row in the table view.
- After configuring the trigger, go to Set conditions and events. Select Add new event in the branch you want.
- Choose an action in the Select the event field and open its form using Set the information.
- Fill in the target form on the left. You can enter fixed values or drag trigger values from the lists on the right into compatible fields.
- Select Save at the end of the event form. The Show the information button opens the saved configuration for review. This saves the event configuration; the workflow is activated separately in the testing and saving step.
Add the event to the branch where it should run. If you need several consecutive actions, a delay or calculated values, see branches, delays and calculations.
Creating new information
Creation actions are under Other events in the Select the event list. Also check the values suggested by the form.
- Create new task: enter the task name and priority, and select a Spot, responsible party and due date or dynamic due date. You can also specify, for example, a task template, task form, category tags, products and recurrence settings. See creating a task and a draft.
- Create draft task: the task is saved with the status In planning. A name and priority are required, but the Spot, responsible party and due date can be left unspecified. Add them before moving the task to open.
- Create a new service request: enter a title and select a priority, status and service request category. Fill in the category's mandatory additional information and, if required, a mandatory Spot. See creating a service request.
- New message: enter the message content and select a message type, priority and Spot. A message is an observation saved for a Spot, so select the correct type and agreed unit for measurement data. See recording a message. To send an email, use the separate Send an email action.
- Create new spot: enter a name and select a folder and status. Fill in the required device card fields. If you enter a purchase price, purchase date or depreciation period, enter all three. See creating a new Spot.
When several Spots are selected as task targets, a separate task is created for each unique Spot. Selecting a folder includes the Spots directly in that folder; it does not itself include Spots in subfolders. The same Spot is processed only once within the target selection of a single creation event.
Updating existing information
The options under Trigger related events depend on the trigger:
- From a task, you can update the task that acted as the trigger, its Spot or its related service request.
- From a service request, you can update that service request or its Spot.
- From a Spot, you can update the Spot that acted as the trigger.
- From a message or read event, you can update its related Spot. A general message update action is not available.
To update separately selected Spots, select Other events → Update another spot. Select the targets using the Select the Spots you want to update button in the event configuration. An update action does not create a missing related target: for example, updating a task's related service request does not give the task a service request if it has no service request link.
Fill in only the fields you want to change. A field left blank in an update retains its previous value. When you specifically want to clear a value, drag Empty from the list on the right into a field that allows it. Mandatory information and the requirements of the target's status also apply to workflows.
Simply clearing a checkbox does not usually change the saved value to false, because unchecked boxes are excluded from the update. Use Empty where allowed, or a compatible dynamic value. Explicitly clearing a service request's yes/no additional information field sets its value to no.
Spot attributes: only attributes already present on the Spot are updated. Missing attributes are not added automatically. Updating a Spot also does not change its folder or tag.
Service request additional information: the field being updated must belong to the request's current service request category. If the request has no value at all for that field, a new value can be saved for it. A normal update does not change the service request category. When placing a request on hold, also enter the reason for the hold on the update form.
Forwarding a service request: the trigger-related Forward action is different from an update. It works for an open request or one in progress, creates a copy in the target category and marks the original as forwarded. Additional information compatible with the target category, attachments and comments are transferred to the copy, and responsibility is determined by the target category. See forwarding a service request and converting it to a task.
Using trigger values
A value dragged from the list on the right is resolved when the event runs. It is not a copy of the trigger information saved at the time of configuration. Information that changes during a delay can therefore affect the result.
Not every value can be used in every field. A date field requires a date, a number field requires a number, and a checkbox requires a yes/no value. In target selections, the identifier must also match the information being selected.
Using the trigger's task template, task form fields, service request category's additional information or folder attributes requires a corresponding, unambiguous restriction in the workflow conditions. If the restriction lacks the required selection or includes several alternatives, not all fields are offered. Fixed values can still be used.
When dragging a field from a repeating task form section, select from the list on the right whether to retrieve the value from The first section or The last section. The default is the first section. Always ask prompts you to choose each time you drag a field during configuration. Changing the selection does not change fields dragged earlier. In long text fields, a task form value may be displayed with the section and field names; number and date fields, Spot attributes and service request additional information use only the value.
Dynamic due date
Dynamic due date on the task event form replaces the fixed due date when the field contains a number of days. The calculation starts from the event's execution date in the service's time zone and sets the due date to the start of the day. The field's help text refers to the trigger time, but after a delay, for example, the calculation uses the later execution date.
A value of 0 means the execution date, a positive number means a future date and a negative number means an earlier date. Use whole days: the decimal part is discarded. If the event runs on 10 October 2026 and the value is 2, the due date will be 12 October 2026 at 00:00. Leaving the field blank disables the dynamic calculation.
Task responsibilities, resourcing and categories
Select a responsible party on the task event form or select Use trigger's responsibility. A task trigger uses its workers, a service request trigger uses its responsible role, and a message trigger uses the message author's user account. If you follow the users of a role, users are selected from the role's members when the event runs. Make sure the trigger has the required responsibility.
When a new responsibility is set in an update, the task's previous workers and their resourcing are removed. Clear responsible also removes previous responsibilities and resourcing. An empty responsibility is allowed only in the planning status, and moving to that status must itself be allowed. If saving the task fails, the update to that task is rolled back to its previous state.
Resourcing is created for new user responsibilities as needed, using the service's default settings. The configured number of days is subtracted from the due date, the start is set to the specified time, and the end is calculated by adding the duration in minutes. Without a due date, the calculation starts from the current time. The service's basic default is a 60-minute allocation starting at 08:00 on the due date, but your company's settings may differ. Responsibility assigned directly to a role does not receive this per-user resourcing.
For example, a due date of 12 October, two days before the due date, a start time of 08:00 and a duration of 90 minutes produce an allocation on 10 October from 08:00 to 09:30. Check the resulting allocations especially when the task was already scheduled.
Setting new category tags replaces the previous tags. Use trigger's category tags copies the task trigger's tags, and Clear category tags removes the current links.
Effects of status changes and other changes
A status update changes how the work is handled and the times saved for it. When you select In progress on the task event form, Select the user for the task and Start recording working hours? appear at the top of the form. A user is required. The start time for recording working hours is set to the execution time unless starting the recording is deselected.
Moving to review sets the completion information. Moving to completed fills in the completion time and the person who completed the task; completing a task from review also saves the reviewer and review time. The available task performer or the workflow's user account is used as the person completing the task, so automatic completion is not necessarily the administrator's personal sign-off.
A workflow does not bypass the task's status rules. Missing or incomplete form sections, mandatory fields and required working hour information can prevent completion. A task requiring review moves to review first. Completion from review requires an internal review comment. A completed task cannot be returned to another status using this update, and a draft cannot be moved directly to completed.
Successful completion can also trigger a check of the service request's status, processing of hourly rules and costs, product stock transactions and creation of the next task in a recurring task sequence. The effects depend on the task's information and settings.
When you select the completed status on the update form, Create PDF and Send report by email appear at the top of the form. A PDF requires a task form and is generated when the task successfully moves to completed, based on either the form's automatic PDF setting or the event's Create PDF selection. Updating a task that is already completed does not generate a new completion report with this action.
Changing the task template or task form can also have consequences: changing the template updates its related products, category tags and signature templates. Changing the form can remove previous form sections. The form cannot be changed on a task that is in progress, in review or completed, and it cannot be removed if the task has completed sections.
Save and verify the result
Use Show the information to check the targets, dynamic values and clearing selections. Continue to Test and save and read the displayed target counts, scheduling and execution options before confirming. Not all selections in the testing step are merely a preview: processing existing information can make real changes. See scheduling and execution history.
After the first execution, open Workflow tool → History and choose the workflow under Select workflow. Check the execution and its steps. Also open the processed targets and verify that the correct information was created or changed: check the fields, status, responsibilities, resourcing, related requests and any reports.
Execution history alone does not guarantee that all updates were saved. Processing several targets is also not one shared change that can be rolled back: some targets may have been saved before an error occurred. Find the cause of the error and check the information already created before trying again, so that a creation action does not create duplicates. Saved changes can also start other active workflows if their triggers and conditions are met.