How to Move a Spreadsheet Process into a Workflow

Summary

The steps

1. 1

   Map your spreadsheet columns to workflow stages

   Before touching the workflow editor, spend 20 minutes with your spreadsheet and a blank document. Your goal is to translate the spreadsheet's structure into a workflow graph on paper. This mapping exercise is the most important step in the process: a workflow built from a clear map is reliable; one built by guessing at the editor is not.

   Look at your spreadsheet and identify three things:

   • The stages. Each column (or group of columns) that represents a distinct phase of the process is a candidate for a workflow node. A typical spreadsheet process has four to eight stages: intake, AI processing, human review, approval, and output.
   • The decision points. Any place in the spreadsheet where a case can go one of two or more ways is a routing decision. A column called "Outcome" with values like "Approved", "Rejected", and "Needs More Info" is a routing decision. In a workflow, this becomes a Routing node or a Human Review node with three decision options.
   • The human touchpoints. Any stage where a person currently opens the spreadsheet and does something (enters data, changes a status, adds a comment) is a human touchpoint. In a workflow, these become User Interaction nodes (for data input) or Human Review nodes (for approve/reject decisions).

   Write the stages in order as a numbered list. Mark each one as: AI step, human input, human review, or routing. This list is your workflow blueprint.

   Do this

   • Open your spreadsheet and list every column header.
   • Group columns that belong to the same stage (for example, "Submitted By", "Submitted Date", and "Brief" might all belong to an Intake stage).
   • Mark each stage as: AI step, human input, human review, or routing decision.
   • Draw a simple left-to-right flow diagram on paper or in a notes document: boxes for stages, arrows for transitions, branches for routing decisions.
   • Identify the start (who initiates a new row?) and the end (what does a completed row look like?).

   Example

   A content approval spreadsheet has columns: Requester, Topic, Draft Link, AI Summary, Reviewer, Decision (Approved / Rejected / Revise), and Published Date. The mapping produces: Start (system) then User Interaction (Requester submits Topic and Draft Link) then Agent Interaction (AI Summary generated) then Human Review (Reviewer makes Decision) then Routing (Approved goes to End; Rejected goes to End; Revise loops back to Agent Interaction) then End.

   Best practice

   • Do not try to replicate every cell in the spreadsheet. Workflows model the process, not the data structure. Focus on stages and decisions, not on column-for-column fidelity.
   • If your spreadsheet has columns that are never actually used or are always empty, leave them out of the workflow map.
   • If the process has informal steps that happen outside the spreadsheet (a Slack message, a verbal approval), decide now whether to formalize them as workflow nodes or leave them outside the workflow. Formalizing them is usually better.
   • Keep the first version of the workflow simple. You can add complexity in later versions once the core process is running correctly.
2. 2

   Configure an AI provider and create your agents

   If your spreadsheet process includes any step where a person currently uses an AI tool (drafting, summarizing, classifying, extracting), that step becomes an Agent Interaction node in the workflow. Before you can build that node, you need an AI provider configured and an agent created.

   If your spreadsheet process has no AI steps, skip this step and move to step 3. You can always add agents later.

   Provider configuration is an Admin task. Navigate to Admin, then API Management, then Providers. You need the provider type, the base URI, and your API key for the AI service you use. DAVE supports seven provider types: OpenAI, Anthropic, Azure OpenAI, Google, OpenAI-compatible, local (Ollama), and custom. You bring your own API key and pay the provider directly.

   Once a provider is configured, create an agent for each AI step in your workflow map. Navigate to Agents in the sidebar and click Create Agent. Give the agent a name that describes its function in the process (for example, "Brief Summarizer" or "Contract Clause Extractor"), not the model it uses. Add a description and any relevant tags, then save. Click into the agent and add a version with the configuration JSON: system prompt, model, temperature, and any other parameters. The system prompt is the instruction set that tells the AI what to do with the input it receives from the workflow.

   Do this

   • Identify every AI step in your workflow map from Step 1.
   • If you have no AI steps, skip to Step 3.
   • Ask your Admin to configure at least one AI provider at Admin, then API Management, then Providers.
   • For each AI step, navigate to Agents in the sidebar and click Create Agent.
   • Name each agent after its function in the process, not after the model.
   • Add a version to each agent with a system prompt that describes exactly what the AI should do with the input it receives.
   • Test each agent version by reviewing its configuration before building the workflow.

   Example

   The content approval process from Step 1 has one AI step: generating a summary of the submitted draft. Create an agent named "Draft Summarizer" with a system prompt such as: "You are a content reviewer. Given the text of a draft article, produce a structured summary covering: (1) the main argument, (2) the key supporting points, and (3) any factual claims that require verification. Format your output as three labeled paragraphs." Set temperature to 0.3 for consistent, low-variance output.

   Best practice

   • Write the system prompt before creating the agent. A prompt written outside the editor is easier to review and refine than one written directly into a form field.
   • One agent per distinct AI task. Do not try to make one agent do everything. A summarizer and a classifier are two agents, not one agent with a complex prompt.
   • Name agents by function: "Invoice Classifier", "Contract Summarizer", "Risk Scorer". Names like "GPT-4 Agent" become misleading the moment you change the model in a new version.
   • Create, not Curate, builds agents. If you are a Curate user building the workflow, coordinate with a Create user to have agents ready before you open the workflow editor.
