AI Workflow Go-Live Checklist for DAVE

Every element of a DAVE workflow depends on the element before it. Understanding this chain is the most important thing to hold in mind before a go-live, because a failure at any step almost always traces back to a missing or misconfigured element earlier in the chain.

The chain runs in this direction:

1. Providers are the foundation. A provider is a configured connection to an AI service: it holds the API key, the base URI, and the model catalog. Without at least one active provider, agents cannot call any AI model and will fail immediately when invoked.

2. Agents depend on providers. An agent wraps a provider with a specific configuration: a system prompt, a model selection, a temperature setting, and other behavior parameters. An agent with no valid provider reference cannot function.

3. Workflows depend on agents. A workflow is a visual graph of nodes connected by edges. Agent Interaction nodes reference specific agents. A workflow that references an agent with no valid provider will fail when that node is reached during execution.

4. Instances depend on workflows. An instance is a single execution of a specific workflow version. You cannot launch an instance without a saved workflow version to run.

5. Tasks are generated by instances. When a running instance reaches a node that requires human input or review (User Interaction, Human Review, Agent Review), it generates a task assigned to a user. Tasks cannot exist without a running instance, and they cannot be completed by a user who does not have the Use role.

6. Reports depend on completed instances. The reports dashboard shows run volume, failure rates, latency, and SLA metrics. There is nothing to report until instances have run.

The go-live checklist follows this chain exactly. Complete each phase before moving to the next.

DAVE's six default roles map directly onto the go-live dependency chain. Different phases of the checklist require different roles, and in a team setting, different people will own different phases. Confirm role assignments before starting the go-live sequence.

• Admin. Required for Phase 1 (provider setup) and Phase 2 (user and role setup). Only Admins can configure providers at Admin, then API Management, then Providers and manage user accounts at Admin, then Settings, then Users and Roles. Admins also have access to all other phases.

• Create. Required for Phase 3 (agent creation). Only Create role holders (and Admins) can create and configure agents. Curate role holders can read agents but not create or edit them.

• Curate. Required for Phase 4 (workflow build). Only Curate role holders (and Admins) can create and edit workflows in the visual editor.

• Use. Required for Phase 5 (instance launch and task completion). Only Use role holders (and Admins) can launch instances and complete tasks. A user without the Use role will not see Instances or Tasks in the sidebar.

• Reporting. Required for Phase 6 (post-launch verification via reports). Only Reporting role holders (and Admins) can access the Reports dashboard.

• Financial. Not directly involved in the technical go-live sequence. Assign to the team member responsible for billing and commercial management of the tenant.

In a small team, one person may hold multiple roles and complete all phases. In a larger team, confirm that the right people have the right roles assigned before the go-live date, so no phase is blocked waiting for a role assignment to be made.

Phase 1: Provider setup (Admin required)

• Navigate to Admin, then API Management, then Providers.
• At least one provider record exists and is configured with a valid name, provider type, base URI, and API key.
• Fetch Models has been run on the provider and returned a non-empty model catalog.
• The provider card is visible in the provider list and the model catalog is populated correctly (expand the card with the chevron to confirm).
• The API key used is a production key (not a development or trial key with rate limits that will affect production workloads).

Phase 2: User and role setup (Admin required)

• Navigate to Admin, then Settings, then Users and Roles.
• All team members who need access have active user accounts.
• Every account has at least one role assigned. No active account has an empty Roles column (an account with no roles sees an empty dashboard and cannot do any meaningful work).
• The team member who will build agents has the Create role (or Admin).
• The team member who will build workflows has the Curate role (or Admin).
• Every team member who will run instances and complete tasks has the Use role (or Admin).
• The team member who will monitor reports has the Reporting role (or Admin).
• Role changes have been saved and affected users have been asked to log out and back in (role changes take effect on the next login).

Phase 3: Agent setup (Create role required)

• Navigate to Agents in the sidebar.
• At least one agent exists for each AI-powered step in the workflow.
• Each agent has a descriptive name and at least one saved version.
• Each agent version references a valid provider and a model that exists in that provider's catalog.
• Each agent version has a system prompt that reflects the intended production behavior (not a placeholder or test prompt).
• Temperature and other behavior parameters are set to production values.

Phase 4: Workflow build (Curate role required)

• Navigate to Workflows in the sidebar.
• The workflow definition exists and has at least one saved version.
• The workflow graph has a Start node and at least one End node.
• All nodes are connected by edges. No node is an island with no incoming or outgoing connection (except Start, which has no incoming edge, and End, which has no outgoing edge).
• Every Agent Interaction node references a valid, published agent version.
• Every Human Review or User Interaction node has a clear task description so assignees know what is expected of them.
• Routing edges have conditions configured where branching logic is required.
• The workflow has been saved. Each save creates an immutable version: confirm the version number is visible and the save completed without error.

Phase 5: End-to-end test run (Use role required)

