How Do I Run a Workflow on a Recurring Schedule Without Clicking Start Every Time?

Summary

The steps

1. 1

   Confirm your workflow is active and has at least one saved version

   Before you can start any instance, the workflow must be in active status and must have at least one saved version. A workflow in draft status cannot be instantiated. A workflow with no saved versions has nothing to run.

   Navigate to Workflows in the sidebar. The list shows each workflow's name, status (draft, active, or archived), and the number of saved versions in the Versions column. The three-stage lifecycle documented in the Dave by voolama Workflows help page is: draft (initial state, not available for instantiation), active (published, can spawn instances), and archived (retired, preserved for reference, cannot spawn new instances). If your workflow shows draft, open it and change the status to active. Only Admin and Curate roles can change workflow status.

   If you cannot see the Workflows section at all, your user account does not hold a role with the required permission. See Why Can't I See Agents, Workflows, or Other Sections in Dave by voolama? for the role-to-section mapping. Dave by voolama has six default roles: Admin, Create, Curate, Use, Reporting, and Financial. All six are editable. The Workflows section is accessible only to Admin and Curate roles. Create, Use, and Reporting roles cannot access it.

   The Versions column shows the total count of saved versions. If it shows zero, open the Workflow Editor, build or verify the graph, and click Save Version in the top-right corner. Each click of Save Version creates a new immutable snapshot. The dropdown when you create an instance shows versions in the format {Workflow Name} - v{VersionNumber}.

   Do this

   • Navigate to Workflows in the sidebar.
   • Find your workflow in the list. Check the Status column: it must show active (green badge).
   • Check the Versions column: it must show at least 1.
   • If status is draft, click the workflow name, change status to active.
   • If versions is 0, open the Workflow Editor, build the graph, and click Save Version.

   Example

   A hypothetical small accounting practice wants to run a weekly client document chase workflow every Monday morning. Before setting up any trigger, the office manager confirms the workflow shows active status and v3 in the Versions column, meaning three saved versions exist and the most recent is v3. She notes the version number so she can specify it when creating each new instance.

   Best practice

   • Keep the workflow in draft while you are still building and testing it. Only move it to active when you are confident the graph is correct.
   • Note the version number you want recurring runs to use. If you save a new version later, existing instances continue running the version they were started on, but new instances will use the latest version unless you specify otherwise.
   • Archive a workflow (instead of deleting it) when you retire it. Dave by voolama has no delete action for workflows: archive is the only retirement path. Archiving preserves the version history and all past instance records.
2. 2

   Start an instance manually from the Instances page

   The simplest way to run a workflow is to create an instance manually from the Instances page. Navigate to Instances in the sidebar. The list shows all instances in your workspace with columns for Status, Workflow Version, Owner, and Created date.

   Click New Instance in the top-right corner. A creation form expands. Select your workflow and version from the Workflow Version dropdown, which lists entries in the format {Workflow Name} - v{VersionNumber}. Click Create Instance.

   The new instance starts in draft status (gray badge). This gives you a moment to review before execution begins. Click into the instance to open the detail page, then click Start to move it to running status (green badge). Only Admin and Use roles can create and start instances.

   For a recurring process, this manual step means someone on your team needs to remember to create and start the instance on the right day. That works for low-frequency runs (monthly, quarterly) where a calendar reminder is enough. For weekly or daily runs, the REST API approach in Step 3 removes the manual step entirely.

   Do this

   • Navigate to Instances in the sidebar.
   • Click New Instance in the top-right corner.
   • Select your workflow and the version you want to run from the Workflow Version dropdown.
   • Click Create Instance. The instance appears with a draft status badge (gray).
   • Click the instance row to open the detail page.
   • Click Start to begin execution. The status changes to running (green badge).

   Example

   A hypothetical marketing agency runs a monthly newsletter draft workflow on the first Monday of each month. The office manager has a recurring calendar reminder to open Instances, create a new instance of the Newsletter Draft workflow (v2), and click Start. The workflow runs the Agent Interaction node automatically and then pauses at the Human Review node for the owner to approve the draft before it goes to the client.

   Best practice

   • Use the draft status as a checkpoint. Before clicking Start, confirm you selected the correct workflow version in the dropdown.
   • If you need to stop a running instance temporarily, click Pause rather than Cancel. A paused instance can be resumed; a cancelled instance cannot be restarted.
   • The instance detail page shows Created, Started, and Completed timestamps. Check these after each run to confirm the instance finished as expected.
3. 3

   Trigger instances automatically using the REST API and an external scheduler

   Dave by voolama exposes 305 REST API endpoints. Creating a new instance is one of them. This means any tool that can send an HTTP POST request on a schedule can start a workflow run automatically, with no one needing to click anything in the platform. HTTP POST is defined in RFC 9110 Section 9.3.3 as the method for submitting data to a server to create a new resource, which is the standard mechanism the Dave API uses for instance creation.

   Common scheduling tools include cron (specified in POSIX.1-2017 via the Open Group's crontab utility specification), scheduled tasks in cloud automation platforms, or calendar-based triggers in no-code tools. The general pattern is: your external scheduler sends an HTTP POST request to the Dave REST API at the scheduled time. The API creates the instance and, depending on how you configure the request, can move it directly to running status.

   To authenticate API requests, you need an API key from your Dave by voolama workspace. Navigate to your workspace settings to generate a per-user API key. Every API action taken with that key is recorded in the audit log with the key owner's identity, so the audit trail remains complete for scheduled runs just as it does for manual ones.

   The specific endpoint path, request body shape, and authentication header format are in the Dave by voolama API reference for your workspace. If you need help connecting an external system to Dave via REST, the guide at How to Connect DAVE to an Existing System by REST covers the connection pattern in detail.

   Important: the Dave by voolama Workflow Editor help page lists all ten node types and confirms that none of them is a timer or scheduling node. If you need a workflow to run on a fixed schedule without any external tool, that capability is not currently available in the Workflow Editor. The REST API is the supported path to automation.

   Do this

   • Decide on your scheduling tool. Options include: a cron job (specified in POSIX.1-2017), a scheduled task in a cloud automation platform, or a calendar-based trigger in a no-code tool.
   • Generate an API key in your Dave by voolama workspace settings. Store it in your scheduling tool's secrets or environment variables, not in plain text.
   • Find the instance creation endpoint in the Dave by voolama API reference for your workspace. The endpoint accepts the workflow version ID and returns the new instance ID.
   • Configure your scheduler to send an HTTP POST request to that endpoint at the cadence you need (daily, weekly, monthly).
   • Test the trigger manually before relying on it for production runs. Confirm the instance appears in the Instances list with the correct workflow version and moves to running status.

   Example

   A hypothetical small manufacturer wants a weekly quality checklist workflow to run every Friday at 8 a.m. A developer sets up a scheduled cloud function that runs at 8 a.m. every Friday, reads the Dave API key from the function's environment variables, and sends an HTTP POST to the Dave instance creation endpoint with the checklist workflow's version ID. The instance is created and started automatically. The production supervisor sees the first task in their Task Inbox when they open Dave at 8:30 a.m., with no manual setup needed each week.

   Best practice

   • Use a dedicated API key for scheduled triggers rather than a personal user key. If the key needs to be rotated, you only need to update it in one place.
   • Log the HTTP response code from each scheduled trigger. A 2xx response means the instance was created; a 4xx or 5xx response means something went wrong and the run did not start.
   • Set up a notification rule in Dave by voolama (Settings, Notifications, Events) for task assignment, so the right person is alerted when a scheduled run creates a task that needs their attention.
4. 4

   Monitor running instances and manage their status

   Once an instance is running, you monitor it from the Instance detail page. Navigate to Instances in the sidebar and click any instance row to open its detail page.

   The detail page shows:

   • Status badge (top-right): the current lifecycle state with a color code. Running is green; waiting for user input is amber; waiting for review is pink; completed is blue; failed is red; cancelled is gray.
   • Metadata grid: three cards showing Created, Started, and Completed timestamps. A timestamp that has not occurred yet shows a dash.
   • Tasks table: every task the instance has generated, with columns for Type, Status, Node, and Created. Click a task row to open the task detail page.
   • Context viewer: a collapsible section (click Context to expand) showing the data the instance has accumulated as formatted JSON. Useful for checking what an agent produced or why a routing decision went a particular way.

   Control buttons change based on the current status. When the instance is running, you see Pause and Cancel. When it is paused, you see Resume and Cancel. When it is in a waiting state (waiting_user_input or waiting_review), you see only Cancel. Completed, cancelled, and failed instances have no control buttons. These are the exact control button states documented in the Dave by voolama Instances help page.

   For a recurring scheduled workflow, the most common monitoring task is checking whether the instance is stuck in a waiting state because a task has not been completed. If the instance shows waiting_user_input or waiting_review, open the Tasks table, find the pending task, and complete it. The instance will not advance until the task is resolved. For a detailed walkthrough of task decisions and their audit trail, see How Do I Use Dave by voolama Task Decisions as an Audit Trail for SOC 2 and GDPR?

   Do this

   • Navigate to Instances in the sidebar after a scheduled run should have started.
   • Find the instance in the list. Check the Status badge: running (green) means it is executing; waiting states (amber, pink) mean a task needs attention.
   • Click the instance row to open the detail page.
   • If the instance is in a waiting state, open the Tasks table and click the pending task to complete it.
   • If the instance has failed (red badge), expand the Context viewer to inspect error details and check the Tasks table for failed tasks.
   • If you need to stop a run temporarily, click Pause. If you need to stop it permanently, click Cancel.

   Example

   A hypothetical bookkeeping practice runs a weekly missing-document chase workflow every Monday. On Tuesday morning, the owner checks the Instances list and sees the Monday instance is still in waiting_user_input status (amber badge). She clicks the instance, opens the Tasks table, and sees a User Interaction task is pending because a staff member has not yet filled in the client list for that week. She completes the task herself and the instance resumes automatically.

   Best practice

   • Check the Instances list at a regular time after each scheduled run, especially in the first few weeks. Waiting states are the most common reason a recurring workflow appears to have stalled.
   • Use the Context viewer to debug unexpected results. If an agent produced output you did not expect, the context JSON shows exactly what data the agent received and what it returned.
   • Pause instead of cancel when investigating a problem. A paused instance preserves its state and can be resumed once you have identified and fixed the issue.
5. 5

   Review past runs and understand what each instance produced

   The Instances list in Dave by voolama is your history of every workflow run. There is no separate run-history view per workflow: all instances from all workflows appear in the same list, with columns for Status, Workflow Version, Owner, and Created date.

   Click any completed instance to open its detail page. The metadata grid shows the exact Created, Started, and Completed timestamps for that run. The Tasks table shows every task the instance generated, with the task type, its final status (completed, failed, cancelled), the node that generated it, and when it was created. Click any task row to open the task detail page and see the full input, output, and decision record for that task.

   The Context viewer on the instance detail page shows the final state of the instance's context as formatted JSON. This is the accumulated data from every node the instance passed through: what the user submitted, what the agent produced, what the reviewer decided.

   All instance lifecycle events are recorded in the audit log: state transitions (start, pause, resume, cancel, complete, failure), step execution with timing, and error events with details. Navigate to the audit log (Admin, Audit Log) to search or export these records. This audit trail behavior is documented in the Dave by voolama Instances help page under the Audit Trail section.

   If your recurring workflow produces a summary you want to share outside Dave by voolama, the output lives in the instance context. You can read it from the context viewer, or retrieve it programmatically via the REST API using the instance ID. For a practical template of what a recurring monthly summary should include, see What Should a Monthly Customer Feedback Summary Include?

   Do this

   • Navigate to Instances in the sidebar.
   • Scan the list for instances with a completed (blue) or failed (red) status badge from your most recent scheduled run.
   • Click a completed instance to open its detail page.
   • Check the metadata grid for the Created, Started, and Completed timestamps to confirm the run finished in the expected time window.
   • Open the Tasks table and click each task row to review the input, output, and decision for that step.
   • Expand the Context viewer to inspect the final accumulated data from the run.
   • Navigate to Admin, Audit Log to search for the instance ID if you need a full event-by-event record of the run.

   Example

   A hypothetical small law office runs a monthly client matter status workflow on the first of each month. At the end of the month, the office manager opens the Instances list, finds the completed instance from the first, and clicks into it. The Context viewer shows the AI agent's summary of open matters and the attorney's review decision. The office manager copies the summary from the context viewer into the firm's monthly report document.

   Best practice

   • After the first few scheduled runs, compare the Completed timestamps across instances to see whether runs are finishing in a consistent time window. A run that takes much longer than usual may indicate a task that sat in a waiting state for an extended period.
   • If a run fails, check the Context viewer and the Tasks table before starting a new instance. The error details in the context often explain the cause, which you can fix before the next scheduled run.
   • For workflows that produce outputs you need to retain, consider whether the context viewer alone is sufficient or whether you need to retrieve the output via the REST API and store it in another system.

What Dave by voolama actually provides for recurring workflow runs

Instance status reference: what each color means and what to do next

Where this guide stops