3. 3

   Create the workflow and open the editor

   With your workflow map from Step 1 and your agents from Step 2 ready, you can now build the workflow graph. This requires the Curate role (or Admin).

   Navigate to Workflows in the sidebar. Click New Workflow in the top-right of the list page. An inline form expands with two fields: Name (required) and Description (optional). Name the workflow after the process it represents, for example "Content Approval" or "Invoice Processing". Click Create Workflow. The new workflow appears in the list with a draft status badge (gray) and zero versions.

   Click the workflow name to open the visual editor. The editor opens at the workflow's editor path. You will see a canvas in the center, a node palette on the left, and a properties panel on the right. The canvas is where you build the graph. The palette is where you drag nodes from. The properties panel is where you configure each node after placing it.

   Creating a workflow from the list page does not create a version. A version is created only when you save from the editor. Until you save, the Versions column in the workflow list shows zero.

   Do this

   • Confirm you have the Curate or Admin role. If not, ask your administrator to assign it at Admin, then Settings, then Users and Roles.
   • Navigate to Workflows in the sidebar.
   • Click New Workflow.
   • Enter the process name in the Name field. Add a brief description of what the workflow does in the Description field.
   • Click Create Workflow.
   • Click the workflow name in the list to open the editor.
   • Familiarize yourself with the canvas, the node palette on the left, and the properties panel on the right before placing any nodes.

   Example

   For the content approval process: Name = "Content Approval Pipeline", Description = "Handles content requests from submission through AI summary, human review, and final decision." After clicking Create Workflow, the workflow appears in the list with a gray draft badge and 0 in the Versions column. Clicking the name opens the editor canvas.

   Best practice

   • Name the workflow after the process, not after a team or a date. "Content Approval" is a good name. "Marketing Q3 2026" is not: it becomes meaningless in Q4.
   • Use the Description field. A one-sentence description of what the workflow does and who uses it saves time for every team member who looks at the workflow list later.
   • Do not activate the workflow until it is fully built and tested. The draft status is your safety net: a draft workflow cannot be instantiated, so no one can accidentally run an incomplete process.
4. 4

   Build the graph: place nodes and connect edges

   With the editor open, build the workflow graph by following your paper map from Step 1. Drag nodes from the left palette onto the canvas, configure each node in the right properties panel, and connect them with edges to define the execution flow.

   The node types you will use most often for a spreadsheet migration are:

   • Start. Every workflow begins with a Start node. Drag it onto the canvas first.
   • User Interaction. For every human input step in your map, place a User Interaction node. Configure it to collect the fields you need.
   • Agent Interaction. For every AI step in your map, place an Agent Interaction node and select the agent you created in Step 2 from the properties panel.
   • Human Review. For every approve/reject decision point in your map, place a Human Review node. The reviewer will see three options: Approve, Reject, or Request Changes. Their decision and any comment they add are recorded in the audit trail.
   • Routing. For every branch in your map, place a Routing node. Configure the routing rules to define which edge is followed based on the incoming context.
   • End. Every workflow terminates with an End node. If your process has multiple terminal outcomes, place an End node for each.

   Connect nodes by drawing edges between them on the canvas. Edges define the execution order. An edge leaving a Human Review or Routing node can carry a condition that determines when that path is followed.

   Save the graph when you have placed and connected all nodes. Each save creates a new version with an incremented version number. Save frequently as you build: each save is a checkpoint you can refer back to.

   Do this

   • Drag a Start node onto the canvas first.
   • Working from your paper map, drag each subsequent node type onto the canvas in order.
   • After placing each node, click it to open its properties panel on the right and configure it: name, type-specific settings, and agent selection for Agent Interaction nodes.
   • Draw edges between nodes by connecting their output and input handles on the canvas.
   • For Human Review and Routing nodes, configure the edge conditions to define which path is followed for each decision or value.
   • Place an End node for each terminal outcome in your process.
   • Click Save. Confirm the Versions column increments to 1 in the workflow list.

   Example

   For the content approval process: drag Start, then User Interaction ("Submit Content Request"), then Agent Interaction ("Draft Summarizer"), then Human Review ("Editorial Review"), then Routing (branches on decision: Approved to End-Approved, Rejected to End-Rejected, Request Changes back to Agent Interaction), then End nodes. Save. Versions column shows 1.

   Best practice

   • Follow your paper map. Do not improvise in the editor. If the map needs changing, update the map first, then update the graph.
   • Name every node clearly. "Submit Content Request" is a better node name than "User Interaction 1". The name appears in the task inbox and in the audit trail.
   • Save after placing each major section of the graph, not just at the end. Each save is a version you can reference if you make a mistake.
   • Keep the graph readable. Arrange nodes left to right following the process flow. A graph that looks like a tangle of edges is hard to debug and hard to hand over to another team member.
