Workflow automation RFP questions

A credible partner describes the topology in concrete terms: one main instance handling triggers and webhooks, Redis passing executions to a worker pool, and PostgreSQL as the shared database that workers read and write. Ask for the worker count per environment, how workers are scaled, and how Redis and PostgreSQL are backed up and made highly available. Ask whether they plan to run multi-main high availability, which n8n restricts to Enterprise self-hosted deployments, and what that license costs in their quote. Request a sample topology diagram, the environment variables or Helm values used for each role, and a load test report showing executions per minute at the target volume. Expect them to say what they will not promise about failover until your test results exist.

The right answer names a key owner, a storage location and a rotation procedure. In n8n queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can decrypt credentials stored in the database. Ask where the key lives (a secrets manager inside your environment, not a file in a repository), who can read it, how it reaches each container without appearing in logs or images, and what happens to stored credentials if the key is lost or rotated. Ask for the documented rotation runbook, the access list for the secrets store, and proof that backups of the database are encrypted or handled as sensitive data. A partner who cannot say who holds the key has not designed the system.

Look for a Git-based process with named branches, reviewed merges and a promotion path through separate environments. Ask whether the partner uses n8n's environments feature with Git, which n8n lists only in its Business and Enterprise plans, or an alternative such as exporting workflow JSON into a repository and deploying through a pipeline. Ask who approves a change, how the approval is recorded, and how credentials are kept out of exported files so that production secrets never move with a workflow. Request an example change record showing a workflow edit from request to production, the rollback steps, and the list of people with production edit rights. For Node-RED, ask the same questions about flow JSON and the deploy process, since flows are stored as JSON.

A credible answer lists the alert route, the owner of each alert and the retry rules per workflow. Ask which error workflow runs when an execution fails, where the alert is sent (a monitored channel with an on-call rotation, not one person's inbox), how duplicate alerts are suppressed, and how retries avoid repeating side effects such as payments or record creation. For Temporal, ask how workflow timeouts and retry policies are defined, and how stuck or failed executions are surfaced in the Web UI. Request a sample alert with its payload, the escalation matrix, and the dashboard or log export used to review failures each week. Ask who receives alerts outside working hours and whether that coverage is included in the proposed scope.

Ask the partner to name each feature the design depends on and the plan that includes it. According to n8n's pricing page, the free self-hosted Community edition exists, but SSO and LDAP, environments with Git and log streaming are included only in the Business and Enterprise plans, and Business is currently self-hosted only. Multi-main high availability is restricted to Enterprise self-hosted deployments. Enterprise uses custom pricing and adds dedicated support with an SLA. Also ask whether your use is internal, because n8n's Sustainable Use License permits use only for internal business purposes or non-commercial use, and files marked .ee need an Enterprise License. Request a written feature matrix tied to your design, the license model for each planned use, and confirmation of who buys and holds the license.

Good partners treat custom nodes like software: a repository, code review, tests, a version number and a documented upgrade path. Ask whether custom nodes are written in TypeScript or JavaScript, where the source lives, who owns the repository after handover, and how each node is tested against the n8n version in use. Ask how they handle n8n upgrades that change node APIs, how community nodes are vetted before installation, and who approves a new dependency. For Node-RED, ask whether contributed nodes come from the library of more than 5,000 community nodes or are built in-house, and how they track Node-RED 5.0 requirements, which need Node.js 22.9.0 or later with Node.js 24 recommended. Request the maintenance runbook, the dependency list and a written handover plan.

The answer should cover authentication, role separation and network placement. Ask how the n8n editor is reached, whether SAML single sign-on is configured (available on Business and Enterprise plans, with setup guides for Okta and Azure AD), and how production edit rights are limited to named roles. For Node-RED, the editor is not secured by default, so anyone who can reach the IP address can deploy changes. Ask for evidence that HTTPS, authentication through Passport, and the admin API are configured, and that HTTP nodes use basic authentication where needed. For Temporal, ask whether an Authorizer is configured, because without one the default noopAuthorizer allows every API request. Request the access matrix, the SSO configuration record and a network diagram showing that Temporal services are not reachable from the public internet.

Ask for the written scope before comparing prices. Most engagements are fixed-scope at DeployOpen, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that scope. Ask which parts are included: platform installation, queue-mode topology, secrets handling, Git and promotion setup, alerting, documentation and training for your team. Then ask what you would need to run it alone: skills in the platform, on-call coverage, license holdings and upgrade capacity. Ongoing support, upgrades and continuous testing are available as retainers, so ask which items recur and what they cost. Request a responsibility matrix that assigns each task to you or to the partner, and a handover acceptance checklist.

The cost follows the scope: how many integrations and workflows you need, how many environments (development, test, production) must exist, which edition of the tool you run, whether custom nodes or code must be written, and how much testing your change process requires. Infrastructure is one cost, paid to your cloud or data center provider. The partner's fixed-scope work is a separate cost, and it is quoted from the written scope rather than from a price list. Ask every bidder to price each integration, each environment and custom node separately so you can see which items move the total.

Recurring costs fall into four groups: infrastructure, upgrades, maintenance of custom nodes or flows, and any subscription fees. The n8n pricing page lists the free self-hosted Community edition, and says SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans, so check which edition covers your requirements before you commit. Node-RED is Apache-2.0 licensed, and Temporal Server is MIT licensed, so their core software carries no license fee, though support contracts and managed options are separate purchases. Ask the partner to state the upgrade and node maintenance effort each year in writing.

The duration depends on how many systems are connected, how mature the credential and approval processes are, and whether high availability or queue mode is required. DeployOpen does not publish a standard timeline. A timeline is stated only in the written scope, which lists the integrations, environments, handover items and acceptance criteria agreed before work starts. Ask each partner to show the milestones behind its estimate, and to state which of them depend on your teams, such as access approvals or system owner reviews.

Before work starts, you need to name a system owner for each integration, provide service accounts and credentials through an approved vault or secret process, and confirm who approves changes to production workflows. The partner also needs network access to the systems being connected, a hosting environment in your cloud account or data center, and a decision on which license terms apply to your use. Missing owners and slow approvals are the most common causes of schedule slippage, so agree on these responsibilities in the scope document.

Yes, if the team has the skills to operate the chosen platform, and the handover is planned for it. Running n8n or Temporal in production requires someone to manage upgrades, backups, credential encryption keys, access control and failure alerts. Temporal's documentation, for example, says a self-hosted server must be upgraded one minor version at a time, and that its default Authorizer allows every API request until you configure one. Ask the partner what runbooks, training and documentation it hands over, and whether an ongoing support retainer is available for upgrades and continuous testing.

According to n8n's pricing page, SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans, and Enterprise adds dedicated support with an SLA. n8n SAML single sign-on is also available on those plans. Multi-main high availability is restricted to Enterprise self-hosted deployments. Files marked .ee require an n8n Enterprise License, and the Sustainable Use License limits use to internal business purposes, so have counsel confirm your use case. Confirm current plan contents directly with n8n before the scope is signed, since pricing pages change.

Engineers should check four things. First, whether the proposal explains how the main instance hands executions through Redis to workers that read and write PostgreSQL, and how those components are sized and monitored. Second, how the n8n encryption key is shared with all worker and webhook processor nodes, and where it is stored and rotated. Third, whether multi-main high availability is in scope, and if so, whether the licensing supports it. Fourth, how failed executions alert a named person. Ask the partner to show these in a sample architecture before you accept the proposal.