Overview
The Trigger in a Workflow is the event that needs to happen for the Workflow to run. Several additional filters can be applied to further specify when exactly the workflow will run.
On the left panel, you'll see a list of trigger nodes. To begin your workflow, either drag a trigger node into the workspace or click on the empty node.
When you drop a node onto the workspace, the edit node window appears, allowing you to specify whether this trigger can be triggered only by a specific team or user. Additionally, you can include notes.
Scheduled Job
This allows you to state a fixed time or fixed time intervals at regular times and dates when the workflow will run, independently of any direct change to a particular record. A good use case of this is to run a workflow that checks for any overdue Inspections in an Audit App or Actions in a RAID App and then sends an email to notify a call to action to complete them - Here is a helpful video on this - Automated Expiry Workflow – Softools
Date & Time of First Run
This is the date and time in local time zone that the first workflow will run. It may then run periodically depending if the Repeat property is set as explained later in this article
Enabled: This workflow will only trigger when the Enabled checkbox is checked. If you disable a schedule trigger that was scheduled to run, then re-enable it later, the job will run immediately (since it's now overdue). To prevent this, update the scheduled date and time to a future time before re-enabling the workflow.
Time Zone: This is a list with all the different time zones, if you are outside of the London time zone you will need to make sure this is set to your relevant time zone. Note that the time-zones will also account for Daylight Saving Time (DST) for a time-zone. So if a workflow is set to run based on a London location 9am GMT then it will still run at 9am BST (instead of the relative 8am BST based on GMT)
Trigger on Date: This is for the user to choose a specific date for when the workflow first trigger. It could be that it only runs on this date or that this is the start date for a repeat intervals of the workflow running.
Trigger at time: This is were the user can select the exact time in hours and minutes at which the workflow will run. (The hours and minutes will correspond to the selected time zone, so if the time zone chosen is +09 Japan Time at 10:00. This means that the workflow will run when it's 10AM in Japan)
Note: If the date set for the workflow to run is set in the past and the node set to enabled then this will assume there is a run needed and the workflow will be triggered on Publish. Make sure to set the date in the future if you would not like the workflow to run on Publish.
Behaviour of Records Triggered
Which Records and the context of how they will be triggered is important. Based on the User selected, inclusion of archived records and batch size will effect the coverage of the Records triggered and actioned against.
User: An App builder can select their own user name or someone else who perhaps has higher privileges to the Records in the App to run the workflow nodes against. We recommend selecting a user with editable access to all Records in the App as the Workflow will run according to that users security, hence if the user only has access to certain Records then you will need to be careful to check the ignore access property on subsequent filters and actions or Records could be missed in the workflow run.
Include Archived Records: If this is toggled then Records which have been archived are also included when the Workflow triggers.
Batch Size: This number box states that the Workflow runs in batches, therefore if number is at 100, it will operate in a batch of 100 records, so if there are more than 100 records, like 156. It will run twice as it would do it in two different batches.
Note: Batch Size could present certain changes in actions, for instance, if the action is to send a combined email as the Workflow in this case only takes batches of 100, however, if there are 156 records it will send two emails. It will not present any issue when the actions are per Record and not a combined Action across multiple records.
Repeat
If the user toggles this option they will then be able to choose when and how often they would like this workflow to run.
Periodically run workflow can be set at time intervals of:
Hours - The workflow will run every 'x' hour intervals from the initial workflow time. If the Start was 10am then running every 4 hours would next run at 2pm, then 6pm, then 10pm, ..
Days - The workflow will run every 'x' day intervals. If you want to be more specific and run the workflow on particular days then use the weeks interval and select the days you would like the workflow to trigger.
Weeks - This allows us to state how many weeks between runs as well as which days on those weeks the workflow will be triggered. Say we would like it to run every other week from 14th August 2025 on Monday and Wednesday at 3pm London time. This would be configured as follows:
Months - Similar to weeks, months is how many months apart the workflow will run and on which days. The time the workflow will run on those days will be taken as the time the first workflow was set to run.
In our use case of checking for overdue inspections, we will use the months option with particular days selected. We know that Inspections are run monthly with a deadline of the 6th of each Month. Therefore we will set the workflow to check on the 10th and then 15th of each month. Any overdue inspections past this date will be marked as missed and then the process repeats each month.
If you wanted to schedule a Workflow for the last day of every month, it needs to first trigger on a month with 31days.
In the case where the first or second upcoming Months do not have 31days, you would need to set up one or two, one-time scheduled jobs, with a separate repeat one firing for the first time on the month that has 31 days.
Run Scheduled Workflow(s) Immediately
This feature allows you to run the scheduled job workflow you are currently in straight away so you don't have to wait for the set time on the node to test it. This will run for all records that apply to the filter if there is one.
This will run the latest published version of the workflow so if you make a change you want to test make sure to publish it. It will also need to be set to Enabled to run. If you set the set in the past and publish it will run the workflow straight away - if you wish to create the workflow but you would like it to be inactive then set if several years in the future
Started by Workflow
This is used to action a workflow that is triggered in a different application. A great example of this is where you may want to trigger a workflow asking for updates on a group of decisions that previously you would have had to go into each record and trigger, where now you can trigger all of those emails from the parent record they are linked to. For a video on this please click here.
Note: The apps do not need to be linked to trigger the workflows
Trigger Identifier: This is what you would like to title the action, when looking up this workflow to trigger in the Start Workflow Node this is what you will use to identify this workflow chain.
Source App: This is the source app you expect to get the trigger from so when using the [Source.FieldID] function it knows where to pull the data from.
Ignore Access Rights: Select this if you want to ignore the record security set on the records. If you expect the person triggering this won't have access to the records you want the action to trigger on then you would want to select this.
Simple Triggers
The remaining trigger options listed below follow the same configuration system, so for a more in-depth explanation of the functionality of these please head to the bottom of this article under the 'Field Configuration' headline.
- Button Clicked: This allows you to assign a workflow to an action field, this means when the button is clicked in workspace it will then trigger the workflow. This can be useful for sending out updates and reports in a single click on the record. For further information regarding Action fields please click here.
- Child Record Created: This event will be triggered by a Child Record on it's creation. This workflow could be to set Full Access to a Risk Owner on a Risk Record when it is created as a Child of a Project.
- Child Record Link Added: This event will be triggered from a Child record when it has been linked to a Parent. It could be to show a Form on a Child Question that contains metadata passed down from the Parent Audit when the Question is linked.
- Comment Added: Comment added will trigger a workflow when a user adds a comment to a record via the Comments icon in the bottom right of the screen. This could generate a notification to a Financial Lead that a comment has been added to a Monthly Financial Record.
- Field Updated: This event will only trigger the workflow when the value of a given Field(s) is changed to meet the Trigger App Filter Criteria. An example for use of this event would be to archive a Project if the Status changes to Unapproved. The trigger app Filter would be Status equals Unapproved and the Action could be to Archive the Record. Then, if the status value is updated and is now Unapproved the Project will be archived.
- Record Archived & Record Un-Archived: This will trigger an Action when a Record is archived or unarchived. A use case here could be to hide forms containing detailed WorkPlan information when a WorkPlan is archived and then show the forms again when the WorkPlan is unarchived.
- Record Copied: This event will trigger on a Record when it is copied. This could be used to lock down record access on monthly Financial records. When a month is copied via template copy to start the new month, the month that it was copied from has an action on it to set Read-Only access to the current Users team, preventing users in that team from making updates.
- Record Created: This will run a workflow on the creation of a new record. An example Action for this trigger could be that when creating a new Audit it copy and links a set of Child Questions to the Audit from a master list of Questions.
- Record Linked to Parent: This will trigger a workflow from a Parent record when a Child record has been linked to it. It could be used to send out an email with Summary Financial information for a Project every time a Child Resource is added.
- Note: This workflow should be used in Apps where few child records are added over time. Otherwise it will generate a number of workflows if multiple child records are added in quick succession.
Trigger User & Team Restrictions
- Enacted By Specific Team: You can filter down when the workflow will run to specific Teams. If you only want the workflow to run when Users in a specific Team meet the event criteria then select this team. You can select multiple teams more easily by using the arrow keys and hitting enter to select.
- Enacted By Specific User: Similar to choosing specific teams, you can also select specific users. Select which Users will trigger the workflow when the event is met here.
- Note: If specific Teams and Users have been selected then it will run if either the user is selected or the user is a member of a team selected. If no specific teams or users have been selected then the workflow can be triggered by all Users.
- Notes: Notes is a really useful area for new app builders or collaborating app builders, this allows you to note down what the purpose of each node is used for to help yourself if you make changes down the line or for other app builders who work on the app and need some context
Trigger Filters
An additional layer of restricting which Records workflow will run for is to specify a filter based on Field criteria being met. For this we add a Filter Node into the flow.
- In order to add a filter node you must already have added a Trigger.
- Click on the filter tab from the node selection panel to the left of the workflow map
- Drag a new filter node onto one of the existing nodes in the map
- Alternatively click the + on the end of an exiting node in the map and select filter as the node type.
Workflow beyond the new filter node will only apply to records that match the filter criteria set in this node.
Then the records for the workflow to run on can be filtered down based on a number of different criteria. For our understanding of each property, we will look at the use case of filtering down Records in an Inspection App based on them being overdue.
Filter
First we set an NCalc expression which is criteria that the Field values need to match. For our scenario of finding overdue inspection we would use:
[InspectionStatus] <> 'Closed' && dateNow() > [InspectionDate]The first part of the expression filters to Records that are not 'Closed'. We then combine this with another criteria using the '&&' to mean and. Finally we put in a second criteria utilising the dateNow() function to check for open inspections that should have been completed before today's date.
Sort Order, Sort Field & Limit to first N results
Adding a sort order and limiting the number of Records that further actions will run against can prevent the sort of flows that can result in high volume of unnecessary workflow activity. Our use case of finding overdue Inspections is valid but let's suppose that the purpose is only to chase the Auditors to complete their Inspections. In this scenario it could be sufficient to just flag once via an email if there are any open inspections overdue.
To do this we Sort the Inspections by Inspection Date ascending and then just take the first Record. We can then add a send email action which will alert Users that there is an overdue inspection and in that email ask them to check for any more inspections that are overdue. This is lighter as it still functions to alert the Auditors there are overdue inspections but does not spam their inbox if there are multiple inspections that need to be caught up on.
Ignore Access
Ignore Access is for scenarios where a User may not have access to the Records that the workflow needs to run across. This is when the Trigger is set to Scheduled Job and so it will initially be running across all Records. With the filter node applied it would then only run on the records assuming the filter is applied by the User named in the Scheduled Job workflow trigger. Ignoring this and running the filter against the full collection of Records may be required.
Applying this to our use case of sending an alert if there is an overdue Inspection, it may be that we have chosen he schedule trigger to run for an Admin User but they do not have access to Confidential Inspections. We would need to tick the Ignore Access to send an alert in the scenario where the overdue Inspections are all in the Confidential category. Not setting this property would mean that the filter does not return the Confidential Inspections that are overdue to then be factored into further workflow nodes.
Comments
0 comments
Article is closed for comments.