5. 5

   Test the workflow with a representative case

   Before activating the workflow, run at least one test instance from the editor using a representative case from your spreadsheet. Testing in draft state is safe: a draft workflow cannot be used by anyone outside the editor, so test instances do not affect production.

   Navigate to Instances in the sidebar, click Create Instance, select your workflow and its latest version, and start the instance. The instance will progress through the graph automatically, pausing at User Interaction and Human Review nodes to generate tasks.

   Navigate to Tasks in the sidebar to see the tasks generated by the running instance. Open each task, provide the test input or make the test decision, and submit. Watch the instance progress through the graph. When it reaches the End node, check the instance status in the Instances list: it should show as completed.

   Run at least three test cases: a straightforward case that follows the main path, a case that triggers a branch (for example, a rejection), and an edge case that represents the most complex input your process handles. If any test case produces an unexpected result, return to the editor, fix the graph, save a new version, and retest.

   Do this

   • Navigate to Instances in the sidebar.
   • Click Create Instance, select your workflow and its latest version, and start the instance.
   • Navigate to Tasks. Open each task generated by the instance, provide test input or make a test decision, and submit.
   • Monitor the instance progress in the Instances list.
   • Verify the instance reaches the End node with a completed status.
   • Repeat for at least three representative cases: a main-path case, a branch case, and an edge case.
   • For each unexpected result, return to the editor, fix the graph, save a new version, and retest from the beginning.

   Example

   For the content approval process: test case 1 is a straightforward article submission that the reviewer approves. Test case 2 is a submission the reviewer rejects. Test case 3 is a submission with an unusually long draft that tests the AI agent's handling of long input. All three should reach an End node with completed status, following the correct path for each decision.

   Best practice

   • Test before activating. Once a workflow is active, it can be instantiated by anyone with the Use role. Test thoroughly in draft so the first live instance is not also the first test.
   • Use real data from your spreadsheet for test cases, not invented data. Real data surfaces real edge cases.
   • Document the test results. A simple note recording which cases you tested, what inputs you used, and what outputs the workflow produced is useful evidence if a process question arises later.
   • If a test case fails, fix the root cause in the graph, not just the symptom. A patch that makes one test pass while breaking another is not a fix.
6. 6

   Activate the workflow and retire the spreadsheet

   When all test cases pass, change the workflow status from draft to active. Navigate to Workflows in the sidebar, find your workflow, and change its status to active. The badge changes from gray (draft) to green (active). The workflow is now available for the team to use.

   Assign the correct roles to your team members so they can interact with the workflow in the way they need to. Users who will submit new cases and complete review tasks need the Use role. Users who need to see performance data need the Reporting role. Users who need to modify the workflow need the Curate role. A single team member can hold multiple roles simultaneously on a single seat.

   Run the workflow in parallel with the spreadsheet for the first week. Ask the team to process new cases through the workflow while continuing to update the spreadsheet. This parallel run catches any gaps between the workflow and the real process before you fully retire the spreadsheet. At the end of the parallel run, if the workflow is producing the correct outputs for all cases, stop updating the spreadsheet and direct all new cases to the workflow.

   Archive the spreadsheet rather than deleting it. The historical data in the spreadsheet is a record of cases processed before the workflow existed. Keep it accessible for reference. Similarly, if you ever need to retire the workflow in DAVE, archive it rather than delete it: archiving preserves the workflow and its version history without deleting anything, and there is no delete action on the workflow list page.

   Do this

   • Navigate to Workflows in the sidebar.
   • Change the workflow status to active. The badge changes from gray to green.
   • Navigate to Admin, then Settings, then Users and Roles, and confirm that each team member has the correct role for their function in the workflow.
   • Run the workflow in parallel with the spreadsheet for one week.
   • At the end of the parallel run, review the outputs and confirm they match the expected results for all case types.
   • Direct all new cases to the workflow and stop updating the spreadsheet.
   • Archive the spreadsheet file and note its location for historical reference.

   Example

   The content approval team runs the workflow in parallel with the spreadsheet for one week, processing eight new content requests through both systems. All eight produce matching outcomes. At the end of the week, the team lead confirms the workflow is correct and directs all new requests to the workflow. The spreadsheet is saved to a shared archive folder with a note: "Archived 2026-08-30. All new requests processed via Content Approval Pipeline in DAVE."

   Best practice

   • Do not skip the parallel run. The first week of parallel operation almost always surfaces at least one edge case the test phase missed.
   • Set a fixed end date for the parallel run before it starts. Open-ended parallel operation leads to teams continuing to use the spreadsheet indefinitely.
   • Communicate the switchover date to the whole team in advance. Surprise switchovers cause confusion and missed cases.
   • Keep the archived spreadsheet accessible. Someone will ask for historical data from it within the first month.

Why spreadsheet processes break, and what workflows fix

What you need before you start

Node types you will use in a spreadsheet migration

Frequently asked questions