Actions
The most basic concept in Accode is the action. It's the main building block of workflows and most concepts in Accode either directly relate to actions or indirectly relate to the results produced by actions.
Overview
Actions are units of business logic that are chained together to achieve specific results. Some actions are simple and accomplish a single distinct operation, while others do a whole host of different things.
Basics
Creating a new action
Workflows are built by chaining actions together. Each action contains (+) buttons that allow for adding a new action after the select one. Pressing the button opens a menu that allows for picking the new action. This menu also allows for pasting in copied actions, routing to other actions and viewing documentation for each action.
Editing actions
Editing actions can be done by opening up “Edit” mode on the specific action. The action will then show you what settings are set up in a default view. Find the fields you would like to edit, open them and the default filter view will open. Now you can edit the actions according to your needs. After you have edited the action, press save.
Copying actions
You can easily copy actions. Press the “Action settings” on the specific action you would like to copy and find “Copy action”. You will not have the action copied into your clipboard. You can also copy “Action path”, which will then copy all the actions beneath and include the specific action you have identified.
Action properties
Outcome and output
Every time an entity enters an action, the action function is called. This function determines what the action does, and while the function can contain many side-effects and behaviors, the most common affect the following things:
- The entity: Many actions access fields in the entity, either to validate certain values or to change the values to something else.
- The action outcome: Actions always set an outcome value when an entity enters/exits the action, which can either be true, false, or null. The outcome determines whether the entity moves down through the action (true), is routed to the right (false), or whether the entity is blocked by the action (null). The default is true.
- The action output: Actions can optionally send an output payload when an entity exits the action, which can be any type of data. This output can then be read by other actions further in the workflow. The default is that no output payload is set.
The following example Script action reads values from the previous action output (which can be accessed from previous.payload), transforms the data, and returns the data. The returned data will now become this action’s output.
Action logs
Every time an entity enters and exits an action, a log is generated: the action log. The action log contains information about the outcome of the action (i.e. true/false/blocked), it contains a representation of any output data that is passed along to the next actions, information about exactly when the entity entered and exited the action and any error messages that the action gave rise to.
The action logs for a particular action can be viewed from the Action menu. Action logs are stored in the Action Log data model.
Debug logs
Actions (and other components in Accode) can also generate debug logs, which often contain information regarding the different states an action can take, side-effects an action can give rise to, and information about decisions that an action makes.
Examples
In this section, we showcase a few core actions and what their intended use case can be.
The Filter action
This action is included by default in a workspace. The Filter actions is used to check entities against a set of conditions. If the entity passes the conditions, it is passed through the action. If the entity fails the conditions, it is routed to the right.
In this example, the filter searches on whether the name contains “Production; CI” or passes a date range condition.
The Task action
This action is included by default in a workspace. The Task action defines a task that requires human intervention. When an entity enters such a task, it is delayed in the action, until the task has been completed. Tasks can be either approved or declined by the user. Once a task has been completed, the entity will continue to the next action.
In this example, we have a task list that collects purchase invoices in a default view. Task lists are used when you want to add a human element to the workflow. Read more about tasks here: Tasks
The Script action
This action is included by default in a workspace. The Script action allows for running arbitrary code in a workflow. With this action, the workflow builder can essentially create a custom type of action.
In this example the Script action reads a data object from the previous action output (which can be accessed from previous.payload) and returns only an array of trimmed messages.