Why public sector workflow automation starts with hosting and licensing
An agency that connects case intake, permit or benefits back offices and partner agency feeds should settle three questions before it builds anything: where the flows and their credentials may run, whether the license of the chosen tool allows the agency to use it, and what class of data the flows will carry. These decisions shape the architecture more than any individual connector does. A flow that reads criminal justice information or controlled unclassified information sits under different safeguards than one that moves public notices, and the hosting location and license terms follow from that classification.
Licensing comes first for n8n. Its Sustainable Use License permits use for your own internal business purposes, so an agency running flows for its own operations is generally within scope, but distributing the tool or offering flows as a service to other bodies is not. Files marked .ee need a separate n8n Enterprise License, and SSO and LDAP, Git-based environments and log streaming sit in paid plans, so confirm which features the agency needs before the design is fixed. Ask counsel to read the current license text and the pricing page, not a summary. For the short answer, use n8n for internal integration flows, Node-RED for edge or message flows where Apache-2.0 terms and lightweight deployment fit, and Temporal for long-running cases that must survive restarts, waiting periods and retries. Temporal's MIT license and self-hosted server suit cases that can take days or weeks to close.
Data classification then sets the hosting rules. For criminal justice information, the FBI CJIS Security Policy governs, and CJIS Security Policy version 6.1 details the encryption requirements that a state's own bulletin describes. Controlled unclassified information on non-federal systems points to NIST SP 800-171 for the agency's requirements. Confirm with the data owner which authority applies to each flow, and record it in the workflow inventory before the first credential is stored.
Which public sector rules shape the automation build
This table maps each public sector rule that tends to reach automation projects to what it asks for and what it means for hosting, key lengths, scanning and change control. Read each row as a question to put to the agency's compliance owner before the flow design is fixed. Applicability depends on the data each flow handles and the agency's legal status, so the table is a starting point, not a determination.
| Requirement | What it means for the automation build | Evidence an assessor will expect |
|---|---|---|
| NIST SP 800-53 baselines via OMB and FISMA | Agencies select low, moderate or high baselines, which select 149, 287 and 370 controls and enhancements respectively. Use the chosen baseline to set hosting boundaries, access control and logging for every flow. | A system security plan mapping each flow platform component to the selected baseline's controls, plus the Inspector General's view of the agency's system security |
| CJIS Security Policy v6.1 encryption | For criminal justice information in transit and at rest outside physically secure locations, use FIPS 140-3 certified modules or AES with at least 256-bit keys. Confirm how n8n credential encryption keys and Temporal payload codecs meet this. | Cryptographic module certificates, key length configuration records, and a description of where CJI is held in each execution store |
| CJIS Security Policy v6.1 vulnerability scanning | Scan platform hosts and containers at least monthly and keep the workflow engine, databases and connectors on the same scan cycle. | Dated scan reports, remediation tickets and proof that findings were closed or accepted with a documented reason |
| 32 CFR 2002.14(h)(2) and CUI on non-federal systems | Where a contractor or partner runs flows that handle controlled unclassified information, NIST SP 800-171 is the default requirement set unless the CUI category specifies other safeguards. Confirm the applicable CUI category before choosing hosting. | System requirements mapped to SP 800-171, and a boundary diagram showing which flows and execution data touch CUI |
| FedRAMP scope under OMB M-24-15 | Cloud services that store or process federal information on behalf of an agency fall in scope. A self-hosted flow platform inside the agency's own infrastructure is usually outside FedRAMP's cloud scope, but any managed or cloud-hosted engine or connector used for federal data may not be. | Written confirmation of the hosting model and a list of any third-party cloud services that touch agency data |
| ADA Title II WCAG 2.1 dates for citizen-facing flows | Citizen-facing forms, portals and mobile apps built on workflow outputs must meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts (28 CFR 35.200). Treat intake screens and notifications as in scope. | Accessibility test results against WCAG 2.1 AA and a remediation log for each citizen-facing interface |
| NIS2 applicability to public administration | NIS2 covers central government entities regardless of size and lists public administration as a high-criticality sector. Member States may extend it to local administration, and it excludes entities in national security, public security, defense or law enforcement. Confirm the agency's status under national law. | A scope determination from the competent national authority or legal counsel, and risk management records for the automation platform if in scope |
| Change control for citizen-facing flows | Route each workflow edit through review and approval, keep workflows in version control, and promote tested changes between environments rather than editing production directly. | Approved change records, version history, test results and a log of who promoted each change to production |
How the n8n license changes what an agency can run
When an agency runs n8n only for its own internal business purposes, the Sustainable Use License generally permits self-hosting and modification. This covers flows that move case data between the agency's own case management, document, payment and identity systems. The license restricts the purpose of use rather than the type of organization, so the question for counsel is whether every flow stays within the agency's own internal operations.
- Internal purpose: Flows that serve the agency's own casework and administration sit within the permitted internal use described in the license.
- Enterprise files: Any file with
.eein its name or directory is outside the Sustainable Use License and needs a valid n8n Enterprise License. Confirm whether your build or custom nodes touch those paths. - Plan gating: SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans, so budget for them if identity integration or promotion through environments is required.
- Edition choice: The free Community edition lacks these features, which matters for audit trails and change control on citizen-facing flows.
- Counsel review: Ask counsel to confirm that each category of flow is internal business use and to record that decision.
Confirm with counsel and your procurement office whether the agency's internal use is the only use before deployment.
A shared automation service that one agency runs for other public bodies, or that a contractor runs for several clients, moves beyond the agency's own internal operations. The Sustainable Use License limits use to your own internal business purposes or non-commercial use, so a service that processes work for a separate organization needs a closer reading. Distribution is limited to free, non-commercial purposes, which affects how a contractor packages flows for other clients.
- Third-party operation: Running n8n to automate another organization's processes is a different situation from running it for your own operations, and the license wording should be read against that difference.
- Contractor delivery: A contractor that builds and hosts flows for several agencies should confirm whether its activity is internal business use for itself or a commercial service.
- Distribution limits: Passing a configured n8n instance or custom packages to another entity can count as distribution, which the license restricts.
- Enterprise requirements: Multi-tenant or large shared deployments may need Enterprise terms and the features that come with them.
- Alternatives: Node-RED is licensed under Apache-2.0 and Temporal's server is MIT licensed, so their terms differ and may fit a shared model better.
Ask counsel to review the service model in writing before any agency or contractor agrees to share an instance.
When a vendor embeds n8n inside a product that citizens or public users access, the license question changes again. The product is offered to third parties and generally falls outside the internal purpose the Sustainable Use License permits. Vendors and integrators should not assume that a self-hosted build is covered simply because the deployment runs on government infrastructure.
- Offering to users: A product that gives citizens automated case or form processing built on n8n is a distribution or commercial offering that needs its own license terms.
- Commercial licensing: Confirm with n8n directly whether an Enterprise License or another agreement covers the product model.
- Citizen-facing flows: Change control, logging and access rules still apply to flows that citizens trigger, so the product's operating model must be documented alongside its license.
- Vendor responsibility: The vendor carries the license risk, and the agency should ask for written confirmation of that position in the contract.
- Option review: Compare Apache-2.0 Node-RED and MIT-licensed Temporal, which carry different terms and may suit a product offering better.
Before procurement, ask the vendor to show the license basis for the product in writing.
Which platforms fit public sector case and integration work
Public sector case intake and agency integrations rarely fit one tool. The cards below pair each open-source platform with the job it handles best, the license or operational constraint to review first, and the check to run before a build starts. Read them as a shortlist to test against your own case volumes, data classes and procurement rules.
n8n for agency integration flows
Use n8n for connecting agency systems through API calls, file transfers and notifications, with a visual canvas that caseworkers' technical staff can review. The constraint is licensing: the Sustainable Use License covers internal business use, but files marked .ee need an n8n Enterprise License, and SSO and log streaming sit on the Business and Enterprise plans. Confirm whether any flow will be offered to other agencies or contractors before you commit to it.
Node-RED for Apache-2.0 message flows
Node-RED suits message-level flows, such as forwarding device or form events into an agency message bus or case queue, where the Apache-2.0 license imposes no internal-use restriction. It is a good fit for flows that run close to data sources on edge hosts. Check who maintains flows after handover, how the editor is access-controlled, and whether the flow editor is reachable only from trusted networks.
Temporal for long-running cases
Temporal provides durable execution, so a case that waits weeks for documents, a payment or a statutory deadline keeps its state through retries, timers and server restarts. Its server is MIT licensed, but self-hosted Temporal uses a noop authorizer by default, which allows every API request, so authorization, mTLS and payload encryption must be configured before production. Confirm the persistence and visibility stores your operations team can support.
Flowable for BPMN human tasks
Choose Flowable when a case needs modeled BPMN steps, case management or human tasks such as caseworker approvals and eligibility reviews, with the process model visible to business owners. Flowable is Apache-2.0 licensed. Camunda 8 source code, by contrast, is limited to non-production use without a commercial license, so that difference should drive the shortlist. Confirm how task assignment maps to your identity provider and how process changes are approved.
Apache Airflow for scheduled batch transfers
Airflow fits scheduled batch transfers between agency data stores, such as nightly extracts, reconciliations or reporting feeds, where dependencies between jobs matter more than event handling. It is Apache-2.0 licensed and gives operators run history and alerting on failed tasks. It is not a substitute for durable case state, so keep long-running case logic in Temporal or Flowable. Confirm how job definitions are reviewed and who can trigger reruns against production data.
APISIX or Kong for controlled API access
An API gateway such as Apache APISIX or Kong puts authentication, rate limits and access logging in front of agency system APIs, so integration flows call services through one controlled point. Both are Apache-2.0 licensed, and APISIX also offers AI gateway features. Check which gateway version and plugins your security team has approved, and confirm that management interfaces are restricted to administrative networks rather than exposed to every integration consumer.
When Temporal replaces n8n for long-running cases
This sequence shows how a public sector team decides when a case must move from n8n to Temporal, how the Temporal workflows are built and hosted on agency infrastructure, and how the platform is upgraded and verified without breaking in-flight cases.
Identify cases that outlast a single run
The agency team and DeployOpen list the case types that wait for days or weeks, such as benefits or licensing applications that depend on documents from applicants or on decisions by other agencies. For each case, they record what must survive a restart, which steps need retries, and which steps need timers, such as a reminder after a missing document. Short, stateless integrations usually stay in n8n. The output is a written split between cases that stay in n8n and cases that move to Temporal, signed off by the process owner and the platform owner.
Model workflows and activities separately
DeployOpen engineers write the case logic as Temporal workflows, which hold orchestration state such as the current step, timers and pending signals. Each call to an agency system, document store or identity service is written as an activity, which can be retried independently and is where credentials are used. The team then confirms that workflow code contains no direct credentials or network calls to agency systems. The output is a workflow design document that maps every external call to a named activity with its retry and timeout settings.
Host Temporal on internal networks with access controls
The platform team deploys the Temporal Server in the agency's own data center or cloud account, on hosts that are not reachable from the public internet, as the Temporal deployment documentation advises. They choose the persistence store and, if needed, the advanced visibility store from the versions Temporal lists as supported. Before any workflow goes live, they configure an Authorizer, since a self-hosted server without one allows every API request. They also enable mTLS for internode and frontend traffic and connect the Web UI to the agency's single sign-on. The output is a verified access configuration that the security team reviews.
Protect case data with payload encryption
Case payloads often contain personal data, so the team defines a custom payload codec and, where agency policy requires it, runs a codec server inside the same network. Encryption keys are stored in the agency's key management service, and the access list for keys is kept separate from developer access. The team tests that a sample case payload is unreadable in the Temporal database and readable only by the intended workers. The output is a documented encryption design and a test record that the security team can keep as evidence.
Plan upgrades one minor version at a time
Before any upgrade, the platform team reads the release notes for the target version and checks whether a schema upgrade is required. Temporal guarantees backward compatibility only between two successive minor versions, so the team moves to the latest patch of the current minor line first, then steps up one minor version at a time. When release notes call for a schema change, the schema upgrade runs before the server upgrade. The output is a written upgrade plan with a rollback path and the exact version sequence, reviewed under the agency change control process.
Pin the Helm chart version for server 1.30 and later
If the agency deploys on Kubernetes with Helm, the team confirms the chart version before every change. Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so the chart is pinned to 0.73.1 or a later release that supports the chosen server image. The team stores the chart version and image tags in version control so that the running configuration can be reproduced. The output is a deployment manifest that matches the approved server version and a record in the change ticket.
Test in-flight cases before promotion
Before a new server version reaches production, DeployOpen and the agency test a copy of real case types, with synthetic data, that are paused mid-process when the upgrade starts. They confirm that timers fire, retried activities complete, and cases resume after a worker restart. Results are compared against the expected state for each case type. The output is a signed test report that the change board uses to approve the production upgrade, and that the agency can reuse for future audits of the case platform.
Keep the n8n and Temporal boundary under review
The agency keeps n8n for short intake and notification flows and uses Temporal only where the case design requires durable state. Each year, or when a new case type is added, the process owner and platform owner review the split and confirm that licensing terms for both tools still match how the agency uses them. The output is a current register of which workflows run on which platform, which feeds the change and access reviews for the public sector environment.
Securing Temporal and n8n before they touch case data
Temporal does not authenticate anything by default. If no Authorizer is configured, self-hosted Temporal uses the default noopAuthorizer, which allows every API request with no authentication or access control. Before any case workflow runs, the team should enable mTLS with separate settings for internode and frontend traffic, configure a ClaimMapper that maps JWT or certificate claims to namespace roles, install an Authorizer plugin that enforces those roles, and turn on OIDC single sign-on for the Web UI. Confirm in a test environment that a request without a valid client certificate or token is refused, and keep a record of that test for the security assessment file. Namespace roles should separate people who start and inspect cases from people who operate the cluster.
Network placement is part of the control set. The Temporal deployment documentation says Temporal services should run on hosts not reachable from the public internet, with access restricted to trusted internal networks. Agencies should confirm that the frontend, the persistence database and any visibility store (Elasticsearch or OpenSearch is recommended beyond a few workflow executions) sit in internal segments, and that citizen-facing intake reaches Temporal only through a controlled integration layer. For payloads that carry case data, a custom codec with a codec server can encrypt workflow inputs and results before they are written to workflow history, so an operator reading the persistence store sees ciphertext. Decide who holds the codec keys and how they are rotated before the first case is stored.
n8n queue mode spreads the encryption key across every node. In queue mode the main instance passes executions through Redis to workers, and the main instance's encryption key must be shared with all worker and webhook processor nodes so they can read credentials stored in the database. Any host that holds that key can decrypt the agency's stored credentials, so worker hosts need the same hardening as the main instance, and key distribution should be recorded as a controlled change. High availability is a separate decision: n8n multi-main setup is restricted to Enterprise self-hosted deployments and is not available in the Community edition or n8n Cloud. Agencies should confirm with n8n which edition and license terms apply to their use, and check the Sustainable Use License limits in the n8n license file with counsel before the workflows go live.
Integration points and deployment patterns for agency systems
Public sector automation touches case systems, identity, document stores, notifications and other agencies, and each connection carries a different data class. The cards below set out the pattern, the data class and the hosting location for each connection point so that architecture and compliance reviews start from the same map.
Case management and intake forms
Intake forms and case management systems are the usual starting point for workflows. Route form submissions through an API gateway into n8n in queue mode, with the main instance receiving webhooks and workers writing to the case system. Treat the data as personal and potentially criminal justice or benefits data, and host the main instance, workers and PostgreSQL inside the agency's accredited boundary. Confirm which fields the workflow stores in execution logs before going live, since execution data persists in the database.
Identity and SSO
Workflow editors, Temporal Web UI and service accounts must sit behind the agency identity provider. n8n SAML single sign-on is available on the Business and Enterprise plans, so confirm the edition before design. Temporal ships with a noopAuthorizer when none is configured, which allows every API request, so configure a ClaimMapper and Authorizer before any namespace holds case data. Map agency roles to namespace roles and keep service identities separate from named staff.
Records and document stores
Case files, attachments and records typically live in an agency document management system or object storage that the agency already operates. Workflows should pass references and metadata rather than copying documents into execution payloads. Temporal activities call the records API with scoped service credentials, and payload encryption through a custom codec protects data that does pass through workflow histories. Confirm retention rules for each record class before deciding how long Temporal histories are kept.
Payment and notification services
Benefit payments, fee collection and citizen notifications often run through outside providers. Model each external call as a Temporal activity with explicit retries and idempotency keys, so a timed-out payment request is not sent twice. Notifications such as SMS or email carry personal data to third parties, so record which provider receives which data class. Hosting the orchestration in the agency's own environment does not change where the provider processes the message, and that transfer needs its own documentation.
Partner agency exchanges
Data exchanges with other agencies usually pass through a controlled gateway with mutual TLS and per-partner credentials, such as APISIX or Kong, rather than direct database links. Keep partner-facing endpoints in a separate network zone, and confirm the data sharing agreement that governs each field. Temporal visibility for large case volumes should run on Elasticsearch or OpenSearch, which Temporal recommends beyond a few workflow executions and which must be sized and hosted in the same accredited boundary as the case data it indexes.
Logging and evidence stores
Audit trails for automated decisions need a store that the operations team cannot silently edit. Send n8n log streaming output and Temporal event histories to a write-once or access-restricted store inside the agency boundary, with a separate retention period from operational data. Where a flow supports a high-risk AI component, the EU AI Act requires automatic event logs kept for at least six months under Article 19(1), so confirm whether any step in the flow falls under that obligation before setting retention.
Evidence auditors and oversight bodies ask for from automation
This table maps each piece of evidence an assessor or oversight body may request to the component that produces it in a public sector automation estate. Read it as a checklist of what to configure and retain before an assessment begins, not as proof of compliance. Evidence like this prepares readiness for assessment and does not replace an independent audit.
| Evidence | Produced by | What to confirm before an assessment |
|---|---|---|
| Execution history and audit logs | n8n execution records and Temporal workflow event history | Retention periods are set in your configuration, log streaming is available only on Business and Enterprise n8n plans, and logs are shipped to storage you control |
| Change approvals for workflow edits | Git versioning and promotion across dev, test and production environments | Each production change links to a reviewed commit, approver and deployment record, and developers lack direct production edit rights |
| Access logs for operators and citizens | API gateway logs and SSO identity provider records | Logs record who accessed each flow, credential and admin screen, and n8n SAML SSO requires a Business or Enterprise plan |
| Encryption configuration for CJI in transit and at rest | Database, TLS, key management and n8n encryption key settings | CJIS Security Policy v6.1 expects FIPS 140-3 validated modules or AES with at least 256-bit keys, so confirm module validation status with your vendor and assessor |
| Monthly vulnerability scan reports | Scanner output for n8n, Temporal, databases and the host operating system | Scans run at least monthly under the CJIS Security Policy, and findings have owners, remediation dates and retained reports |
| WCAG test records for citizen-facing flows | Accessibility test results for forms, portals and any web or mobile front end | Records show testing against WCAG 2.1 Level A and AA, with dates aligned to the ADA Title II compliance deadlines for your entity size |
| Temporal authorization and network configuration | Temporal Authorizer, ClaimMapper and mTLS settings | Self-hosted Temporal with no Authorizer allows every API request, so document the chosen authorization model and network restrictions |
Common questions from agency IT and procurement teams
Can an agency run n8n for its own internal case flows under the Sustainable Use License?
Generally yes for internal use, but confirm the terms with counsel before rollout. n8n's Sustainable Use License allows use or modification only for your own internal business purposes or for non-commercial or personal use. That covers an agency automating its own case intake and internal system integrations. It does not cover offering flows to other agencies, contractors or the public as a product or service, and distribution is limited to free, non-commercial use. Files marked .ee need a valid n8n Enterprise License. Ask whether any flow will be shared with a partner agency or a vendor-hosted service, because those cases change the answer.
What does a workflow automation engagement cost, and what drives it?
Cost comes from four parts: the n8n edition or plan, hosting, build work and ongoing testing. The n8n pricing page lists a free self-hosted Community edition, while SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans. Those paid features often matter for agencies because they cover directory login and change control. Build cost rises with the number of integrations, the number of workflows, and how many legacy systems lack stable APIs. Hosting and testing recur. Ask any partner for a fixed-scope quote that lists each integration, each environment, the licensing tier assumed, and what is one-time versus recurring.
How long does a pilot take, and what sets the timeline?
The timeline depends on scope, not on a standard duration, so ask for a written schedule before work starts. The main factors are the number of agency systems in the first flow, whether test environments already exist, how quickly system owners can confirm data formats and credentials, and whether the flow needs a durable process engine such as Temporal for long-running cases. Accessibility review, if the flows are citizen-facing, and change approval also add time. A pilot limited to one intake process and two integrations is easier to bound than a multi-agency rollout. Request milestones with named owners and acceptance tests.
What must the agency provide before a partner starts?
The agency must provide named system owners, non-production test environments, a credentials policy and decision rights on data. Each integrated system needs an owner who can approve API access, test data and change windows. Test environments should mirror production closely enough to validate error handling. The credentials policy should state where secrets are stored, who can read them, and how they rotate. In n8n queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can read stored credentials, so key custody needs to be agreed up front. Confirm who approves production promotion and who receives alerts when a run fails.
Can agency staff maintain the flows after handover?
Yes, if the agency funds ownership, training and version control from the start. Staff can maintain flows when they have a documented naming standard, Git-based versioning where the edition supports it, a promotion path from test to production, and runbooks for common failures. n8n's environments with Git feature sits in the Business and Enterprise plans, so confirm which edition the agency will run. Handover should include a list of every workflow, its owner, its credentials, and its retirement date. Ask the partner to show how a change is reviewed, tested and approved before it reaches production, and whether training covers both builders and operators.
Which CJIS Security Policy and NIST items apply to these flows?
The answer depends on whether the flows carry criminal justice information or other controlled data, so classify the data first. CJIS Security Policy version 6.1 took effect on 26 June 2026 and requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations, plus vulnerability scanning at least monthly. Flows that touch CJI also need access logging and identity controls. For federal systems, NIST SP 800-53 Rev. 5 at Release 5.2.0 defines low, moderate and high baselines of 149, 287 and 370 controls and enhancements. Ask your compliance lead to map each flow to the applicable controls, and ask the partner to prepare evidence for those mappings. DeployOpen prepares systems and evidence for assessments, but auditors issue the determinations.
Should a Temporal server be used for long-running cases, and how is it secured?
Temporal fits long-running cases that must survive restarts, but it must be secured before use because self-hosted Temporal allows unauthenticated API calls by default. If no Authorizer is configured, the default noopAuthorizer allows every API request with no authentication or access control. A secured deployment should enable mTLS, a ClaimMapper that maps identity claims to namespace roles, an Authorizer plugin, OIDC single sign-on for the Web UI, and payload encryption where case data is sensitive. Run Temporal services on hosts that the public internet cannot reach. Confirm the persistence store, since PostgreSQL 13 to 16 and MySQL are tested options and SQLite is meant only for development. Ask the partner to document the upgrade path, which moves one minor version at a time.
How an agency rollout moves from one flow to governed production
This sequence takes one case intake flow from classification and license review to a monitored production service with a retirement plan for every temporary flow. Each phase closes with a named document that an agency owner can sign.
Classify data and review licensing
The agency's data owner and DeployOpen's solution architect list every data element each candidate flow touches, label it by sensitivity (including any criminal justice information or controlled unclassified information), and identify which regimes apply, such as the CJIS Security Policy or NIST SP 800-171 requirements. In parallel, legal and procurement review the n8n Sustainable Use License against the intended use, confirm whether any .ee files are needed, and decide whether a commercial plan is required. The step closes with a signed data classification register and a license decision record.
Decide architecture and trust boundaries
The team maps where n8n's main instance, its worker pool, PostgreSQL, Redis and any Temporal services will run, and which network zones may reach each one. Decisions cover whether Temporal runs as a durable backend for long-running cases, how encryption keys for stored credentials are held and shared with workers, and which external agency systems each flow may call. Temporal services are kept on hosts that are not reachable from the public internet. The output is an architecture decision record with a trust boundary diagram that the agency's security office approves.
Pilot one intake flow with test data
DeployOpen builds a single intake flow, such as an application or permit submission, using synthetic test records only, with no production credentials. The pilot exercises retries, error branches, timeouts and a human review task so that the team can see how a case behaves when a downstream agency system is unavailable. Agency staff run agreed test scripts and record results. The step closes with a pilot test report listing passed and failed scenarios and the changes made as a result.
Harden Temporal and n8n
Engineers replace default settings before any real data arrives. For Temporal, this means configuring an Authorizer, since the default noopAuthorizer allows every API request, then enabling mTLS for internode and frontend traffic, mapping identity claims to namespace roles, and setting up OIDC single sign-on for the Web UI. For n8n, the team confirms SSO through an edition that includes it, restricts editor access, and documents how the encryption key is protected. Vulnerability scanning and a patch cadence are scheduled. The output is a hardening checklist with evidence captured for each setting and a sign-off from the security team.
Sign off accessibility and change control
The agency's accessibility lead tests every citizen-facing form and page against WCAG 2.1 Level A and AA, the standard named in the ADA Title II web rule, and records defects and fixes. Change control is set up so that every workflow edit goes through a versioned export, a peer review and an approval record before promotion from test to production. Owners confirm who may edit, who may approve and who holds emergency access. The output is an accessibility conformance record and a change control procedure signed by the business owner and the agency's change board.
Cut over to production with monitoring
The approved flow is promoted through the change process and deployed into the production environment with its own credentials and encryption key. Monitoring is configured before cutover: failed executions alert a named on-call group, and execution and case-age metrics feed a dashboard that the operations team watches during the first days of live use. Rollback steps are rehearsed. The step closes with a cutover record showing the deployed version, the monitoring checks that passed and the rollback test result.
Hand over and retire temporary flows
DeployOpen transfers runbooks, architecture records, the upgrade plan and the credential inventory to the agency's operations team. Upgrades follow Temporal's rule of moving one minor version at a time, with schema upgrades run before server upgrades when release notes require them. Every temporary or interim flow is listed with an owner, an end date set by the agency and a removal step. The step closes with a handover acceptance form and a retirement plan that the agency tracks until each temporary flow is removed.
Questions to ask an implementation partner before signing
Start with the license, because it decides whether the build is allowed at all. Ask the partner to show, in writing, how they classified each n8n component against the Sustainable Use License, which permits use only for your own internal business purposes or non-commercial use, and whether any file in the deployment carries a .ee path that would require an n8n Enterprise License. Ask who signs off if the agency later shares flows with a municipality, a contractor or a vendor acting on its behalf, since that sharing may fall outside internal use. Then ask which n8n edition the design depends on for SAML single sign-on, Git environments and log streaming, and who pays for that plan. Those features are listed as Business and Enterprise plan items, so confirm them against the current pricing page before the design assumes them.
Next, ask how Temporal is secured before any case data touches it. A self-hosted Temporal server with no Authorizer configured uses the default noopAuthorizer, which allows every API request, so the partner should name the Authorizer plugin, the ClaimMapper that maps JWT or certificate claims to namespace roles, and the mTLS settings for internode and frontend traffic. Ask where the OIDC configuration for the Web UI is held and who can change it. For n8n queue mode, ask where the main instance's encryption key is stored, how it reaches every worker and webhook processor, and how a rotation is rehearsed without losing access to stored credentials. Ask for the same answers for any key protecting CJI, including whether the chosen modules meet FIPS 140-3 and whether AES keys are 256 bits, as CJIS Security Policy version 6.1 requires.
Then test the evidence trail. Ask how every workflow edit is tied to an approved change record, who can promote a flow to production, and whether production credentials are reachable by developers. Ask for a sample control mapping that links NIST SP 800-53 Rev. 5 controls, and any CJIS Security Policy requirements that apply, to the configuration and logs the partner would produce, and ask them to state plainly that the mapping supports your assessor and is not a certification. For citizen-facing forms and portals, ask how they test WCAG 2.1 Level A and AA conformance, which tools and manual checks they run, and whether they will retest after each change, since the ADA Title II rule sets the compliance dates for state and local governments. Finally, ask who maintains custom nodes and scripts after handover, how their source is versioned, and what the agency receives in writing at handover.
How DeployOpen scopes and supports public sector flows
DeployOpen plans, implements, hardens, documents and supports self-hosted workflow platforms inside the agency's own infrastructure, including its cloud accounts, data centers or isolated networks. For public sector case intake and agency integrations, the work starts with a written scope that settles licensing, hosting and change control before any flow is built.
How we scope
- Inventory the case intake forms, agency systems and integrations that the written scope covers.
- Confirm hosting location, data classification and which controls from the agency's own compliance baseline apply.
- Review the license terms of each candidate tool against how the agency will use it, including any paid edition needed for SSO or environments.
How we build
- Deploy the chosen platform in the agency's infrastructure, with credentials and execution data kept on premises.
- Configure durable execution for long-running cases and set retry and error handling rules for each integration.
- Test flows in separate environments and document the change approval steps for citizen-facing flows before release.
How we hand over
- Deliver runbooks, architecture records, configuration documentation and workflow inventories to the agency's operations team.
- Train named staff to maintain flows, rotate credentials and promote changes through the agency's approval process.
- Provide evidence packages covering access settings, logging and change records to support the agency's own compliance assessments.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan platform upgrades one minor version at a time, with backups and test runs before each change to production.
- Ask any support partner to confirm response expectations and service levels in writing before work starts.
