Workflow automation requirements checklist for buyers

How to use this workflow automation requirements checklist

This checklist turns the choice between n8n, Node-RED and Temporal, or a decision to build on one of them, into written requirements that someone can verify. A team with integrations to connect and manual tasks to remove needs to know which platform fits each process before it signs anything, and the fastest way to get there is to score every requirement against a proof rather than a feature claim. A proof is a test run in your environment, a configuration file you can inspect, or a clause in the license you have read. A vendor sentence saying SSO is supported does not count until someone has logged in through your identity provider with a test account and recorded the result.

The checklist covers six areas where the platforms differ most. The first is processes and volumes: which workflows run, how often, and how many executions a month, since n8n counts one execution as a whole workflow run regardless of steps, which changes the cost picture. The second is credentials and environments: where secrets are stored, who holds the encryption key, and whether development, test and production are separated with Git. The third is error handling, retries, SSO, high availability and license terms, which decide whether a flow can be operated safely after launch. The fourth is ownership: each workflow needs a named owner, a reviewer for changes, and a retirement plan. Work through each area with the people who will run the flows, not only the people who will build them.

Use the checklist as a scoring sheet. Mark each requirement as met, partly met or unmet, and attach the evidence. For example, an n8n Community edition deployment will not meet a requirement for SSO or environments with Git, because the pricing page places those in the Business and Enterprise plans, so confirm the current tier before you write it down. Likewise, Temporal ships with a noopAuthorizer when none is configured, so the access control requirement is unmet until you configure one. Ask your partner to show the configuration, the test output and the license text for each item, and keep that evidence with the requirement so an auditor or a new engineer can follow it later.

Functional requirements every workflow automation platform must meet

This table lists the functional requirements to settle before choosing n8n, Node-RED or Temporal, what each one matters for, and how to verify it. Use the last column as a proof task: run the pilot against the forecast volume and trigger mix, not a demo workflow. Requirements that fail the proof task usually change the platform choice, so treat them as gates rather than preferences.

Requirement	Why it matters	How to verify
Process and integration inventory	Every workflow needs a named source, target and owner, which sets the connector and node list the platform must support	Signed inventory listing each flow, its systems, data classes and owner, reviewed against the candidate's node or SDK coverage
Expected run volumes	Execution counts drive sizing, queue workers and, for Temporal, visibility storage choices	Forecast peak and average runs per workflow, then a load test at that forecast in the pilot environment
Execution counting	n8n counts one run of a whole workflow regardless of steps, while other tools may bill per step or per action, changing cost and sizing	Confirm the counting rule in the vendor's current pricing terms and model a sample flow with its real step count
Trigger types (schedule, webhook, event)	Each trigger type has different availability, retry and load behavior, and webhooks often need a public endpoint	Build one pilot flow per trigger type and test a missed schedule, a duplicate webhook and a burst of events
Custom code in JavaScript or Python	Business logic often outgrows visual nodes, and code needs review, testing and access control	Run a code step that transforms a sample payload and confirm which languages and libraries the platform permits in production
Node library and community nodes	n8n advertises more than 1,500 integrations and Node-RED's library holds over 5,000 community nodes, but unvetted nodes add supply chain and maintenance risk	Maintain an approved node list, review source, maintainer activity and license for each node, and test upgrades before promotion
Credential storage and encryption key handling	Credentials are the highest-value data in automation, and queue-mode workers need access to the encryption key	Confirm where credentials are stored, how the key is rotated and shared with workers, and test restore from backup
Environments and Git versioning	Changes should move from development to production through review rather than edits in the live editor	Confirm environment promotion and Git support on the plan you will buy, then promote a test change through both environments

Which platform fits which requirement profile

n8n suits teams that connect SaaS applications, internal APIs and databases through a visual canvas, with custom JavaScript or Python where a step needs code. Its catalog of more than 1,500 integrations covers much of a typical business task list, and the Community edition is free to self-host. The requirements that need extra work are the ones tied to paid features and licensing. SSO and LDAP, environments with Git, and log streaming are listed on the Business and Enterprise plans, and multi-main high availability is restricted to Enterprise self-hosted deployments.

Licensing: The Sustainable Use License permits use for your own internal business purposes, so internal automation fits, but offering n8n to customers as part of a product needs a separate review.
Credentials: Queue mode requires the main instance's encryption key on every worker, so key distribution must be designed before scaling out.
Environments and Git: Promotion between development and production is a paid feature, so budget for it or build a manual export and review process.
Identity: SAML single sign-on is available on Business and Enterprise plans, with setup guides for Okta and Azure AD.
Execution data: Because an execution counts as one run of a whole workflow, volume planning should focus on run frequency and data retention rather than step counts.

Confirm current plan contents with n8n's pricing page before you commit to an edition, since feature placement can change.

Which security requirements decide where credentials and execution data live

Credentials, editor access, API authorization, network exposure, payload encryption and access logs decide whether workflow data stays inside your infrastructure and who can change it. Each card names a default or dependency that can weaken that control, and how to confirm it in your own environment before the platform goes live.

Credential storage and encryption keys

Workflow platforms store connection secrets in their database, protected by an encryption key. In n8n queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can read those credentials. Decide who holds that key, where it is stored, and how it rotates, because anyone with the key and database access can decrypt every stored credential. Verify that the key is held in a secrets manager, that workers receive it through a controlled path, and that a restore test recovers credentials with the correct key.

Editor and admin access

Node-RED is not secured by default, so anyone who can reach its IP address can deploy changes to running flows. Configure HTTPS, username and password or OAuth and OpenID authentication through Passport for the editor and admin API, and basic authentication for HTTP nodes. Confirm that the editor is not exposed beyond the internal network, that each editor user maps to a named person, and that deployments are logged. Check the same questions for n8n and any other visual editor your team runs.

API authorization

Self-hosted Temporal uses a default noopAuthorizer when no Authorizer is configured, and that setting allows every API request with no authentication or access control. Before any workflow runs against shared namespaces, configure an Authorizer and a ClaimMapper that maps JWT or certificate claims to namespace roles. Verify by attempting an API call with an identity that lacks the right role and confirming it is refused. Record which roles can start, terminate and read workflows in each namespace.

mTLS and network isolation

Temporal services should run on hosts that the public internet cannot reach, with access limited to trusted internal networks. Self-hosted Temporal supports mTLS with separate settings for internode and frontend traffic, so service-to-service and client connections can each be authenticated. Verify from outside the trusted network that the frontend port does not respond, confirm that internode traffic requires certificates, and review firewall rules after each upgrade or Helm change.

Payload encryption

Workflow inputs and outputs often carry personal or financial data, and the platform does not encrypt them automatically in every setup. Temporal supports payload encryption through custom codecs and a codec server, so data is encrypted before it reaches the server. Decide which fields must be encrypted, who may run the codec server, and how keys for it are separated from the credential key. Verify by inspecting stored payloads in the database and confirming they are unreadable without the codec.

Access logging and execution records

Execution history shows who changed a workflow, which credentials it used and what data moved, so it is the main evidence for reviews of production changes. Confirm which audit events the platform records, where logs are sent, how long they are kept, and whether a person with edit rights can delete them. Where the workflow supports a high-risk AI system, Article 19(1) of the EU AI Act requires logs to be kept for at least six months unless other law provides otherwise. Verify by reviewing a sample change from start to finish and checking that the log shows the actor, the time and the affected workflow.

How environments, Git versioning and change control should work

Separate development, test and production environments are the first control to specify, because they are what lets a team change a workflow without changing the one that moves customer or finance data. Each environment needs its own credentials, its own connections to source and target systems, and its own execution history, so that a test run can never write to a production ledger by accident. Ask the partner to show where each environment runs, which systems it can reach, and how a workflow moves from one to the next without anyone re-creating it by hand.

Git is the mechanism for that promotion, and the edition you buy decides whether it is built in. According to n8n's pricing page, environments with Git are included only in the Business and Enterprise plans, so the reader must confirm that the chosen edition covers the need before the design assumes it. If the edition does not, the fallback is exporting workflow definitions to a repository on a schedule or through a pipeline, which the partner must build and maintain. Require that every production workflow exists as a version-controlled export, that each change is traceable to a commit and an author, and that credentials are referenced rather than stored in those exports.

Change control then decides who may promote what. Define an approval step for every production change, with a reviewer who is not the author, and record the approval against the commit. Limit deploy rights to a small named group, separate from the people who build workflows, and keep an emergency path with after-the-fact review. Ask the partner to document this model as a runbook, including how a rollback works when a promoted workflow fails, since that is the moment the controls are tested.

Which integration requirements to test before committing

Integrations decide whether a workflow platform works in practice, and they are the hardest requirements to judge from a feature list. The cards below cover the connectivity, identity and data-handling questions to settle in a test environment before you choose n8n, Node-RED or Temporal.

Source and target connectivity

List every source and target system the workflows will call, with its exact product version, authentication method and network path. Confirm that each connector or node works with those versions in a test environment, not only in the vendor's demo. Record which credentials each system needs, who owns rotation, and whether the platform can store them encrypted on premises. A connector that works on a current SaaS API may still fail against an on-premises ERP release that is two versions behind.

SSO and directory integration

Decide how administrators and builders will sign in before the platform goes live. n8n SAML single sign-on is available on the Business and Enterprise plans, with setup guides for Okta Workforce Identity and Azure AD, so check whether your identity provider and group mapping need the paid tier. For Temporal, confirm that OIDC single sign-on for the Web UI matches your identity provider's claims. Test role mapping with real groups, because a user who can sign in but lands with the wrong permissions is a common failure.

API gateway placement

Decide whether workflows call internal APIs directly or through a gateway such as Apache APISIX or Kong. A gateway adds authentication, rate limits and logging in front of systems that were never built for automated callers, but it also adds a hop and another component to operate. Confirm which team owns gateway routes, how workflow service accounts are issued and scoped, and whether the gateway can enforce the same limits for flows as it does for other clients.

Event and webhook ingress

Map every trigger that starts a workflow, whether a webhook, a message queue, a file drop or a schedule. Webhook endpoints are exposed to callers, so confirm which ones must be reachable from outside your network and which can stay internal. In n8n queue mode, the main instance handles triggers and webhooks, so size and secure that instance accordingly. Test what happens when a sender retries a delivery, since duplicate events can start duplicate workflow runs.

Data format and schema handling

Document the payload formats each integration sends and expects, including JSON versions, XML, CSV and character encodings. Decide where schema validation happens and what the workflow does when a field is missing or renamed by an upstream team. Silent schema drift is one of the most expensive integration failures because workflows keep running and write bad data downstream. Ask each system owner for a sample payload and a change notice process before the first production flow is built.

Connectivity from workers to databases

Trace the network path from each worker to the databases it reads and writes. In n8n queue mode, workers read and write workflow data in PostgreSQL, and every worker must hold the same encryption key to read stored credentials. Temporal workers and services also need reliable access to their persistence and visibility stores. Confirm firewall rules, connection pool limits, failover behavior and which database versions the platform supports, and keep these services on hosts that are not reachable from the public internet.

Operational requirements for error handling, retries and high availability

This table sets out the operational requirements a workflow automation platform must meet once flows run in production, with a failure test and a restore test for each. Read each row as a question to put to your team or implementation partner: if the answer is not written down and tested, the requirement is not met. The main takeaway is that high availability on n8n depends on the license edition and on shared encryption keys, and that Temporal is safe only after its authorization and visibility stores are configured deliberately.

