Note: Neither test features is available for workflows using a Shopify trigger. This is because the Shopify integration does not use xAPI statements.
There are two ways of testing your workflow, both of which are accessed by clicking Test in the top right of your screen:
Quick test asks you to supply an email address and to decide how conditions should respond. This is useful for quickly simulating what your workflow would do in a certain situation.
Full test requires an xAPI statement to be pasted into it and will run the entire workflow as if this xAPI statement has just been received by Learning Locker. This is useful if you want to fully test every aspect of your workflow, how it will behave for a specific user, and whether your conditions are operating as expected, but it does require you to have access to Learning Locker and a standard knowledge of it.
How to run a quick test
Click Test and Quick test:
You'll be prompted to select true or false for each condition in your workflow:
This will dictate whether the simulated user in the workflow will go down the true or false branch of the condition. Once you've done this for every condition, click Complete test in the top right.
You'll then be prompted to enter an email and full name. Emails will actually be sent to this address if there are send email items in your workflow. Once the test has completed, you'll see each item in the workflow highlighted in green (to indicate that it successfully completed its task), highlighted in red (to indicate that the item failed) or greyed out (to indicate that the item wasn't reached either due to a prior error or because it was on a condition branch that wasn't followed):
You can click Variables in the top right to view how your variables have been populated and adjusted. This can be very useful when determining why a workflow has or hasn't worked as expected:
If the workflow is still processing when you reach this screen, you can click Refresh to update the screen:
When you're done, click Return to workflow on the left:
How to run a full test
Click Test and Full test:
You will be prompted to paste an xAPI statement into the box below.
Finding the xAPI Statement
xAPI statements can be used in order to get a full picture of how the Automation workflow will act when real data is put through the workflow. Using the full test option allows the proper testing of the workflow and how the workflow items added will act with the data that is put through them. The most important workflow items being 'Get Completion Status' & 'Condition'.
To get an xAPI statement, Learning Locker will need to be used as this is where the xAPI statements sent from the LXP (or other hosting Platform are stored). The statement used to trigger the workflow must exactly match the trigger condition.
For example:
If the trigger of the workflow is 'When a user enrols on an LX', then in the LRS that would translate to 'When a user joins an LX' - there is a small difference in the naming convention here (enrols = joins).
If the trigger looks like this:
Then the statement within the LRS should look like this:
Structure of the LRS query
When building the query, it will be a simple query that will incorporate the following elements of the Query Builder in the LRS:
- Who - Because this is a test, this might be the person who has been testing the LX on the LXP
- Did - Matching the trigger within Automation so this could be 'completed' or 'joined'
- What - What was it that the user did? This could be completing an LX or being enrolled onto an LX.
Important Note:
When constructing your query, there might be the case that duplicate statements are possibly been seen, an example can be see below:
Each of the above are not duplicates they represent different activities within the LX itself. These can include: Resource, Object & Level as well as the overall Course and Learning Experience. If all of these have been named the same then it will look like duplicates (there is no issue naming resources, levels & objects the same within the LXP).
To know which Activity to choose from the above screenshot, you can hover over each of them and an ID will appear:
With each of the activities, there will always be the URL of the LXP site that the statement has come from. The example about represents the object that is within the LX (contains home#object plus the ID of the object.
So when looking for the Activity ID and looking for the trigger, there may be the case that the ID's will show as the below:
Learning Experience -
https://learningplatform.streamlxp.com/learning-experience/124782
Course -
https://learningplatform.streamlxp.com/courses/customer-care
Level -
https://learningplatform.streamlxp.com/courses/customer-care/learn#level/240923
Object -
https://learningplatform.streamlxp.com/courses/customer-care/home#object/251251
Resource -
https://learingplatform.streamlxp.com/xapi/activity/resource/553868
* The above URL will be replaced by the URL of your LXP site.
Finding the statement to match Automation
When it comes to testing Automation using the full test, as stated before the exact statement that matches the trigger needs to be found in order to successfully test the workflow. If the incorrect statement is found, Automation will throw an error message:
So again, finding the correct statement will mean being able to successfully test the workflow. It will again compromise as looking at the workflow trigger and finding the statement that matches.
In the example above, the trigger was 'When a user enrols on a LX', so in the LRS that translates to 'When a user (Who) joins (Did) an LX (What)'.
Which statement works with this trigger?
Automation will take the Alias of the course and the course itself (not the Learning Experience). So when it comes time for looking for a statement for the trigger 'When a user enrols on an LX' or ' When a user completes an LX' the activity ID should be as below:
https://learningplatform.streamlxp.com/courses/customer-care
The activity ID must just include /course/ the alias of the course.
Once the statement has been found
To get a statement, go to Learning Locker and use the query builder to locate an appropriate statement to trigger your workflow. Then copy it.
If you toggle Suppress emails on, the workflow will not send any emails even if there are send email items in the workflow:
Once the test has completed, you'll see each item in the workflow highlighted in green (to indicate that it successfully completed its task), highlighted in red (to indicate that the item failed) or greyed out (to indicate that the item wasn't reached either due to a prior error or because it was on a condition branch that wasn't followed):
You can click Variables in the top right to view how your variables have been populated and adjusted. This can be very useful when determining why a workflow has or hasn't worked as expected:
If the workflow is still processing when you reach this screen, you can click Refresh to update the screen:
When you're done, click Return to workflow on the left: