Workflows Overview

Learn about Workflows

1 About Workflows
2 Benefits
3 Key Terms and Glossary
4 Workflow Template Details
5 Workflow Settings
6 Workflow Actions
7 Workflow Errors
8 Workflow Instances
9 Workflow Audit Logs
10 Creation and Execution Rules
11 Backfilling Workflows
12 Where to find Workflows
13 Workflows Management
14 FAQ’s
15 Additional & supported Reading

Search the Knowledge Base

Supporting Resources

On demand webinar: Troubleshooting Workflows

About Workflows

Workflows are used to automate communications to your customers, your Trainers, and your platform Administrators!

Workflows are highly configurable; you can define the content of your communications, the criteria for them sending when they are sent, and who they are sent to!

Workflows are most commonly used to communicate booking confirmations, joining instructions, course reminders, invoice notifications, and course statistics such as profitability and fill rates.

Benefits

Here are the benefits of using Workflows

Configurable and Customisable

Each of your Workflows can be highly configured!

You define the content of your Workflow Email, the criteria for when your Workflow emails are sent (the rules), who the recipient of the emails should be, and the timing for the emails.

To support your ways of working, Custom Fields can be used within Workflows to trigger events for communications to be sent. Workflows can be custom built to suit the need of its purpose allowing you use a combination of setting and rules to trigger an Email, Task or Note

Automated Communication

The primary purpose of Workflows is to automate communications with your customers and your team! Additionally, Workflows can generate Tasks and record Notes to support collaborative, informed, working across your team.

Reduced risk of human error

As Workflow Emails are automated, you no longer need to manually send emails out, this greatly reduces the chance of human error and provides a more consistent experience for your customers!

Key Terms and Glossary

Settings	Settings are the Rules the instance has to meet before an Email/Task/Note is issued. Here you can use a combination of Rules to send for Specific Courses, Users, Bookers or Trainers
Actions	An Action is what you want the Workflow to do when the rules are met. For example, do you want the Workflow to send an Email, record a Note or generate a Task.
Instances	An Instance is the record created when your Workflow rules are met, an instance will wait until the ‘Action Date’ before it triggers. You can see a list of all instances and when they are created for each Workflow.
Error	If there is an issue with a Workflow then it will show in the errors. This could be an error at the time of execution or the Delegate or Course no longer meets the rules so it will throw an error. Errors can occur for a number of reasons, but the Customer Support Team are here to help if you are unsure on why its happening.
Matching Rules	Matching rules means that when the the Instance is created the same rules should apply when the Instance is executed, most Workflows are set up with Matching Rules.
Creation vs Execution	Creation rules are the rules that create the instance, in most cases the same rules have to apply when the instance is executed however, the execution rules can be different if required.
Advanced Rules	The advanced approach has the benefit of you being able to group your filters together and use the operator of 'or', as standard Workflows will trigger based on all of your rules being met, in the example above the Workflow will trigger when the delegate's status has changed and their status is now 'No Attend'. With Advanced Rules you can set up rules such as course start date is 'in the past' or course status is 'cancelled'.
Action Date	The Action Date is where you define when your action will trigger, for example if you would like reminder emails to send 5 days before the Course, you would set your Action Date as: 5 - Days - Before - Start Date
Send on Action Date Only	This option allows you to prevent your Workflow from generating if the action date has already passed, such as preventing a 7 day course reminder email from sending to people booked onto a course 5 days before the Course.
Consolidate Emails	Consolidated emails are generated when a recipient was due to receive more than one email for the same Workflow Action. Instead of receiving multiple emails, they can instead receive a single, consolidated email, this means that you can communicate more efficiently with your customers and your team!

Workflow Template Details

The first step of adding a new Workflow is Details. Here you will give your Workflow a name and a description, and select which accessplanit ‘Module’ your Workflow relates to.

The following settings are available on the Workflow Template Details page

