Workflows Overview

Search for a solution

Page Contents


Related Helpguide Pages:

  1. https://accessplanit.atlassian.net/wiki/spaces/HG/pages/163741758

  2. https://accessplanit.atlassian.net/wiki/spaces/HG/pages/83427376

  3. Workflows Video Tutorial - Download

Workflow 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 send, and who they send 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.


Where to find Workflows

Follow these steps to view and manage your platform’s Workflows.

  1. Click on the Profile option at the top right of your platform

  2. Select Administration

     

  3. Scroll down, and click on the menu option Workflow Templates


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 in 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

 

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

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

  1. Workflows with Email Actions

  2. Workflows with Note Actions

  3. Workflows with Task Actions

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

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

 


 

Workflow Audit Logs

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:

  1. Workflows being set to ‘Active’

  2. Workflows being set to ‘Inactive’

  3. Updates to the Workflow Rules

  4. Updates to the Workflow Title

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


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”

  1. 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:                   

  1. Status has changed

  2. Status = “Booked”

  3. 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:                   

  1. Status has changed

  2. Status = “Booked”

  3. Course = “Course A”

 

Execution Rules:                

  1. Status = “Booked”

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

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.