Requirement	Why it matters	How to verify
Error handling and retry policy per workflow	Each flow needs a defined response to failed steps, such as retry count, backoff and whether a failure stops downstream writes. Without it, a failed payment or record update can be silently repeated or dropped.	Force a failure in a non-production copy of each flow (for example, an unreachable API) and confirm retries, the final error state and that no duplicate writes occur.
Alerting to a named owner	An error that reaches a shared inbox or nobody's inbox is a production incident without a responder. Each workflow should map to one accountable person or team and an escalation path.	Trigger a failure and confirm the alert reaches the named owner within the agreed window, then confirm the escalation contact receives it when the owner is absent.
Execution history retention and log streaming	Execution data can contain personal or financial values. Retention periods must match your policy, and logs must reach your central monitoring. n8n places log streaming in the Business and Enterprise plans according to its pricing page.	Confirm the retention setting in the instance, run a test execution, then check that the record appears in your log platform and is purged when the retention period ends.
Queue-mode workers with Redis and PostgreSQL dependencies (n8n)	In queue mode the main instance passes executions through Redis to workers that read and write PostgreSQL. Loss of Redis or the database stops processing, and all workers and webhook processors need the main instance's encryption key to read credentials.	Stop one worker and confirm jobs continue. Stop Redis or PostgreSQL in staging and record the recovery behavior. Restore the database and confirm workers start with the same encryption key.
Multi-main high availability (n8n Enterprise self-hosted only)	Running several main instances for high availability is restricted to Enterprise self-hosted deployments, so it is not available in the Community edition or n8n Cloud. Teams that plan for it on a lower tier will find the design invalid at procurement.	Get the written license scope for the chosen edition, then test failover by stopping the active main instance and confirming webhooks and triggers resume on another.
Persistence store for Temporal	Temporal keeps workflow state in a supported database. Only specific versions of Cassandra, PostgreSQL and MySQL are tested, and SQLite is for development only. The choice determines backup, restore and upgrade procedures.	Confirm the database version against the Temporal persistence documentation, then restore a backup into a clean environment and run a sample workflow to completion.
Visibility store for Temporal (Elasticsearch or OpenSearch beyond a few executions)	Visibility powers search and listing of executions. Cassandra visibility was removed in version 1.24, and Elasticsearch or OpenSearch is recommended for anything beyond a few workflow executions, so a database-only design may fail to scale.	Load test visibility queries at your expected execution volume, then stop the visibility cluster and confirm the impact on running workflows and on search.
Backups and restore for both platforms	A backup that has never been restored is unproven. Backups must cover workflow definitions, credentials and the encryption key (n8n), and the persistence and visibility stores (Temporal), stored separately from production.	Once per release cycle, restore the full set into an isolated environment, then confirm flows run, credentials decrypt and in-flight Temporal workflows resume.
Upgrade path (Temporal one minor version at a time, schema before server)	Temporal guarantees backward compatibility only between successive minor versions, and release notes may require schema upgrades before server upgrades. Skipping steps can leave a cluster unusable.	Rehearse the upgrade on a copy of production, run the schema step first where the release notes require it, and confirm workflows and workers still operate before promoting.

Why license terms and paid editions belong in the requirements

The license decides who may run the software and for what purpose, so it belongs in the requirements before any platform is chosen. n8n is licensed under the Sustainable Use License, which allows use or modification only for your own internal business purposes or for non-commercial or personal use. Distribution is permitted only free of charge and for non-commercial purposes. Any file marked .ee in the repository is outside that license and requires a valid n8n Enterprise License, so a team that plans to use those features needs that entitlement in writing before the design is fixed.

Edition limits matter as much as the license text. n8n's pricing page places SSO and LDAP, environments with Git, and log streaming only in the Business and Enterprise plans. If your requirements call for SAML single sign-on, promotion of workflows between environments through Git, or exporting execution logs to your SIEM, those needs translate into a paid edition, and the Business plan is currently self-hosted only. Confirm the current plan contents directly with n8n, because pricing pages change, and record the edition you are pricing against in the requirements document.

By contrast, Temporal's server is licensed under the MIT license and Node-RED is licensed under Apache-2.0. Both permit internal use and redistribution under their own terms, and neither gates SSO or environments behind a commercial edition in the way n8n does. That does not remove the need for review. Ask legal counsel to confirm whether your planned internal use, and any offering of automation to customers inside a product, is permitted under each license and the terms of each dependency. Record that decision alongside the owner of each workflow so the license position is revisited when scope changes.

How to assign who owns each workflow

This sequence gives every workflow a named business owner, technical owner and credential owners, plus a review and retirement rule, so the automation keeps running and stays accountable after staff changes.

