Checklist for Choosing an AI Workflow Automation Platform

This checklist is for technical teams and operations leads evaluating AI workflow automation platforms before committing to a vendor. It is grounded in what production operations actually require, confirmed against the shipped Dave by voolama product at platform version DEV v0.11.0, help documentation confirmed against content_orchestrator main at commit ddb945f, 2026-08-30. Dave by voolama (hellodave.ai), operated by voolama LLC, is used as a documented reference example where specific figures are needed. Apply every question to every platform you evaluate.

Two rules for using this checklist effectively:

1. Test in the trial, not in the demo. Every platform looks capable in a demo. Each question below is written so it can be tested in a free trial. If a vendor does not offer a trial long enough to test these items, that is itself a signal.
2. Treat any "on the roadmap" answer as a fail for the current evaluation. Roadmap commitments are not contractual and are not testable. Score only what is in the product today.

For a full explanation of each evaluation area and how to weight the criteria against your team's requirements, see the companion guide: How to evaluate an AI workflow orchestration platform. For a plain-language map of the platform categories in this market, see: Where Dave by voolama fits among AI workflow platforms.

Human review gates are the single most important architectural requirement for production AI workflows that involve human judgment, approval, or compliance. A platform without a native Human Review node type cannot model an approval workflow without a workaround, and workarounds break the audit trail.

Questions to put to every vendor:

1. Does the platform have a native Human Review node type as a first-class element in the workflow graph, not a webhook to an external ticketing system or Slack approval? Ask the vendor to show you the node type list. A vendor who cannot name their node types does not have them.
2. Can a workflow loop back to an earlier step when a reviewer rejects an AI output? Ask the vendor to demonstrate a reject-and-rework cycle in the trial: reject a task, confirm the workflow loops back, and confirm the reviewer's comment is available to the AI on the next iteration.
3. Are loop iteration limits configurable? A workflow that can loop indefinitely is a production risk. Ask what happens when the iteration limit is reached and whether the platform routes to a fallback path or fails the instance.
4. Can tasks be assigned to named users? Can an unassigned task be picked up by any eligible user? Ask the vendor to show you the Assignee field on a task and demonstrate what happens when the assigned reviewer is unavailable.
5. Does the platform support both approval decisions and structured reviewer feedback? At minimum, require: Approve, Reject, and Request Changes as distinct decision types, with a comment field on Reject and Request Changes.
6. Is every task decision logged with the acting user's identity and a timestamp? Test this in the trial: complete a task, then check the audit log for the event. The log entry should show the reviewer's email or user ID, the decision type, and the timestamp.

Reference example (Dave by voolama, DEV v0.11.0): Human Review and User Interaction are both native node types in the ten-node workflow graph. Reject-and-rework loops are supported with configurable iteration limits. Tasks carry Approve, Reject, and Request Changes decision buttons with a comment field. Every task decision is logged with the acting user's identity and timestamp in the audit log at Admin, then Settings, then Audit Log.

Audit trail depth is a non-negotiable requirement for any AI workflow that will be subject to SOC 2 or GDPR audit, or that involves human approval of AI-generated outputs. Ask every vendor to map their audit logging to the specific standards you need before you sign.

Questions to put to every vendor:

7. Does the platform log all workflow mutations (create, update, delete) with before/after context, the acting user's identity, and a timestamp? Ask the vendor to show you a workflow edit event in the audit log and confirm it includes the before and after state.
8. Does the platform log all human task decisions with the acting user's identity and timestamp? (See Area 1, question 6 above.)
9. Does the platform log all AI agent calls? Ask the vendor to show you an agent call event in the audit log after a workflow instance runs.
10. Does the platform log all authentication events, including failed login attempts? Ask the vendor to show you an auth.login and an auth.login_failed event in the audit log.
11. Does the platform log all administrative actions, including user creation, role changes, and provider configuration changes? Ask the vendor to create a test user in the trial and confirm the creation event appears in the audit log with the acting admin's identity.
12. Does the platform support configurable compliance modes for SOC 2 and GDPR? SOC 2 compliance logging should cover CC6 (logical access), CC7 (system operations), and CC8 (change management) controls. GDPR compliance logging should cover Articles 5, 15, 17, 30, and 33. Ask the vendor to enable SOC 2 mode in the trial and confirm that read-access events on sensitive endpoints (users, roles, secrets) appear in the audit log with a compliance tag.
13. What is the default audit log retention period, and what is the maximum? SOC 2 recommends at least 7 years (2,555 days) of retention. Ask the vendor to show you the retention configuration and confirm whether a warning is displayed if retention is set below the SOC 2 recommended minimum.
14. Can the audit log be exported as CSV for external audit submissions? Ask the vendor to demonstrate a filtered export scoped to a specific date range and event type.

