Node: Request Action Plan
The Request Action Plan node sends an email asking one or more recipients to create an action plan. Like the other request nodes, it pauses workflow execution until the plan is actually created — or until a deadline is reached, if a timeout has been configured.
This node (as well as the Trigger: Action Plan) only appears in the editor's node palette when your space's company has the Action Plan module configured. If you don't find the node in the side panel, contact your company administrator.
How It Works
Unlike the Approval and Request Form Response nodes — whose link can be completed by anyone who receives it, even without a Hashdata account — this node's link opens an authenticated screen of the platform. Because of that, the recipient can only complete the request if they are already a collaborator of the workspace where the Action Plan is configured and already have permission to create/manage action plans in that workspace.
- The recipient receives an email with a "Create Action Plan" button, containing a link exclusive to that workflow instance.
- Clicking the link requires the recipient to log in to Hashdata (if not already authenticated), after which they are taken to the normal action plan creation screen, using their own collaborator permissions — if they don't have access to the workspace or lack the required permission, creation will be blocked, exactly as it would be outside the workflow.
- The recipient fills in and saves the action plan normally, exactly as they would outside the workflow.
- As soon as the plan is saved, the workflow automatically detects the creation and resumes execution, moving to the next node.
Unlike the other request nodes, this node does not grant access through the link — it only identifies which workflow instance the created plan should be linked to. Before configuring recipients, make sure each one is already a collaborator of the Action Plan's workspace and already has the permission to manage action plans there. An external email address or someone without that permission will receive the link but will not be able to complete the plan's creation.
Unlike an automation that "creates the record by itself", this node always depends on a real, authenticated person with permission to manage action plans in order to actually create the plan. This ensures that all the Action Plan module's auditing and permission rules continue to be respected normally.
While waiting, the workflow instance shows the status Awaiting action plan, visible in the "Last step" column on the workflow's instances screen.
When to Use
Use the Request Action Plan node whenever a process needs someone to formalize a corrective or improvement action before proceeding. Examples:
- Handling non-conformities: after an inspection or audit is rejected (via Trigger: Form Response), the workflow asks the responsible person to create an action plan to fix the identified problem.
- Reacting to failed verifications: combined with the Trigger: Action Plan configured for the "Verification failed" event, the workflow automatically requests a new corrective action when a previous action's effectiveness is not confirmed.
- Continuous improvement cycles: an indicator crosses a critical threshold and the workflow asks the responsible manager to formally register an action plan to address the root cause.
Configuration
To configure the node, click on it in the workflow canvas and fill in the fields in the right-hand side panel:
| Field | Description | Required |
|---|---|---|
| Recipients | Who will receive the email requesting the action plan's creation. The field accepts the same four recipient source types as the other request nodes (platform user, respondent of the trigger or an ancestor form, email field from an ancestor form, or a freely typed external email), but only someone who is already a collaborator of the Action Plan's workspace and has permission to create action plans will actually be able to complete the request when opening the link — so in practice, always prefer a platform user with that permission. Multiple recipients can be added. | Yes |
| Email subject | Subject line of the email sent to recipients. Supports variables in the {{field_name}} format, including Action Plan variables when there is an ancestor Action Plan trigger. | Yes |
| Email body | Main content of the email. Editor with support for formatting, variables, and artifact attachments (such as PDFs or form responses generated by ancestor nodes). The "Create Action Plan" button with the access link is included automatically — you don't need to add it manually. | Yes |
| Action plan defaults | Optional Indicator, Source, Action plan type, and Organizational unit values that will be pre-filled in the creation form shown to the recipient, speeding up completion when this data is already known by the workflow. | No |
| Timeout | Maximum wait time for the action plan's creation. Configure a duration (integer number) and a unit (Minutes, Hours, Days, or Weeks). If the deadline expires without the plan being created, the workflow follows the TIMEOUT output. | No |
Node Outputs
| Output | When it occurs |
|---|---|
| Main output | The recipient successfully created the action plan, within the deadline (or with no deadline set). |
| TIMEOUT | The configured deadline expired without any action plan being created. Only appears on the canvas when the timeout is enabled. |
If you don't configure a timeout, the node will remain waiting for the action plan's creation indefinitely, with the instance in the Awaiting action plan status. Configure a timeout in processes with a defined deadline to avoid instances being blocked indefinitely.
Data Available After Creation
As soon as the action plan is created, its data becomes available as variables for the following nodes in the workflow — the same variables described on the Trigger: Action Plan page: {{anomaly}} and {{actionPlan.cause|what|how|where|status|executorName|indicatorName|sourceName|actionPlanTypeName}}.
In addition, the Action plan created event now displays a "View action plan" link in the instance's event history, allowing direct access to the newly created plan.
Best Practices
- Confirm the recipient's access before publishing: check that each recipient is already a collaborator of the Action Plan's workspace and already has permission to manage action plans. A recipient without that pre-existing access will never be able to complete the request, and the instance will stay in Awaiting action plan indefinitely (or until the timeout, if configured).
- Add context to the email with variables: use variables from the form or the trigger Action Plan to explain to the recipient why the plan's creation is being requested. This reduces doubts and speeds up completion.
- Pre-fill the defaults when possible: configuring the Action plan defaults (Indicator, Source, Type, Organizational unit) reduces the recipient's effort and improves the consistency of the registered data.
- Always handle the TIMEOUT path in processes with a deadline, connecting it to a notification or escalation node.
- Combine with Set Status right before this node, to make it clear in the instance listing that the process is awaiting the creation of an action plan.