Build a complete workflow inventory
List every workflow running in each n8n, Node-RED or Temporal environment, including the ones built by individuals outside the central team. For each entry, record the purpose, the trigger, the systems it connects to, the data it moves and the environment it runs in. Include scheduled jobs, webhooks and any flow that was switched on for a short project and never removed. The output is a single register that the platform team agrees is complete, checked by comparing it against the exported workflow list from each instance and against the execution logs for the last review period.
Name a business owner for purpose and data
Assign one accountable person in the business function that relies on each workflow. This owner approves why the workflow exists, which personal or financial data it may touch, and who may request changes to its scope. Business owners do not edit the flow itself. Record the name, role and approval date in the register. The step is complete when every inventory entry has a business owner who has signed off on its purpose and data categories, and any workflow without a sign-off is flagged for suspension until one is recorded.
Assign a technical owner for maintenance
Name a technical owner who maintains the flow, reviews changes, handles upgrades of the platform and answers for failures. This should be a named engineer or team, not an individual's personal account, so that the role continues when someone moves on. Where the platform supports environments and Git versioning, the technical owner should be the only role able to promote changes from a test environment to production. The step is complete when each workflow shows one technical owner and a backup contact, and the register lists the repository or export location holding its current version.
Assign a credential owner for each connected system
Credentials are owned separately from workflows because one credential can serve several flows. For each connected system such as an ERP, CRM, directory or database, name a credential owner who is responsible for the service account, its scope, its rotation and its revocation. Confirm where credentials are stored and who holds the encryption key that protects them. The step is complete when every credential in the instance is linked to a named system owner and a documented revocation path, and no credential is shared under a personal login.
Assign owners for custom nodes and community packages
Custom nodes, community packages and any code written inside a workflow need an owner too, because they run with the same access as the flows that call them. For each one, record the author or team, the source repository or package origin, the version in use, the license and who approves updates. Confirm the license terms of each package with the vendor or its repository before production use. The step is complete when no executable component is in use without a named owner, and each one has an approved version and a documented update decision.
Set a review cadence for each workflow
Agree a review schedule that matches the risk of each workflow, with higher-risk flows reviewed more often than low-impact internal notifications. At each review, the business owner confirms the purpose and data are still valid, the technical owner confirms the flow still works with current platform versions and the credential owner confirms access is still needed. Record the review date and outcome in the register. Ask your implementation partner to propose a cadence and confirm it in writing. The step is complete when every workflow has a scheduled review date and the register shows the last completed review.
Write a retirement rule and transfer ownership
Define the conditions under which a workflow is suspended or retired, such as the owner leaving the role, the connected system being decommissioned, no executions over an agreed inactivity period or a failed review. Require that ownership moves to a named successor before a departing owner's access is removed. When a flow is retired, disable its triggers, revoke its credentials if no other flow uses them and archive its exported version. The step is complete when the rule is written, approved by the business owners, and tested on at least one workflow whose ownership is transferred.
Confirm ownership survives staff changes
Check that the register, not individual memory, identifies every owner. Run a test in which one named owner is removed from the list and confirm that the escalation path reaches a successor and that alerts about failed executions are routed to a team mailbox or group rather than a personal address. Repeat this check at each review. The output is a short record that shows every workflow has at least two people able to act on it, and that the register is updated whenever someone joins, moves or leaves a role.

What buyers ask before choosing a workflow automation platform

How much does a self-hosted workflow automation project cost?

The cost comes from four places: the software licence edition, the infrastructure you run it on, the number of integrations and environments, and the time spent building and maintaining workflows. The free n8n Community edition has no licence fee, but the pricing page lists SSO and LDAP, environments with Git, and log streaming only on the Business and Enterprise plans, so those features add a paid licence. The Business plan is listed at 667 euros per month billed annually and is currently self-hosted only, and Enterprise is custom priced. Infrastructure, backups and the team that operates the platform recur every year. Ask for a written quote that separates one-time build work, licence fees, infrastructure and ongoing support, and that names which edition each feature requires.

How long does a workflow automation implementation take?

The timeline depends on how many processes are in scope, how many systems each one touches, how many environments you need, and how quickly your owners approve designs and test results. A first workflow that connects two systems with simple error handling takes less time than a set of flows that handle credentials for several systems, queue-mode workers and an approved change process. Temporal and high-availability designs add infrastructure and verification steps. Ask the implementation partner to list each milestone, the dependencies between them and the internal reviews they assume, and to state the timeline in the written scope rather than as a verbal estimate.

What does our internal team need to provide during the project?

Your team needs to provide four things. Process owners must describe each workflow, its inputs, its expected outputs and the exception cases. Engineers must grant system access, such as API credentials or service accounts, in a test environment first. Test data that resembles production, with personal or regulated fields masked where needed, lets the team verify behavior before go-live. Approvers must sign off on designs, credential ownership and production changes. Name these people before work starts, and write their review windows into the scope so that delays are visible and assigned.

Can our team build and run workflow automation without a partner?

Yes, many teams do, especially when they already run Linux, containers, a secrets store and a change process. The harder parts are operational: running n8n in queue mode with a shared encryption key, keeping Temporal services off the public internet, securing the Node-RED editor, upgrading Temporal one minor version at a time, and documenting who owns each flow. Assess your skills in those areas honestly. A partner can take on part of the work, such as the initial build, hardening, backup design or the compliance evidence, while your team keeps ownership of the workflows and the platform.

Does the free n8n Community edition include SSO and Git versioning?