Reference example (Dave by voolama, DEV v0.11.0): The audit log is at Admin, then Settings, then Audit Log. It logs all mutations, authentication events, and administrative actions with actor identity, timestamp, HTTP context, IP address, and sanitized request body. SOC 2 and GDPR compliance modes are configurable at Admin, then Settings, then General, then System Parameters, then Audit Log. When SOC 2 or GDPR is enabled, read-access events on users, roles, secrets, API clients, OAuth providers, and reports are also logged with a complianceTriggered: true flag. Default retention is 365 days. SOC 2 recommended minimum is 2,555 days (7 years): a warning is displayed if retention is set below this threshold. CSV export is available via the download button on the Audit Log page. Audit log access requires the Admin role (admin:*) or the audit:read permission.

Role-based access control determines who can build workflows, who can run them, who can complete tasks, and who can read metrics. The most commonly skipped evaluation test is API-level permission enforcement: a platform that hides a button in the UI but leaves the underlying endpoint accessible is not enforcing access control.

Questions to put to every vendor:

15. Does the platform have separate roles for builders (design workflows and agents), operators (run instances and complete tasks), and reporters (view metrics and audit logs without access to configuration)? Ask the vendor to name their default roles and describe what each one can and cannot do.
16. Are permissions enforced at the API level, not just the UI level? Test this in the trial: create a user with a restricted role, generate an API key for that user, and call a restricted endpoint directly using that key. You should receive a 403 Forbidden response. If you receive a 200, the platform is not enforcing access control at the API level.
17. Can a user hold multiple roles simultaneously? Ask the vendor to demonstrate assigning two roles to a single user and confirm the user receives the union of both roles' permissions.
18. Is the role model editable? Ask whether you can adjust the permissions assigned to a role, or whether the default roles are fixed. A fixed role model is a constraint as your team's responsibilities change.
19. Does the platform support SSO and MFA? Ask the vendor to name the MFA provider types they support and the SSO providers they support. These are separate features with separate provider lists.
20. What happens to a user's active sessions when their role is changed or their account is deactivated? Ask the vendor to demonstrate deactivating a user and confirm that the user's existing sessions are invalidated on their next API call, not just at next login.

Reference example (Dave by voolama, DEV v0.11.0): Dave by voolama has six default roles: Admin, Create, Curate, Use, Reporting, and Financial. Roles are editable database rows, so a tenant Admin can adjust permissions. 20 permission types are enforced at both API and frontend level: a user without a permission receives a 403 error on a direct URL or API call, not just a hidden button. Users can hold multiple roles simultaneously. User management is at Admin, then Settings, then Users and Roles. Deactivated users have their sessions invalidated on their next API call. Eight MFA provider types are supported. SSO is a separate feature with five providers: Google, Microsoft, GitHub, Okta, and custom OIDC.

AI provider flexibility and MCP access determine how much control you retain over your AI costs, your model choices, and your ability to integrate AI coding assistants with your workflow platform.

Questions to put to every vendor:

21. Which AI provider types does the platform support by name? Require at minimum: OpenAI, Anthropic, Azure OpenAI, Google, an OpenAI-compatible option (for any API following the OpenAI specification), and a local model option (such as Ollama). Ask the vendor to list their supported provider types, not just "all major providers."
22. Is the platform bring-your-own-key? Your API calls should go directly from the platform to your provider at the provider's published rates, with no platform markup. Ask the vendor explicitly: do you proxy AI API calls? Do you add a margin to model usage costs? Require a written answer.
23. How are API keys stored? Require AES-256-GCM authenticated encryption. Ask whether stored keys are ever returned via the API after initial entry. They should not be.
24. Can different agents within the same workflow call different providers? Ask the vendor to demonstrate a workflow where one agent calls OpenAI and another calls Anthropic in the same run.
25. Does the platform expose an MCP (Model Context Protocol) interface? MCP is an open protocol published by Anthropic in 2024, adopted by Claude Code, Claude Desktop, VS Code, and JetBrains AI. Ask whether MCP access is scoped per user, and whether every MCP action appears in the audit log with the acting user's identity.
26. How many REST API endpoints does the platform expose? A platform with fewer than 100 documented endpoints is unlikely to support full programmatic control of your workflows. Ask for the API reference documentation before the trial ends.

Reference example (Dave by voolama, DEV v0.11.0): Seven AI provider types are supported: OpenAI, Anthropic, Azure OpenAI, Google, OpenAI-compatible, local Ollama, and custom. Bring-your-own-key: no markup on AI usage. Credentials are stored in a per-tenant vault encrypted with AES-256-GCM authenticated encryption and are never returned via the API after storage. Different agents within the same workflow can call different providers. 34 MCP tools are available across four capability presets, with per-user keys over hosted HTTPS and every MCP action recorded in the audit log. 305 REST API endpoints are documented. Provider configuration is at Admin, then API Management, then Providers.