Title	This is the name of your Workflow. We recommend that you stick to a naming convention for all of your Workflow Templates, as this will make it easier in the long run to search through your Workflow Templates. A popular format for Workflow Template titles is 'Recipient Type - Name of Communication', so for example 'Delegate - Booking Confirmation', or 'Administrators - Course Date Statistics'.
Module	The module is very important as it indicates where you will be getting your information from for your Workflow Actions and what will cause your Workflow to trigger. The module determines what information you can pull through from the platform, what rules you can apply to the Workflow, and who can receive Workflow Actions. For example if you wish to automatically send an email when a Delegate completes a Course, you will need to use the Delegate module to have access include to Delegate information in your email, and define your Workflow Email to send when the Delegate’s status is ‘Completed’. There are a lot of possible modules for you to include in your Workflows. If you would like to know which modules are available and which one you should use, please see our Module guide.
Trigger Event	Your Workflow Template can either be generated based on a 'Save' event or a 'Delete' event. The majority of Workflow Templates are generated when an object is saved, so if you're unsure opt for the 'Save' option. The Save option covers scenarios where you want to trigger an email based on a creation in the platform (such as a new Booking), and an update in the platform (such as a Delegate status change), and any timed emails (such as a Course reminder). The Delete option covers the deletion of objects only, for example a User or Course is deleted.
Description	The description field is optional and allows you to add some further information about what your Workflow Template is for, and when your Workflow Template will send. We recommend adding in a description which describes what your Workflow does, for example: “An email is sent to the Booker 5 minutes after their booking with their booking confirmation” “An email is sent to the Delegate 7 days and 1 day before the Course with the joining instructions” “A task is generated for the Course Administrator to book the trainer’s travel”

Workflow Settings

Once you have completed the Details for you Workflow you will move onto the Settings page.

The settings are where you set the criteria for your Workflow triggering, you can have multiple rules on each Workflow, and there may be some Workflows where you add no rules.

Using Rules
There are two types of ways that you can apply rules to your Workflow Template. You can either take the standard approach and use the drop-down boxes to define your rule, or you can opt for the Advanced approach and type out your rule. We recommend that you stick to the standard approach until you are really confident with the Workflow Template options available in the platform.

Standard:

Advanced:

You can toggle the Advanced Rules tick box to display your Workflow Template rules in the Advanced approach.

The advanced approach has the benefit of you being able to group your filters together and use the operator of 'or', as standard Workflows will trigger based on all of your rules being met, in the example above the Workflow will trigger when the delegate's status has changed and their status is now 'No Attend'. With Advanced Rules you can set up rules such as course start date is 'in the past' or course status is 'cancelled'.

To use an 'or', simply use a double pipe separator || instead of a double ampersand && in the rule.

Common Rules
The rules available to you are dependent on the module that you have selected. For example, if you have selected the Invoice module you'll be able to apply a rule to your Workflow Template to only send when the Invoice is outstanding, but you wouldn't be able to apply a rule to this Workflow Template to only send when the Delegate is booked as this information isn't stored against the Invoice.

Delegate Status Rules
These are the most common rules used within Workflow Templates. They are used on Workflow Templates that communicate to Delegates and their managers when their status on a course date has been updated (i.e. when a Delegate is marked as cancelled, or when a Delegate is marked as completed).
There are two rules used, one to ensure the Workflow Template only sends when the status has been changed, and another to indicate which status it has been changed to. You can use these rules using the User Course Date modules, such as User Course Date Class.
Course Status Rule
Course status is often used within delegate cancellation Workflow Templates, as the communication that is sent when a delegate is cancelled is very different to the communication that is sent when the course is cancelled. In both scenarios the Delegate is given the status of cancelled, however the course status rule allows you to define which communication they receive. These would be rules used in a User Course Date Workflow Template if the delegate had cancelled, but the course was still running:

You would also use the status of a course as a rule within your admin communications such as Course Stats, as you wouldn't want your Administrators to receive notifications about courses which are cancelled or on hold, here is an example using the Course Date module:
You can use this rule using the User Course Date module, and the Course Date module.

Sessional Delegate Rule
If you use sessional courses you may be interested in using the 'Is Session Delegate' field from the User Course Date modules in your rules. This allows you to define whether a delegate receives or does not receive the communication if their place is on a session.
When a Delegate is booked onto a sessional course, they are actually being booked onto many courses in one, they will be booked onto the parent course, and any subsequent child courses (sessions), so if for example you have a booking confirmation Workflow which does not filter out 'session candidates', they will receive a booking confirmation email for the parent course, and additional booking confirmation emails for each session, which might be a little over the top! To filter out 'session candidates', use this rule:
This will stop the Delegate receiving booking confirmations for each session they are booked onto, but they would still receive it for the parent course.
This rule only stops your Workflow from sending when the delegate is booked through a sessions plan, if a Delegate is directly booked onto a single session (without the parent course), or if a Delegate is booked onto a standard, non-sessional course, the Workflow will still send.

Communicating with Trainers Rule
Trainers and Delegates are both stored within the User Course Date modules, therefore you will use these modules when communicating with both in your Workflow Templates. With Delegate communications you do not typically need to have a rule to say 'only send to Delegates', as having a Delegate status rule in place (see above) ensures the communication only sends to Delegates.
However for Trainer communications you'll need to apply the following rule:
Using Advanced Rules
Above the list of rules within the Settings page you will see an ‘Advanced Rules’ tick box, ticking this will change your list of rules into an advanced rule format in one line. This does look much more complicated. You can do even more with the advanced rules such as:
1. OR instead of AND
If you would like to filter your communications based on one rule OR another rule, instead of one rule AND another rule, you can convert to the advanced rule format and change the && text into ||

