When designing workflows in Automation—whether you're updating existing ones or creating them from scratch—there are a few key aspects of the system that are helpful to understand.
Good to know when designing workflows
When it comes to designing workflows, there are just a few things to keep in mind to ensure that the workflow works to the expected outcome.
Chosen Learning Experience
When creating the workflow, typically a Learning Experience would need to be chosen (depending on what the trigger is of course). So for example:
The trigger has been chosen and the LX has also been chosen, now to ensure that the workflow works as expected it is best practice to ensure that the same LX is chosen as the workflow is built out. This comes into practice especially when you are checking for completions.
From the above set up, it is evident that the workflow chosen for the trigger does not match the workflow that Automation is checking for completion for. This can possible cause incorrect Emails, Slack or Teams messages from being sent to users, this is because the user may be enrolled onto the first LX but may not exactly be enrolled onto the second LX. In this case, if the user had actually completed the first LX, they would receive an email stating that they had not completed the LX.
Important Note:
The above is particularly important when you are copying workflows. It might be the case that you have a template that is copied each time a workflow is required, therefore the above is important for getting it right.
Variable Placement within Outputs
This comes into focus a lot more when you want Automation to fetch information from the LRS and bring it into Automation and action it according to the requirements in Automation. For example, if the 'Get Completion Status' workflow item was used:
You would create Custom Variables and use the variables created here to store information collected from the LRS. Where these variables are placed will depend on what you place in your next workflow item, such as the 'Condition' workflow item.
If you are unsure of where to place the variable, you can hover over the question mark icon which will show you example data that would be stored within that output:
If it was to be the case that your Get Course Completion and Condition workflow looked like the below:
The value in the Condition workflow is not matching the possible values in the output section of the get completion status workflow item therefore this can cause issues with the path in which users are taking. Therefore, ensuring these are set up correctly is important. The value needs to match what is possibly being stored within the output, in this instance:
- If your custom variable is stored in the 'Status' then the value in the Condition would be completed.
- If your custom variable is stored in the 'Success' then the value in the Condition would be true.
- If your custom variable is stored in the 'Completion' then the value in the Condition would be true.
Lowercase lettering
When it comes to the condition workflow item, it is important that the value is in lowercase lettering. Placing an uppercase letter (Completed rather than completed), again, will cause issues within the workflow which is something that can be avoided.
Good to know when making changes to an Active Workflow
From time to time there will be the requirement to make changes to a Workflow that is already active, it is important to consider a few key points when doing this.
Changing the Alias of the LX
When an LX is created it is automatically given an alias (typically the name of the LX with spacing replaced with ampersands and in lowercase letters). The alias is important when it comes to Automation, especially with the trigger.
What is an Alias?
As mentioned above, this is typically automatically applied when creating an LX in the LXP. However, it can viewed within the LX settings itself
What is there to know?
The alias is what is appended to the xAPI statement when a user enrols or completes an LX (it does also appear in every statement to do with the LX). However, for Automation if the alias is changed within the LXP and that LX is attached to a workflow within Automation then it could stop jobs from being created (on the basis that the trigger is 'When a user enrols on a LX').
When a workflow it made active, it locks in the settings at that time so therefore the alias of the LX at the time in which the workflow was activated. If it was the case that the alias is changed after the activation then no further jobs may be created because the xAPI statements in the LRS would be different and not want Automation is expecting.
What to do if this happens
If it is the case that this happens, then the LX itself within the workflow will need to be refreshed in order to pull in an up to date list of Learning Experiences from the LXP. This can be done via the refresh button beside where you choose the Learning Experience name:
Next steps would be to click on 'update' within the workflow item and then the workflow will need to be activated again therefore pushing it to a new version.
Making changes to workflow items within an active workflow
There may be instances where changes need to be made such as correction to a spelling mistake within an Email workflow item or the value within the condition workflow item is incorrect.
The main thing to consider here is the jobs that are currently in progress within the workflow. When a workflow is activated, it will automatically update to be Version 1 of the workflow. What this means then is that the users who then meet the trigger and have a job created within the workflow is locked into version 1 and the settings within the workflow items at that time.
If it is the case that changes need to be made to the workflow, then once the update button has been clicked there will be an asterisk sign where the workflow title is at the top:
At this stage, your changes have not been saved and any new jobs created after the fact will remain on the previous version. You will need to click the activate button again and this will push the workflow to the new version:
At this stage only jobs created after the above has been clicked will be placed onto Version 2 of the job, any jobs created on Version 1 will remain on Version 1 and the settings set at that time of activation.
You can view the Jobs tab within the workflow to view the version that the users are on: