Weekly Reporting Workflow: Example Framework

This weekly reporting framework moves through four stages each time it runs:

1. Trigger and data collection: A User Interaction node opens the reporting cycle and collects or confirms the reporting period and any manual data inputs the agent cannot fetch automatically.
2. Report generation: An Agent Interaction node reads the collected data and the reporting period, synthesises the week's workflow performance into a structured plain-language summary, and writes the draft to a named workflow field.
3. Review and approval: A Human Review node presents the draft summary to the reporting lead. The lead can approve the report for distribution or request changes.
4. Route and close: A Routing node branches on the review decision. Approved reports route to a final End node ("Report Approved"). Change requests loop back to the Agent Interaction node for revision, closing a lightweight revision loop.

The workflow produces two possible outcomes:

• Report Approved: The summary has passed review and is ready for distribution to stakeholders.
• Abandoned: An optional path for cases where the reporting lead determines that no report should be issued for this cycle (for example, insufficient data or a holiday period).

All paths terminate at a named End node. Distinct End node labels make reporting cycle outcomes distinguishable in the DAVE Reports page's Total Runs and Failure Rate cards.

Build the following nodes in the Workflow Editor. Drag each from the Node Palette, drop it on the canvas, rename it in the Properties Panel, and connect edges in the order shown. All edges run from the source handle (bottom) of the upstream node to the target handle (top) of the downstream node.

1. Start

Type: Start (green play icon). Label: "Start". No configuration required. Every workflow requires exactly one Start node.

2. Open Reporting Cycle (User Interaction)

Type: User Interaction (blue user icon). Label: "Open Reporting Cycle". Purpose: Collects the reporting period and any manual inputs needed before the agent runs. Fields section: Configure fields to capture: the reporting week (start and end dates), any notable events or context the reporting lead wants included in the summary (for example, a product launch or an outage), and confirmation that the reporting cycle should proceed. User Assignment: Assign to the reporting lead or the user responsible for initiating the weekly cycle. Notifications: Use the workspace rule (default) to notify the assignee when the task is ready.

3. Draft Weekly Report (Agent Interaction)

Type: Agent Interaction (purple bot icon). Label: "Draft Weekly Report". Agent Assignment: Assign a reporting agent. The agent's system prompt should instruct it to read the reporting period, any manual context provided, and the workflow performance data available in the instance context, then produce a structured weekly report summary covering: total workflow runs for the period, notable failures or latency spikes, pending task volumes, any context or events provided by the reporting lead, and a brief outlook or recommendation for the following week. Write the output to reportDraft. Fields section: Read the reporting week fields and the manual context field from Open Reporting Cycle. Write reportDraft.

4. Review Weekly Report (Human Review)

Type: Human Review (amber eye icon). Label: "Review Weekly Report". User Assignment: Assign to the reporting lead or a senior stakeholder who approves the report before distribution. Fields section: Pass reportDraft and the reporting week fields to the reviewer as context. The reviewer reads the draft and makes one of three decisions: approve, request changes, or abandon. Notifications: Use Custom audience and notify the task assignee directly. Report review tasks are time-sensitive: the report should reach stakeholders on a consistent day each week, so the reviewer should be notified promptly.

5. Route Review Decision (Routing)

Type: Routing (purple GitFork icon). Label: "Route Review Decision". Routing Configuration: Configure three output ports based on the Human Review decision field:

• Port "approved": decision equals approved, priority 1. Edge leads to End ("Report Approved").
• Port "changes-requested": decision equals changes-requested, priority 2. Edge leads back to Draft Weekly Report, closing the revision loop.
• Port "abandoned": decision equals abandoned (or rejected), priority 3. Edge leads to End ("Abandoned: No Report This Cycle").

End nodes

Use two distinct End nodes with descriptive labels:

• "Report Approved": the report has passed review and is ready for distribution.
• "Abandoned: No Report This Cycle": the reporting lead determined no report should be issued.

Distinct End node labels make the two outcomes distinguishable in the Reports page's Total Runs card and in the instance list. A completed instance reaching "Report Approved" counts as a successful run. An instance reaching "Abandoned" is still a completed run, not a failure, and will not inflate the Failure Rate card.

This workflow uses the following named workflow fields. Configure these consistently across all node Fields sections and the agent's system prompt. Field names are case-sensitive.

The instance context accumulates as the instance progresses. Fields written by Open Reporting Cycle persist through the entire instance lifecycle and are available to every downstream node without re-passing.

What data the agent can and cannot access

The reporting agent synthesises the data available in the instance context. It does not have direct read access to the DAVE Reports page's summary cards (Total Runs, Avg Latency, Failure Rate, Pending Tasks). Those cards are displayed on the Reports page for users with the Admin or Reporting role, and are not automatically injected into a workflow instance's context.

To include live metrics in the report, use one of these approaches:

• Manual input via Open Reporting Cycle: The reporting lead enters the week's key figures (total runs, failure rate, pending tasks) into the User Interaction fields before the agent runs. The agent then incorporates these figures into the narrative summary. This is the simplest approach and requires no API integration.
• API Call node: Insert an API Call node between Open Reporting Cycle and Draft Weekly Report. Configure it to call DAVE's REST API (305 endpoints) to fetch instance and task data for the reporting period. Map the response fields into the instance context. The agent then reads the fetched data alongside the manual context. This approach is more complex but produces a fully automated data feed.

DAVE's built-in Reports page (navigate to Reports in the sidebar) provides four summary cards that are always available to users with the Admin or Reporting role:

• Total Runs (blue): The total number of workflow instances started across the tenant.
• Avg Latency (purple): The average time between an instance starting and completing.
• Failure Rate (red): The percentage of instances that did not reach a completed state.
• Pending Tasks (amber): The number of tasks currently awaiting human action across all instances.

Four trend panels (Runs over Time, Failure Rates, Latency per Agent, Task SLAs) are planned and will appear when available. Date range filtering narrows report data to a specific time window for period-over-period comparison.

The Reports page and this workflow serve complementary purposes:

• The Reports page gives Admin and Reporting users an always-on operational view of workflow health. It is the right tool for monitoring and troubleshooting in real time.
• The weekly reporting workflow produces a curated, narrative summary for a broader stakeholder audience who may not have Reports page access, or who need context and commentary alongside the raw metrics. The workflow adds the reporting lead's judgment, the manual context, and a plain-language synthesis that the summary cards alone do not provide.

The two are designed to work together. The reporting lead uses the Reports page to gather the week's figures, enters them as manual context in the Open Reporting Cycle task, and the agent weaves them into a stakeholder-ready narrative.

Role access to the Reports page

Only the Admin and Reporting roles can access the Reports page. All other roles are restricted from viewing summary cards, trend panels, and the audit log. DAVE ships with six default tenant roles: Admin, Create, Curate, Use, Reporting, and Financial. All roles are editable by your administrator. The reporting lead who initiates this workflow and reviews the draft needs the Reporting role (or Admin) to access the Reports page for metric gathering, and the Use role to complete the workflow tasks in their Task Inbox.

This framework is a starting point. The following variations are common when adapting it to a specific reporting operation.

Adding an API Call node for automated metric ingestion

Insert an API Call node between Open Reporting Cycle and Draft Weekly Report. Configure it to call DAVE's REST API to fetch instance counts, failure rates, and task volumes for the reporting period. Map the response values to named workflow fields (totalRuns, failureRate, pendingTasks, avgLatency). The reporting agent reads these fields directly, removing the need for the reporting lead to enter figures manually. This is the recommended approach for high-frequency reporting or large tenants where manual data entry is error-prone.

Adding a Safety node before the agent

If the manual context field accepts free-text input from users other than the reporting lead, insert a Safety node between Open Reporting Cycle and Draft Weekly Report to screen the input before the agent processes it. The Safety node's guardrails propagate to every downstream agent call. Connect the flagged port to a dedicated End node labeled "Blocked: Policy Violation".

Splitting into per-workflow reports

If your tenant runs multiple distinct workflows and stakeholders need per-workflow breakdowns rather than a single tenant-wide summary, create one instance of this framework per workflow. Each instance collects data for its specific workflow, generates a focused summary, and routes to its own reporting lead for review. The Reports page's date range filter and (when available) the Failure Rates trend panel can help the reporting lead gather per-workflow figures for the manual input step.

Removing the revision loop

If the reporting lead trusts the agent's draft and does not need a revision cycle, remove the Route Review Decision Routing node and connect Review Weekly Report's approved port directly to End ("Report Approved"). Remove the changes-requested port and its back-edge. This simplifies the graph to four nodes and eliminates the loop entirely.

Scheduling the workflow

This framework is designed to be triggered manually by the reporting lead at the start of each reporting cycle. If your team wants to trigger the cycle automatically on a fixed schedule (for example, every Monday at 09:00), configure the workflow trigger accordingly when scheduled triggers are available in your workspace. Until then, the reporting lead initiates the cycle by starting a new instance and completing the Open Reporting Cycle task.

The Information node (indigo info icon) does not affect workflow execution: it creates no tasks, invokes no agents, and has no effect on the instance context. Its sole purpose is to add notes directly on the canvas for the benefit of anyone who opens the workflow in the editor later.

For a reporting workflow that runs weekly and may be maintained by different people over time, Information nodes are especially valuable. Place them beside (not in) the execution path: a node with no incoming or outgoing edges is purely documentary.

Recommended Information node placements for this workflow:

• Beside Open Reporting Cycle: Document the five fields collected, their expected format, and where the reporting lead should source the metric figures (the Reports page summary cards). Label the node "Inputs: reporting period, manual metrics, context notes".
• Beside Draft Weekly Report: Document the agent's system prompt summary and the output field name. Label the node "Agent: synthesises inputs into reportDraft. See agent config for full prompt."
• Beside Route Review Decision: Document the three routing rules and their priority order. Label the node "Routing: approved (p1) to Report Approved, changes-requested (p2) loops to Draft, abandoned (p3) to Abandoned End."
• Beside the revision loop back-edge: Document the loop. Label the node "Revision loop: Draft Weekly Report → Review Weekly Report → Route Review Decision → (changes-requested) back to Draft."