What are Events in a Procedure?

Learn how to setup Events to model errors in your Procedures, or to allow your users more free-form interactions within the training.

One of the most powerful parts of the Procedure Builder is the Events system. It allows you to move from linear and static step-by-step instructions into more reactive and flexible training flows, by factoring in errors, alternatives, and optional learning moments. 

What are Events?

Events are tasks or interactions that run in parallel with Steps. However, unlike Steps (which are linear), Events can be optional checks, warnings, or actions. Events allow you to set up specific user actions, mistakes, or interactions at any given point, which are not part of the main procedure flow.

Why use Events?

Events make your training more dynamic, flexible and realistic. In the real world, people make mistakes or do things out of order. Moreover, they can provide an additional layer of safety, because the user is given feedback when such mistakes occur. Therefore, Events allow you to:

• Simulate errors or unsafe actions (what happens if you perform the wrong action?).
• Add optional interactions or exploration (additional learning opportunities, if the user chooses to investigate something).
• Enable parallel checks (monitor actions or conditions in the background).
• Provide real-time feedback (the procedure responds dynamically, like the real world would, with immediate consequences or feedback)

Types of Events

Events define when something should happen in your procedure. They probe for triggers, like entering an area or pressing a button, and then execute actions.

Here are a few examples of types of Events you can define in the Procedure Builder:

• Trigger-based Events: Events that are activated when a user enters or exits an area - can be defined using the Move inside area Operation.
• Interaction-based Events: Events that are activated when the user interacts with something - e.g. pressing a button, or activating a lever.
• System-driven Events: Events that are automatically activated by the system - e.g. using a Wait Operation to automatically activate the Events after a period of time.

Understanding Events in the Procedure Builder

A simple way to understand Events is to see them as extra operations that are triggered by the user’s behavior during the main steps of the procedure. The flowchart below represents the relationship between Steps, Operations, Actions and Events. Let’s break it down.

Structure of Events

Users can configure the following in an Event:

• Activate trigger: Specify how many trainees are needed to activate the Event. Choose between "When one player activates" or "When all players have activated".
• Deactivate trigger: Specify how many trainees are needed to deactivate the Event. Choose between "When one player deactivates"’ or "When all players have deactivated".
• Is error: Let the system know if the Event is to be treated as an error. When a trainee completes the Procedure through the LMS integration, a score board is shown at the end summarizing how many errors were triggered.
• On enter actions: List of Actions that will be executed when the Event is enabled as result of a "Toggle event" Action.
• Activate operations: Defines the Operations the trainee must perform to activate the Event. Multiple Operations can be defined – unlike for Steps where multiple Operations must all be performed to proceed to the next Step, when the first of these are performed by the trainee the Event is activated.
• On activate actions: List of Actions defining how the system responds to the user activating the event.
• Deactivate operations: Defines the Operations the trainee must perform to deactivate the Event. Multiple Operations can be defined – when the first of these are performed by the trainee the Event is activated.
• On deactivate actions: List of Actions defining how the system responds to the user deactivating the event.
• On exit actions: List of Actions that will be executed when the Event is disabled as result of a "Toggle event" Action.

How Steps and Events Work Together

A Step includes an Operation that the user must complete, while an Event listens in the background for conditions (like entering an area). Within Steps you can enable or disable Events using the Toggle Event Action.

In the example above, the procedure consists of one Step Group that contains two steps and one Event.

Step #1

• Actions Before: Toggle Event (Enable).
• Operation: Wait.
• Actions After: Nothing added.

We assigned a Wait Operation in the first step. This can be customized with Actions Before and Actions After, like a Toggle Event action, added here as an Action Before. This defines the point from which the Event is enabled.

Step #2

• Action Before: Nothing added.
• Operation: Wait.
• Actions After: Toggle Event (Disable).

A Wait Operation was added to Step #2, customized with an Action After, where another Toggle Event was added, this time to tell the system that this is the stage where we want the Event to be disabled.

Customizing the Event

Once the Event is enabled, it runs the following logic:

• On Enter Actions: None added.
• Activate Operations: Move Inside Area
• On Activate Actions: Toggle Visibility and Play Audio

We defined Move Inside Area as the task to perform to activate the Event. As soon as the user enters this area, Change Visibility actions are applied to one or more assets to make them visible, as well as having audio play via a Play Audio Action.

• Deactivate Operations: Move Inside Area
• On Deactivate Actions: Toggle Visibility and Play Audio
• On Exist Actions: None added.

We customize Deactivate Operations and On Deactivate Actions in an identical way, except we want the opposite to happen, that is, when the User steps out of the area, the assets will be hidden or turned off. Additionally, until this Event is disabled in the procedure, it maintains a repeatable nature, meaning that the user can step in and out of the defined area and the Event will respond.