Triggers

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 interval when the workflow will run independently of any change to a particular record. This can be run on repeat at regularly set up by you. A good use case of this is to run a workflow that checks for any overdue action and then sends an email to notify the owner. - Here is a helpful video on this - Automated Expiry Workflow – Softools  

• Trigger on Date: This is for the user to choose a specific date for when the workflow first trigger. This date will become more important if the repeat function is used below. 
• Time Zone: This is simply 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.
• 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)
• User:  Here the user can select it's own user name or someone else who perhaps has importance to this Workflow.

Note: We recommend selecting a user with admin access as the Workflow will run according to that users security, hence if the user only has access to 80/100 records only those 80 records would get triggered. 

• Include Archived Records: If this is toggled the user will have the opportunity to determine that 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: that this 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.

• 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- they have the option between:
  • Hours
  • Days - If selected they can also pick which day of the week they would like to trigger on i.e. only on week days
  • Weeks - If selected they can also pick which days of they month they would like to trigger on i.e. always the 1st day of the month
  • Months

• 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.

Note: 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

Note: 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 Any Change: This event is a combination of all the following Record Events. An example Action for this trigger could be to notify users via a slack channel logging recent record activity in an App.
• Note: This Trigger could generate a high number of workflows if the App is in high usage so be cautious.
• 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.
• Record Updated: This event will be triggered on every save of a record except for it's creation. A typical example would be to email an Action Owner key Field information every time their Action has been updated.
  • Note: Record updated does not include Record created events. If the workflow needs to run on Record creation and Record update you will need to create one workflow for each event trigger. Record updated event can be filtered down further to only act when particular Fields change value by using the Field updated event.

Field Configuration

• 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 Filter

The last layer of filtering is to specify when a workflow will run based on the event happening and also Field criteria being met.

NOTE: A more user friendly way of setting Filters is coming soon, for now entering Filters via string format is supported - See here for information on string Filters.

Make sure to click the 'Save' button when making any changes in order for them to be added to the next app version. Once you have made all the changes you need to an application you are then ready to publish it to workspace.