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