Trigger: Scheduled
The Trigger: Scheduled node starts a workflow automatically at regular time intervals, without depending on any human interaction. Unlike the form-based trigger, this node is fired by the system itself according to the configured frequency — daily, weekly, bi-weekly, or monthly — enabling reliable and predictable automation of recurring tasks.
Each time the schedule is activated, a new workflow instance is created and follows the flow defined in the editor, executing all configured nodes in sequence or in parallel, according to the process design.
When to Use
The Trigger: Scheduled is suitable for processes that need to happen at fixed dates or intervals, regardless of a manual action. Some common examples:
- Periodic reports: send a weekly summary of indicators to managers via email or Slack.
- Recurring reminders: notify teams monthly about compliance deadlines, contract renewals, or mandatory reviews.
- Scheduled data collection: trigger an evaluation form every week for employees in a specific group.
- Maintenance tasks: trigger export integrations to spreadsheets or external systems during low-traffic hours.
- Approval cycles: automatically start a monthly approval flow without anyone needing to remember to trigger the process.
If your process depends on an external event — such as the submission of a form — use the Trigger: Form Response instead of this node.
Configuration
To configure the Trigger: Scheduled, click on the node in the workflow editor canvas. The side panel will display the options described below.
| Field | Description | Available options |
|---|---|---|
| Frequency | Defines how often the workflow will be automatically triggered. | Daily, Weekly, Bi-weekly, Monthly |
| Execution time | Defines the exact time at which the workflow will be started on the scheduled day. | Hour and minute selection (24h format) |
| Day of the week | Available when the frequency is Weekly or Bi-weekly. Defines on which day of the week the trigger occurs. | Monday to Sunday |
| Day of the month | Available when the frequency is Monthly. Defines on which day of the month the trigger occurs. | 1 to 28 (to ensure execution in all months) |
| Recipients | Defines who the process participants are. Required in this type of trigger, since there is no associated form respondent. | See Recipients section below |
Recipients
Since the Trigger: Scheduled is not linked to a form response, there is no automatic "respondent". Therefore, it is mandatory to configure at least one recipient directly in the node.
You can add recipients in four different ways:
- Platform user — select an internal user already registered in Hashdata. Ideal for involving team members with access to the system.
- External email — freely type an email address. Useful for including people outside the organization or group addresses (such as
team@company.com). - Form email field — references the value of an email-type question in an ancestor form of the workflow. Not applicable to the pure scheduled trigger, but available when combined with other nodes that collect responses.
- Form respondent — represents whoever filled out the trigger or ancestor form. Not applicable to this type of trigger.
Unlike the Form Response Trigger — which automatically has the respondent as a process participant — the Scheduled Trigger has no implicit participant. Therefore, you must configure at least one recipient directly in this node for the remaining workflow steps to function correctly, especially nodes that send emails or request approvals.
Difference from the Form Trigger
Understanding the difference between the two types of triggers is fundamental to correctly modeling your processes in Hashdata.
| Characteristic | Trigger: Form Response | Trigger: Scheduled |
|---|---|---|
| What starts the workflow | A user submits (or changes/deletes) a form response | The system fires automatically at the configured time |
| Response data available | Yes — all form fields are available as variables {{field_name}} | No — there is no form response associated with the trigger. But you can use the Request Form Response node to send a form link to recipients to respond (recommended). |
| Automatic respondent | Yes — whoever submitted the form is the default respondent | No — recipients must be configured manually |
| Variable usage | Variables from trigger form fields are available in all subsequent nodes | Variables will only be available if subsequent nodes collect responses (e.g., Request Form Response) |
| Human interaction to trigger | Yes — depends on form submission | No — completely automatic |
Important: in workflows started by the Scheduled Trigger, variables in the format {{field_name}} will not be available in email or status nodes immediately after the trigger, as there is no filled form data. To use variables, add a Request Form Response node to the flow, which will collect data from participants and make the fields available as variables in the following nodes.
Timezone and Execution
The execution time of the Scheduled Trigger is interpreted according to the timezone configured in your organization in Hashdata. If your team is distributed across different timezones, check with the space administrator what the reference timezone is before configuring the trigger time. A workflow scheduled for 08:00 will execute at 08:00 in the organization's timezone, which may correspond to different times for users in other regions.
Scheduled Workflow Lifecycle
A workflow with a Scheduled Trigger follows the same lifecycle as other platform workflows:
- Draft: the workflow has been created and configured, but has not yet been published. No instances will be created while the workflow is in draft.
- Published and Enabled: the workflow is active. Each time the schedule is reached, a new instance will be created automatically.
- Published and Disabled: the workflow does not accept new scheduled triggers. Instances already in progress continue normally until the end of the flow.
To permanently stop future triggers, disable the workflow on the space's workflow listing page.
Best Practices
- Avoid peak hours: schedule workflows that involve external integrations (such as spreadsheet exports or webhook calls) during low-usage hours, such as early morning.
- Combine with the Set Status node: use the Set Instance Status node right after the trigger to record a descriptive message, making monitoring easier in the instance list.
- Use the Wait node sparingly: in long-running scheduled workflows, the Wait node can be combined with the trigger to create pauses within the flow, but remember that waiting instances remain active and consume resources.
- Test before publishing: use the workflow preview mode to review the logic before enabling the schedule in production.