• Navigate to Instances in the sidebar.
• Click Create Instance, select the workflow and its latest version, and launch a test instance.
• The instance status moves from draft to running without error.
• Navigate to Tasks. Any User Interaction tasks generated by the test instance are visible and assigned correctly.
• Complete each task in sequence: open the task, provide the required input or make the review decision (Approve, Reject, or Request Changes), and submit.
• The instance progresses through all nodes without stopping in a failed state.
• The instance reaches completed status. Confirm this in the Instances list.
• Review the instance context and artifacts to confirm the AI agent outputs are as expected for the production use case.
• The Dashboard summary cards update to reflect the completed instance (Running Instances count decrements; check Recent Instances panel).

Phase 6: Post-launch verification (Reporting role required)

• Navigate to Reports in the sidebar (requires the Reporting feature flag to be enabled; confirm with Admin if the Reports link is not visible).
• The test instance appears in the reports dashboard.
• Run volume, failure rates, and latency data are visible for the workflow.
• No unexpected failure events appear in the report for the test run.
• Confirm the audit log is recording events for the test run (visible to Admin and Reporting roles).

Go-live sign-off

• All phases above are complete with no open items.
• The team members who will operate the workflow in production have been briefed on how to find and complete tasks.
• A point of contact has been identified for issues that arise after go-live.
• The workflow is ready for production instances.

These are the most frequent causes of a failed or delayed go-live, based on the dependency chain described above.

• No provider configured, or provider API key invalid. Agents cannot function without a valid provider. If an Agent Interaction node fails immediately when the instance reaches it, the first thing to check is the provider: navigate to Admin, then API Management, then Providers, expand the provider card, and confirm the model catalog is populated. If it is empty, the API key or base URI is likely incorrect. Edit the provider, re-enter the key, and run Fetch Models again.

• Agent references a model not in the provider's catalog. If the model an agent was configured with is no longer in the provider's catalog (because the catalog was rebuilt and the model was not re-selected), the agent call will fail. Open the agent, check the model selection, and confirm the model exists in the current catalog.

• Workflow saved with disconnected nodes. A node with no outgoing edge (other than an End node) will cause the instance to stall when it reaches that node. Review the workflow graph in the editor before go-live and confirm every non-End node has at least one outgoing edge.

• Use role not assigned to task assignees. A user without the Use role cannot see the Tasks sidebar item and cannot complete tasks. An instance waiting for a task to be completed will remain in waiting_user_input status indefinitely. Confirm every user who needs to complete tasks has the Use role assigned and has logged out and back in after the role was assigned.

• Reports link not visible. The Reports sidebar item requires both the Reporting role and the reporting feature flag to be enabled. If the link is missing for a Reporting role holder, ask an Admin to check Admin, then Settings, then Feature Flags and confirm the reporting flag is on.

• Role changes not yet in effect. Role changes take effect on the user's next login. A user who was assigned a new role while logged in will not see the new sidebar items until they log out and back in. If a team member reports missing sidebar items immediately after a role assignment, ask them to log out and back in.

Can I go live with a workflow that has not been fully tested?
You can launch a production instance of any saved workflow version. DAVE does not enforce a testing gate before production use. However, an untested workflow that fails mid-execution will leave an instance in a failed or waiting_user_input state that requires manual intervention. The end-to-end test run in Phase 5 of this checklist exists to catch those failures before they affect real work.

What is the difference between a workflow version and a workflow instance?
A workflow version is an immutable snapshot of the graph, saved each time you save the workflow in the editor. A workflow instance is a single execution of a specific version. Multiple instances can run from the same version simultaneously. When you update a workflow and save it, a new version is created: existing running instances continue on their original version and are not affected by the new save.

What happens if an agent call fails during a live instance?
If an Agent Interaction node fails, the instance may move to a failed status, or a task may be generated for human review and intervention, depending on how the workflow is configured. Check the instance detail view for the error message. The most common causes are an invalid API key on the provider, a model that is no longer available, or a rate limit error from the AI service.

Who can see the Tasks sidebar item?
Only users with the Use role (or Admin) can see the Tasks sidebar item and complete tasks. A user without the Use role will not see the link even if tasks are assigned to them. Confirm role assignments at Admin, then Settings, then Users and Roles.

Can I run multiple instances of the same workflow simultaneously?
Yes. Multiple instances of the same workflow version can run at the same time. Each instance is independent and maintains its own context data as it progresses through the graph.

What does the Dashboard show after go-live?
The Dashboard shows four summary cards: Agents, Workflows, Running Instances, and Pending Tasks. It also shows a Recent Instances panel and a Pending Tasks panel. These update in real time as instances run and tasks are generated or completed. The Dashboard is visible to all six roles and is the recommended first stop after logging in.

Do I need to configure Feature Flags before go-live?
Feature Flags are optional. The core workflow capability (Start, End, User Interaction, Human Review, Agent Interaction, Agent Review, Routing, API Call, Information, and Safety nodes) does not require any feature flag to be enabled. Advanced capabilities such as advanced_nodes, split_join, and pdf_export are gated behind feature flags that an Admin can enable at Admin, then Settings, then Feature Flags. The reporting flag must be enabled for the Reports sidebar item to appear.