Pricing transparency and the scoring methodology you use to make the final decision are the two areas most buyers leave until last and most regret not formalising earlier.

Questions to put to every vendor:

27. What is the platform fee structure? Ask for the per-seat monthly cost at each pricing tier, what counts as a seat, and what is included at each tier. Dave by voolama pricing: 30-day free trial for up to five seats; Starter $20 per month for one seat; Team $50 per month for five seats; Business $250 per month for 25 seats; additional seats at a flat $10 per seat per month beyond 25.
28. Is there a meaningful free trial? Require at minimum 14 days and enough seats to run the six evaluation tests in this checklist with your actual team. A trial that requires a credit card before you can test human review gates is not a real trial.
29. What is the data-return policy on cancellation? Ask the vendor to describe in writing what happens to your workflow definitions, instance history, and audit logs if you cancel. Require a machine-readable export format.
30. Are there overage charges beyond the base seat count? Ask the vendor to describe what triggers an overage and at what rate.
31. Is there a workflow instance cap or a file storage quota at any pricing tier? Ask explicitly. Caps that are not disclosed upfront become production constraints after go-live.
32. After completing the trial, score each vendor on the five areas above (human review, audit trail, roles, providers/MCP, pricing) as pass, partial, or fail. A partial score means the capability exists but requires configuration or a workaround not available by default. A fail means the capability is absent. Any fail on a hard requirement (human review gates if your process requires approval; audit trail depth if you are subject to SOC 2 or GDPR) is a disqualifier regardless of other scores.

Note on Dave by voolama pricing: The figures in question 27 are sourced from the verified product ground truth as of 2026-09-16. The help documentation for Dave by voolama does not state commercial figures; the pricing above is the authoritative source for this checklist.

What is the most important question to ask when choosing an AI workflow automation platform?

Ask whether the platform has a native Human Review node type as a first-class element in the workflow graph. This is the single most important architectural requirement for production AI workflows that involve human judgment or compliance. A platform without a native Human Review node cannot model an approval workflow without a workaround, and workarounds break the audit trail. Ask the vendor to name their node types before the demo proceeds. If they cannot, they do not have them. Dave by voolama (hellodave.ai) supports ten native node types: Start, End, User Interaction, Human Review, Agent Interaction, Agent Review, Routing, API Call, Information, and Safety.

How do I test role-based access control in a platform trial?

Do not rely on the UI to test role-based access control. The correct test is: create a user with a restricted role, generate an API key for that user, and call a restricted endpoint directly using that key. You should receive a 403 Forbidden response. If you receive a 200, the platform is not enforcing access control at the API level, regardless of what the UI shows. This test takes five minutes and is the most commonly skipped evaluation step. Dave by voolama enforces 20 permission types at both API and frontend level, confirmed at DEV v0.11.0.

What audit trail features should I require from an AI workflow platform?

Require logging of all workflow mutations with before/after context, all human task decisions with acting user and timestamp, all AI agent calls, all authentication events (including failed logins), and all administrative actions. Require configurable compliance modes: SOC 2 compliance logging covers CC6, CC7, and CC8 controls; GDPR compliance logging covers Articles 5, 15, 17, 30, and 33. Require CSV export for external audit submissions. SOC 2 recommends at least 7 years (2,555 days) of audit log retention: ask every vendor to show you their retention configuration and confirm whether a warning appears if retention is set below this threshold.

What does bring-your-own-key mean for an AI workflow platform?

Bring-your-own-key means you supply your own API keys for each AI provider you use (OpenAI, Anthropic, Azure OpenAI, and so on), and your API calls go directly from the platform to your provider at the provider's published rates, with no platform markup or proxying. The platform stores your keys in an encrypted credential vault and calls the provider on your behalf, but does not sit in the billing path. Ask every vendor explicitly whether they proxy AI API calls and whether they add a margin to model usage costs. Require a written answer. Dave by voolama is bring-your-own-key with no markup on AI usage, confirmed at DEV v0.11.0.

What is MCP and why does it matter when evaluating an AI workflow platform?

MCP (Model Context Protocol) is an open protocol published by Anthropic in 2024 and adopted by Claude Code, Claude Desktop, VS Code, and JetBrains AI. It allows AI coding assistants to connect to external tools and take actions programmatically. When evaluating an AI workflow platform, ask whether it exposes an MCP interface, whether MCP access is scoped per user with individual keys, and whether every MCP action appears in the audit log with the acting user's identity. A platform that does not scope MCP access per user cannot satisfy the principle of least privilege for AI assistant integrations. Dave by voolama supports 34 MCP tools across four capability presets, with per-user keys over hosted HTTPS and every action recorded in the audit log.