Workflow Actions

Once you have defined the criteria for your Workflow sending by applied rules, you can move onto adding your Workflow Actions.

Workflow Actions are the output of the Workflow, this may be an email, or a task, or a note. Within the Workflow Action you will decide when it triggers and who to.

Please see our dedicated guides for adding Workflow Actions to your Workflow

Once you have built your Workflow Actions, you are ready to test your Workflow and then turn it on using the ‘Active’ checkbox on the Details page.

Workflow Errors

The Workflow Errors page lists the occasions where a Workflow has not triggered.

The Workflow Errors page is very useful for troubleshooting Workflow issues, from this page you can find out why a Workflow did not trigger, for example if the recipient was missing an email address, if the Workflow Rules had not been met, or if information is missing from your Workflow.

Within the Workflow's Settings page you can enable full logs to make the most of the Workflow Errors, with the full logs an Error will be recorded every time an update in your platform (within your Workflow’s module) fails your Workflows rules. This can be very useful for finding out which Workflow rules need correcting. For example, if you have a Workflow with the rule 'Delegates Status = Cancelled”, then there will be a Workflow Error raised for every Delegate that is assigned a status other than Cancelled.

Workflow Instances

The Workflow Instances page lists all all of the Instances where your Workflow Rules have been met and your Workflow has triggered or is ready to trigger!

The Workflow Instances page is where you can view when your Workflow has and hasn’t yet triggered, from this page you can also trigger your Workflow early and retrigger your Workflow if it needs to send again!

To see if your Workflow Instance has triggered yet, right click on the Workflow Instance and select the ‘Actions’ option from the context menu.

You will then be able to see each of the Actions for this Workflow, and their status.

The following information is available from the Workflow Instance Actions DataGrid:

Action Date	This is the date and time that the Action is due to trigger, for Email Actions this would be the date and time that the email is due to send.

Action Date

This is the date and time that the Action is due to trigger, for Email Actions this would be the date and time that the email is due to send.

Date Completed

This is the date and time that the Action did trigger, for Email Actions this would be the date and time that the email did send.

Please note that there may be times where the Action Date is different to the Date Completed, such as if the date of a Course changes which affects the date a Workflow email is due to send.

Status

This is the status of the Workflow Instance Action

Active = this Action is waiting to trigger
Completed = this Action has been triggered
Failed = this Action has tried to trigger but it has been unsuccessful
Object Deleted = this Action will not trigger as the object it relates to has been deleted

Error Message

This is the reason why a Workflow Instance Action has failed

Please note, if the Recipient on a Workflow Action changes before the Action Date, the email will be sent to the updated Recipient.

Workflow Audit Logs

The Workflow Audit Logs allow you to see any changes made to the Workflow.

The Audit Logs on a Workflow are very handy for identifying when changes are made to your Workflow.

The following are tracked in the Workflow Audit Logs:

Workflows being set to ‘Active’
Workflows being set to ‘Inactive’
Updates to the Workflow Rules
Updates to the Workflow Title

Audit Logs include the date and time that the update occurred, and which User made the change.

Please note, changes to Workflow Actions (such as an update to the recipient of a Workflow Email) are tracked in the Workflow Action Audit Logs.

Creation and Execution Rules

Creation Rules
A creation rule is processed when a record of the type selected in Module is updated/deleted, depending on your selected Trigger Type.

Creation rules can include checks on whether a field’s value has changed. This is because at that moment in time we have the original value for that field, and the current/updated value if it has changed.

It’s important to note that using the Trigger Type of “Saved” means the creation rules will be checked the moment any record of the relevant type is updated. This may well be caused by background processes in the platform that recalculate dynamic fields, such as Communications Count in the User Course Date module, which is updated every time a new communication for that record is created.

As a result of this, it is recommended that your creation rules include at least one “Has Changed” check, such as “Status has changed” on the User Course Date module, so a Workflow instance is only created if you have actively made a key change to the record. Without this check, an update of the record by a background process may cause a Workflow instance to be created if that record matches all the other defined creation rules, even for records in the past.

Worked example

As a worked example, consider the following User Course Date Workflow:

Workflow Name: Delegate booking confirmation

Creation Rules: 1. Status = “Booked”

Course = “Course A”

If a new Delegate was booked onto “Course A”, they would satisfy all these rules and a new Workflow Instance would be created.

Unfortunately, if an existing Delegate of “Course A” with the status of “Booked” is updated for any reason other than to change their status to a different value, they would also create a Workflow Instance, even if the Workflow was created after that record was first created.

