Getting Non-Engineers to Build AI Workflows

The DAVE Workflow Editor is a visual drag-and-drop canvas for designing workflow graphs. It uses a three-panel layout that keeps everything a workflow designer needs in one screen:

• Left: the Node Palette. A scrollable sidebar listing all ten node types, each with an icon and a color-coded border. To add a step to the workflow, drag the node type from the palette onto the canvas. That is the entire interaction for adding a step: drag and drop.

• Center: the Canvas. The interactive area where the workflow graph lives. It shows a dot-grid background, zoom controls, a mini-map in the bottom-right corner, and a live counter showing the current number of nodes and edges. You can pan, zoom, and scroll freely. For large workflows, the mini-map lets you navigate to any part of the graph without excessive panning.

• Right: the Properties Panel. Appears when you click a node. Shows editable fields for the node's label and configuration, plus read-only fields for its ID, type, and position. Renaming a node from its default label (for example, changing "User Interaction" to "Collect Author Brief") takes one click and a few keystrokes.

There is no code editor. There is no JSON panel that a workflow designer needs to touch for routine workflow construction. The editor was built specifically to make process design accessible to anyone with the appropriate role, without requiring engineering involvement.

The one place where JSON appears is the node configuration panel for advanced settings on specific node types, such as API Call nodes that need a request body template or response field mapping. For workflows that do not include API Call nodes, a non-technical workflow designer can build and save a complete production workflow without encountering JSON at all.

Every step in a DAVE workflow is one of ten node types. Understanding what each type does is the core literacy a workflow designer needs. None of them require code to configure for standard use cases.

• Start. The entry point of the workflow. Every workflow must have exactly one Start node. Execution begins here. Drag it onto the canvas first.

• End. A terminal node that marks workflow completion. A workflow can have multiple End nodes for different outcomes, for example one for an approved path and one for a rejected path.

• User Interaction. Pauses the workflow and creates a human task. The workflow resumes after a user submits the required input. Use this wherever the process needs a person to provide information before the workflow can continue.

• Human Review. Creates a review task for a human reviewer. The reviewer can approve, reject, or request changes. The workflow branches based on the decision. Use this wherever a human needs to evaluate an output and make a go/no-go call.

• Agent Interaction. Invokes an AI agent automatically. The agent processes the current workflow context and returns a result without human involvement. This is the node type that does the AI work.

• Agent Review. An AI-powered automated quality check. An agent evaluates content against defined criteria and returns a pass/fail result. Use it to automate a quality gate that would otherwise require a human reviewer for every instance.

• Routing. A logic-only node for conditional branching. Evaluates output port criteria to determine the execution path, with no user or AI involvement. Use it to separate branching logic from functional nodes and keep the graph readable.

• API Call. Calls an external REST API during workflow execution. Sends an HTTP request, captures the response, and maps response values back into workflow fields. This is the most configuration-heavy node type and the one most likely to need engineering input for initial setup.

• Information. A documentation or annotation node. Does not affect execution. Drop Information nodes next to complex sections of the graph to explain the intent for future editors. This is the non-technical workflow designer's best friend for making a graph self-documenting.

• Safety. Runs content safety and compliance checks. Flags or blocks content that violates configured policies. May generate a task depending on configuration.

For most operational workflows, a non-technical designer will primarily use Start, End, User Interaction, Human Review, Agent Interaction, and Routing. The other four node types are available when needed but are not required for a complete, production-grade workflow.

The Workflow Editor is accessible to two roles: Admin and Curate. For a non-engineer who is a process designer, the Curate role is the right assignment. It gives full workflow-building access without touching anything outside that scope.

With the Curate role, a user can:

• Open the Workflow Editor for any workflow in the tenant.
• Add and remove nodes from the canvas.
• Connect and disconnect edges between nodes.
• Edit node properties, including labels and configuration.
• Save new workflow versions. Each save creates an immutable snapshot: previous versions are preserved and can be loaded later, so there is no risk of overwriting a working design.

The Curate role also includes agents:read, which means a Curate role holder can see the agents available in the tenant and reference them in Agent Interaction and Agent Review nodes. They cannot create or modify agents: that requires the Create role. This separation is intentional and valuable.

