Awell Health Developer Hub
Dev Hub

What is an Action?

An action is the most low level and granular building block at design-time in a pathway or care flow. Compared to tracks and steps which purely help you organizing a pathway , an action defines what needs to happen by who. There are default or native actions in Awell like a form, message, checklist, and calculation.

The anatomy or building blocks of a Pathway/Care flow

The anatomy or building blocks of a pathway/care flow

Actions can also be classified by whether they should be completed by a user or will (automatically) be completed by a system. We refer to these as user actions/activities (eg: form) and system actions/activities (eg: calculation, API call), respectively.

What is an Activity?

When an action is activated at run-time (i.e. orchestration), an activity is created in the Awell System to keep track of its start date, status, completion date, etc. The activity stores a reference to the action so we know at all times what action needs to be completed as part of what activity.

Action vs. Activity

Action vs. Activity

At run-time, we create activities because, depending on how your pathway is structured, a track or step (and thus the actions in it) might be activated more than once (one-to-many relationship). That is why at run-time we talk about activities instead of actions. The details about the action are embedded in the activity.

Please note that an orchestrated pathway doesn't only consist of activities related to actions but that there are many other (system) activities as well (eg: track activation/completion, step activation/completion, reminders, ...). You can thus look at activities as a full history log of what has happened in a pathway.

What are Custom Actions?

Custom Actions are a specific type of extentions that allows you to add one or more custom action types to your pathways.

The extension you build to add Custom Actions has two components:

  1. Front-end: define the settings of your extension, the UI configuration for the actions, and how the actions need to be rendered when being previewed and orchestrated.
  2. Back-end: define the logic of how and when the activity (which will be created when your action is activated) can be completed.