The trigger determines which event or item's data the workflow processes. Conditions limit the situations in which the workflow continues with its actions. A property condition and the time when the workflow starts are separate choices.
Configure these settings in the browser. You need Spotilla administrator permissions, and the workflow feature must be enabled for your account. Open Workflow Engine from the navigation, then select Create new workflow at the top. In the first step, select Event or Property. The workflow's other basic details are covered in Creating a workflow.
Event or property?
Event is suitable when you want to respond to a specific creation, update, completion or addition of a comment. In the Trigger section of the building stage, select an event from the Select the trigger field and click Accept the conditions and continue.
The available events are:
- Creating, updating and marking a task complete.
- Adding a new completion comment, review comment or task form review comment to a task. These are separate triggers.
- Creating, updating and marking a service request complete, and adding a new completion comment.
- Creating a message.
- Creating and updating a Spot.
- Creating a read event.
For example, creating a new message and editing an existing message are different things: the event selection only includes message creation. Comment triggers apply to adding a new comment, not editing an existing one.
Property is suitable for comparing an item's values, such as a task's status or a Spot's numeric field. In the first step, select Task, Service request, Message or Spot and continue by clicking Next. Conditions for tasks, service requests and messages can also use data from their related Spot.
Selecting a property does not by itself determine when the workflow runs. In the settings before saving, you choose between processing existing items once, processing them regularly, or processing based on future creation and update events. Event-based and regular processing cannot be selected at the same time. Processing items once does not automatically enable processing of future events. See Workflow scheduling and history.
What does a saved event mean?
Event-based processing starts after a creation or update has been saved to the server. Completion submitted in Android and iOS is processed through the same server. A local tap, an unsaved change or a failed save does not yet indicate that the workflow has started.
An update trigger does not mean that every possible change is monitored. For example, updating only a task's PDF report or changing a Spot's default image does not trigger this processing. A property condition checks the value at the time of processing: for example, meeting a status condition does not usually require the status itself to have changed. In event-based processing, another monitored update can cause the same condition to be checked again.
The workflow must be active. Its schedule and daily execution limit can also prevent processing, even when the event or property condition matches.
Completion triggers and completion in the mobile app
Task is marked complete and Service request is marked complete mean that the status changes to Completed. Another update to an item that is already complete does not by itself meet this trigger.
Completing a task in the mobile app requires the user to have permission to mark it complete and to successfully complete the required sections of the task form. A task that requires review first moves to review when completion is submitted. This does not yet meet the completion trigger. Check the task's actual status afterwards; the button's name or a recorded completion time alone is not enough.
Moving to review also does not mean that the completed task form's PDF is available as an attachment to a workflow email. The attachment requirements are described in Workflow branches, delays and calculations.
The item, property and value on a condition row
In the Trigger section of a property-based workflow, select the item for the condition row, the Property, the comparison from the Choose condition field and, if needed, the Value. For a field-specific comparison, also select the Field.
Distinguish the item's own data from its Spot's data. For example, the status under Task and the status under Tasks Spot belong to different items. Select the correct item before selecting the property; similar field names do not guarantee that they refer to the same data.
When comparing a task form field, select a Section if needed. Selecting Any searches for the field in all sections of the form. If there are several matching field records, a match in one record may be enough. This does not mean that the values in all sections meet the condition.
For numeric and date comparisons, you can use a dynamic value instead of a fixed value. Open the small selection icon next to the Value field, whose tooltip is Select dynamic value. Drag a suitable value from the lists on the right of the view that opens into the comparison field, then click Save. Select a value that suits the type of field being compared.
Key differences between comparisons
- Numbers: a decimal comma is treated as a decimal point. For example, 1,5 and 1.5 are the same value in a numeric comparison. An empty field is not zero. A comparison of magnitude does not match if either value is missing. The comparison does not apply separate rounding to match what the client displays.
- Dates: by default, only the date is compared, so different times on the same day are equal. The comparison uses the account's time zone; if none is set, the default is Helsinki. When selecting a dynamic date value, Use also timestamp in comparison, not just date includes the time. Is today means the day on which the workflow runs. Before and after comparisons exclude the same day, and a missing date does not match them.
- Text: Contains text is case-insensitive. However, comparisons such as Is, Is not, Does not contain text and comparisons based on the beginning or end of the text are case-sensitive. This means that Does not contain text is not always the opposite of the case-insensitive contains comparison.
- Selection lists: Is any of these accepts even one match among the selected options. Is none of these requires the value being compared to contain none of the selected options.
- Empty and missing data: use the appropriate Is empty field or Is not empty field comparison. Missing related data generally does not match an ordinary value comparison. As an exception, Is none of these can match when no prohibited related data is found.
and, or and subsequent branches
and adds a new condition to the same group. All conditions in the group must be met. or adds an alternative group: meeting all conditions in one group is enough.
For example, (status Is Completed and priority Is the first selected option) or (status Is Completed and priority Is the second selected option) requires the Completed status in both alternatives. If you add only the priority to the second group, that group can match regardless of the status.
When the trigger conditions are ready, click Accept the conditions and continue at the bottom of the section. After the trigger, you can add a branch to refine the conditions using Add new condition. This additional condition is evaluated only once the workflow reaches this stage. Different subsequent actions can be built into its The condition is true and The condition is false branches.
In a property-based workflow, items that fail the trigger conditions can also be routed to the false branch, if one has been built. This applies both to event-based processing and to processing existing data. Tightening the trigger condition alone therefore does not limit the entire workflow if both branches contain actions. Always check both branches. An event that falls outside the event trigger does not start its false branch.
Test the conditions and verify the result
Proceed from the building stage by clicking Test and create a workflow, or Test and save when editing. Testing a property-based workflow evaluates existing items. The corresponding stage in an event-based workflow does not offer the same item count test.
In the test, distinguish between Number of items the workflow will start for and The number of items affected by the workflow. The first can also include items that fail the trigger conditions if a false branch has been built. The second estimates the items whose path reaches an action. These figures describe the current data, not the number of future events or a guarantee that an individual action will succeed.
Before the final save, also check the selections for processing once and recurrence: saving an active workflow can start actual processing. Actions in the selected branches can, for example, change data, create new items or send email.
After saving, carry out a limited real test with one item that meets the conditions and one that fails them. When testing an event trigger, perform exactly the selected event. Open the History tab in the Workflow Engine view and select the correct workflow in the Select workflow field. Check the execution status and result, and the processed item's data. Also verify that the negative case followed the intended branch or was left unprocessed.