A workflow designer who can also modify the AI agents their workflows depend on is a separation-of-duties problem. The person designing the process should not also be able to change the AI behaviour the process relies on. The Curate role enforces this boundary at the API level: it is not a convention or a guideline, it is enforced on every request. A Curate role holder who tries to edit an agent configuration will be blocked, whether they try through the browser or through the API directly.

To assign the Curate role to a team member, an Admin navigates to Admin, then User Management, finds the user's row, clicks the edit button, toggles the Curate badge on, and saves. The change takes effect on the user's next login.

The fastest way to build confidence with the Workflow Editor is to build a minimal workflow first, run an instance, and see it complete. The DAVE documentation recommends starting with a simple Start, then Agent Interaction, then End workflow to verify that the agent configuration works before adding complexity. Here is the sequence for a slightly more realistic first workflow that includes a human review step.

1. Open the Workflow Editor. Navigate to Workflows in the sidebar, select or create a workflow, and open the editor. If the canvas is blank, the workflow has no saved versions yet: this is expected for a new workflow.

2. Drag a Start node onto the canvas. Find Start in the Node Palette on the left. Drag it onto the canvas and drop it near the top. Every workflow needs exactly one Start node.

3. Drag an Agent Interaction node below the Start node. This is the step where the AI does its work. Click the node to open the Properties Panel, rename it to something descriptive (for example, "Draft initial response"), and use the Agent Assignment section to select the agent that should run this step.

4. Drag a Human Review node below the Agent Interaction node. This is the step where a person reviews the AI output. Rename it (for example, "Review AI draft") and use the User Assignment section to specify who should receive the review task.

5. Drag an End node below the Human Review node. You may want two End nodes: one for the approved path and one for the rejected path.

6. Connect the nodes with edges. Hover over the source handle (the bottom circle) of the Start node. Click and drag to the target handle (the top circle) of the Agent Interaction node. Release to create the edge. Repeat for each connection: Agent Interaction to Human Review, Human Review to End (approved), Human Review to End (rejected).

7. Name your nodes descriptively. Click each node and update its label in the Properties Panel. A graph where every node has a specific, meaningful name is self-documenting: anyone who opens the editor later can understand the process without reading a separate document.

8. Add an Information node if the design needs explanation. Drop an Information node next to any complex section of the graph and add a note in its label. It does not affect execution.

9. Click Save Version. The editor serializes the graph and creates a new immutable version. The version list is updated. Previous versions are preserved.

10. Run a test instance. Navigate to Instances, create an instance from the workflow version you just saved, and run it through to completion. Confirm every node executes as expected and every task appears for the right user.

The entire sequence above, for a workflow of this complexity, takes under thirty minutes for a first-time user. For a workflow designer who has built a few workflows, it takes ten.

Giving non-engineers the ability to build workflows does not mean engineers have nothing to contribute. It means the contribution is in the right place.

Agent configuration is an engineering responsibility. The Create role, which covers building and editing AI agents, requires judgment about model selection, prompt engineering, temperature settings, and the behaviour parameters that determine what the AI actually does. A workflow designer can reference an agent in a workflow, but the quality of the AI output depends on the quality of the agent configuration. That is an engineering and AI craft responsibility, not a process design one.

Provider setup is an Admin responsibility. Connecting DAVE to an AI service, managing API keys, and maintaining the model catalog requires the Admin role. Engineers or IT administrators typically own this function. Without a configured provider, no Agent Interaction node can function: the dependency chain runs from providers through agents to workflows, and the engineering layer is at the foundation.

API Call nodes often need engineering input. The API Call node type connects a workflow to an external REST API. Configuring the method, URL, headers, body template, and response field mapping is a technical task that benefits from engineering involvement, at least for the initial setup. Once an API Call node is configured and working, a workflow designer can copy the pattern to other workflows without needing to reconfigure it from scratch.

Complex routing logic can benefit from a review. Routing nodes evaluate port criteria to determine execution paths. For simple branching (approved goes left, rejected goes right), a non-technical designer can configure this independently. For complex multi-branch logic with nested conditions, an engineering review of the routing configuration before go-live reduces the risk of a path that never resolves.

The right model is not engineers building workflows or non-engineers building workflows. It is engineers owning the AI capability layer (providers and agents) and process designers owning the workflow layer (the graph that orchestrates those capabilities into a business process). DAVE's role model enforces exactly this division, at the API level, on every request.