Trigger: Action Plan
The Trigger: Action Plan node automatically starts a workflow based on events that happen in Hashdata's Action Plan module — such as the creation of a new action, a status change on an action, a failed effectiveness verification, or an action being rescheduled. It's the ideal starting point for automating processes that depend on tracking action plans, without needing to monitor them manually.
Just like the Trigger: Form Response, this trigger is fired by a real system event (the creation or change of a plan action) and makes that action's data available as variables to the following nodes in the workflow.
The Trigger: Action Plan node (as well as the Request Action Plan node) only appears in the editor's node palette when your space's company has the Action Plan module configured. If you don't find these nodes in the side panel, contact your company administrator.
When to Use
Use the Trigger: Action Plan node whenever a process needs to automatically react to an action plan's lifecycle. Some examples:
- Approval of new actions: whenever a new action is created in a plan, the workflow sends an approval request to the responsible manager before it is considered valid.
- Escalation by status: when an action's status changes to "Overdue" or "Canceled", the workflow automatically notifies the responsible person or the action's executor.
- Handling failed verifications: if an action's effectiveness verification fails, the workflow can automatically ask the responsible person to reassess the cause or create a new corrective action.
- Tracking reschedules: every time an action is rescheduled, the workflow logs the event and notifies interested parties about the new deadline.
Configuration
To configure the Trigger: Action Plan node, click on it in the workflow editor's canvas. The properties panel will display the fields below, in the Trigger section.
| Field | Description | Required |
|---|---|---|
| Event | Defines which Action Plan event triggers the workflow. The options are:
| Yes |
| Target statuses | Visible only when the selected event is Status changed. Lets you select one or more specific statuses that should trigger the node — for example, only when the action changes to "Completed" or "Overdue". If no status is selected, this field is required for this event type. | Yes, when event = Status changed |
| Indicator | Optional filter: restricts the trigger to actions linked to a specific indicator. | No |
| Source | Optional filter: restricts the trigger to actions originating from a specific source. | No |
| Action plan type | Optional filter: restricts the trigger to actions of a specific action plan type. | No |
| Organizational unit | Optional filter: restricts the trigger to actions associated with a specific organizational unit (group). | No |
When no filter (Indicator, Source, Type, or Organizational unit) is selected, the trigger considers all actions that match the configured event, regardless of these dimensions.
Advanced Conditions
Beyond the filters above, you can further refine when the trigger should fire using the Conditions section, which evaluates fields of the Action Plan itself (such as Anomaly, Cause, Executor, among others).
Conditions work the same way as the If/Else node, including support for multiple conditions combined with AND/OR or custom expressions. The If/Else node's page has the complete list of Action Plan fields available for conditions.
Data Available to Following Nodes
When the Trigger: Action Plan fires, the action's data (and its associated problem) becomes available as variables in all nodes downstream of the trigger, using the variable picker ({{}}) in any compatible field:
| Variable | Description |
|---|---|
{{anomaly}} | Shortcut for the anomaly (problem) associated with the action plan. |
{{actionPlan.anomaly}} | Anomaly (problem) associated with the action plan. |
{{actionPlan.cause}} | Cause registered for the anomaly. |
{{actionPlan.what}} | Description of the "What" of the action (what will be done). |
{{actionPlan.how}} | Description of "How" the action will be executed. |
{{actionPlan.where}} | Where the action will be executed. |
{{actionPlan.status}} | Current status of the action, already translated to the recipient's language. |
{{actionPlan.executorName}} | Name of the executor responsible for the action. |
{{actionPlan.indicatorName}} | Name of the indicator linked to the action, when present. |
{{actionPlan.sourceName}} | Name of the source linked to the action, when present. |
{{actionPlan.actionPlanTypeName}} | Name of the action plan type, when present. |
These variables can be used in email nodes (subject and body), in the Set Status node, in If/Else conditions, and in integration nodes (Slack, Teams, spreadsheets).
A common pattern is to use the Trigger: Action Plan to react to an event (for example, a failed verification), and then use the Request Action Plan node to ask the responsible person to create a new corrective action, closing the continuous improvement loop.
Also see the workflow nodes overview to learn about all available node types.