Worked example - alternative approach

The creation rules can be modified slightly to only create a Workflow instance when a new delegate record is created (under normal circumstances):

Workflow Name: Delegate booking confirmation

Creation Rules:

Status has changed
Status = “Booked”
Course = “Course A”

The addition of the “Status has changed” rule means that when a new delegate record is created, and its status changes from effectively “nothing” to “Booked” (as they didn’t previously exist), that rule is satisfied and the rest of the rules can be checked.

If an existing delegate of “Course A” with the status of “Booked” is simply updated, their status has not changed and no new Workflow instance will be created.

The only time where this won’t work is if a User is for some reason changed from another status, to “Booked”. As the status has changed and the rest of the rules now match, a Workflow instance will be created. It is unlikely this would be a problem in normal operation, as the User has indeed been changed to “Booked”, so a booking confirmation would be appropriate.

Execution Rules
Execution rules are fundamentally the same thing as creation rules, but this time they are checked when a Workflow instance’s “Action Date” value is in the past.

The key difference with execution rules is that we can’t check if any values in the record have changed, as the update has been completed either a few seconds or potentially many days in the past.

Execution rules are most important when building Workflows that won’t be executed until sometime in the future, where the record’s values may have changed in some significant way between the Workflow instance’s creation and when the actions of that Workflow are due to execute.

Using the Matching Rules option will automatically ignore any “has changed” rules when processing execution rules.

Worked example

A good example of when execution rules are important would be setting up a pre-course reminder:

Workflow Name: Delegate pre-course reminder

Creation Rules:

Status has changed
Status = “Booked”
Course = “Course A”

Execution Rules:

Status = “Booked”
Course = “Course A”

Matching Rules: On

Action Date: 1 day before course start date

The creation rules for this Workflow are the same as the example in the Creation Rules section, as we know we want to send a pre-course reminder to any Delegates that book onto “Course A”.

The execution rules become important in this Workflow, as we only want to send a pre-course reminder to Delegates that are still marked as “Booked” when we reach the action date. In this case, that is one day before the course is due to start.

We set up the execution rules this way because between the time of the Delegate being created and one day before the course is due to start, they may well have cancelled or been transferred to another course. In this event we don’t want to send them a pre-course reminder for a course they’re not going to attend, and the execution rules prevent us from doing that by checking the Delegate’s status before we perform any actions.

Warning: If you opt to use Advanced Rules, the “has changed” rules will not be automatically be removed from the execution rules if you include them in your core rules and choose Matching Rules, or explicitly define them in the Execution Rules option.
A Workflow set up in this way will always fail.

Backfilling Workflows

As Workflows only send for events that were made after the Workflow was turned on, the Backfill Instances option allows you to force accessplanit to send the Workflow for events prior to the Workflow being created.

Backfilling instances can send out past emails that may not be applicable now, therefore we recommend adding in a date-based rule (eg. Course Start Date > Period > Future) to the Workflow before performing a Backfill to ensure that no unwanted emails are sent out.

Furthermore, you need to remove any rules relating to status changes (e.g. Course Status > Has Changed) as this will exclude a lot of the objects you would want to be included by the backfill.

Please get in touch with a member of the accessplanit support team if you would like any support with completing a Backfill on your Workflow.

Where to find Workflows

Open the ‘Administration’ menu from the Profile options at the top-right of your platform
Open the ‘Workflows’ menu option to access the page where you can create and manage your Workflows

Workflows Management

Learn how to create and manage Workflows in your platform:

Planning & Building Your Workflows

Workflow Templates

Workflows with SMS Actions

Workflow with Task Actions

Workflows with Note Actions

Workflows with Email Actions

Consolidate Emails

Consolidate Workflow Email Actions - Courses

Example Consolidate Email Content - Delegates

Consolidate Workflow Email Actions - Delegates

FAQ’s

There are a number of reasons why a Workflow may not have triggered, we always advise you to check every setting against the instance you are trying to create. Ensure that all the rules are met first as usually the rules not being met is the main cause for the Workflow not triggering.
If you are still struggling to work out why it hasn't triggered, please reach out to one of the Customer Support Team who will be able to assist you with this

If you are unsure of the error, please send a screenshot of the error to one of our Customer Support Team and they will be able to assist with an explanation for the error

Sometimes, it can be really obvious based on its content and subject line which Workflow the Communication has come from, however, if you have multiple versions of a Communication, for example, a Booking Confirmation for a Class Course, one for a Web and so on it can become a little trickier to work out which communication is from which Workflow. IF you are unsure, reach out to one of our Customer Support Team who will be able to provide further support with this.