No, based on the pricing page. According to n8n's pricing page, SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans. The SAML single sign-on documentation also states that SAML is available on the Business and Enterprise plans. Community edition users can still build and run workflows, but they would need another way to manage versions, such as exporting workflow JSON into your own Git repository through a documented process, and a separate way to control who logs in. Confirm the current plan entitlements on the pricing page before you decide, because plan contents can change.

How is a fixed-scope engagement defined?

A fixed-scope engagement starts with a written scope that names the processes to automate, the systems and integrations involved, the environments to deliver, the deliverables, the responsibilities of each party and the agreed timeline. DeployOpen works this way for most engagements, and the scope is agreed in writing before work starts. Ask for a document that lists what is out of scope, such as new integrations added later, changes to upstream systems, or ongoing support. Also ask how changes are handled, who approves them and how they affect the quote. DeployOpen does not publish a price list, so the quote follows from the written scope.

Which questions should the scope answer before we request a quote?

A useful scope answers these questions in writing: which processes and integrations are in scope, expected run volumes, where credentials and execution data will be stored, how many environments are needed, how errors are retried and who is alerted, whether SSO is required, whether high availability is required, which licence edition applies to internal use, and who owns each workflow after handover. Each answer changes the infrastructure, licence and effort lines of the quote. Incomplete answers usually show up later as change requests, so resolve them before work starts.

How to score vendors and partners against this checklist

Score every requirement in this checklist as a must-have, should-have or later. A must-have is a condition the platform or partner cannot operate without, such as credential encryption at rest, SSO for editors and admin access, a license that permits your intended use, and a documented way to restore execution data. Require written evidence for each must-have: a configuration export, a dated test result, a license clause quoted from the publisher's own file, or a named control in the partner's runbook. A claim in a sales deck is not evidence. Reject any platform that fails a security or license must-have, regardless of how well it scores elsewhere. For n8n, for example, check whether your use falls within the Sustainable Use License and whether the features you need, such as SSO, environments with Git or multi-main high availability, sit in a paid edition, since the pricing page places several of them only in the Business and Enterprise plans.

Ask each partner to run the same test on the same workflow. Choose one representative flow from your estate, ideally one that calls a system of record, handles credentials and fails in a realistic way. Ask the partner to build or migrate it in a non-production environment, promote it through your intended environments, force a failure at a named step, and show the alert, retry behavior, execution record and rollback. Then ask them to demonstrate who can edit the flow, how the change is approved and where the credential and encryption key sit. For Temporal, include a check that the Authorizer is configured, because an unconfigured self-hosted server accepts every API request. Compare the outputs side by side rather than comparing presentations.

Close the evaluation by requesting the following in writing with the proposal: the list of components and versions to be installed, the queue or worker topology and where each component runs, the credential and encryption key management design with the named owner of each key, the environment and promotion model, the alerting and error-handling standard, the license analysis for every product and every custom node, the list of paid features the design depends on, the handover plan naming the owner of each workflow after go-live, and the fixed scope and deliverables. Ask the partner to state which items they will not cover. A proposal that cannot answer these questions in writing is not ready to be scored as a must-have pass.

How DeployOpen scopes and delivers workflow automation requirements

DeployOpen turns a workflow automation requirements list into a written, fixed-scope plan for a self-hosted platform such as n8n, Node-RED or Temporal inside your own infrastructure. The work covers the processes, integrations, credential handling, environments, error paths and ownership model you decide on, then builds, documents and hands them over.

How we scope

Inventory the processes and integrations in scope, with run volumes and the systems each flow touches.
Confirm the target platform, edition and license position for internal use before any build starts.
Record credential storage, environment layout, SSO, high availability and ownership decisions in the written scope.

How we build

Deploy the chosen platform in your cloud accounts, data centers or air-gapped network, with credentials and execution data kept on premises.
Configure environments, Git versioning, error handling, retries and alerting for each agreed workflow.
Test workflows against defined failure cases, including credential rotation and worker restarts, before release.

How we hand over

Document each workflow's purpose, owner, inputs, outputs, retry rules and change procedure.
Train named staff to maintain flows, promote changes through environments and respond to alerts.
Deliver the runbooks, configuration records and evidence your change control and audit teams request.

How we support

Offer ongoing support, upgrades and workflow maintenance as a retainer after handover.
Patch and upgrade the platform in line with vendor release notes, with changes tested in non-production first.
Review ownership, license and integration changes with your team whenever scope or usage grows.

Workflow automation requirements checklist