Why BPM for energy and utilities needs its own design
A utility operations leader usually inherits connection requests, field work orders and outage handling that already run across a GIS, an asset register, a customer information system and operational tooling that sits close to SCADA. Each of these processes has a regulated clock attached to it, and each crosses a boundary that a generic BPM project would not normally weigh. The first design question is therefore not which engine to buy but which parts of the process may run where, and which systems the engine is allowed to call. In the United States, the CIP Reliability Standards make that boundary a compliance matter, because they become mandatory once FERC approves them and NERC and the Regional Entities enforce them. Start by asking your compliance team which assets could be classified as BES Cyber Systems under CIP-002-5.1a, since that classification decides which controls apply to the workflow host.
Those classifications shape the architecture. Under CIP-005-7, routable connections to high and medium impact BES Cyber Systems must sit inside an Electronic Security Perimeter, and interactive remote access must pass through an Intermediate System with encryption and multi-factor authentication. A workflow engine that pulls outage data or dispatches field tasks can therefore fall inside or next to that perimeter, depending on how it is connected. In the EU, NIS2 lists energy as a sector of high criticality, and the network code on cybersecurity for cross-border electricity flows adds sector-specific rules. CIP-013-2 adds supply chain duties for software you run, including vendor incident notification, software integrity verification and reviews of vendor remote access, so the open-source components, their release sources and their patch paths belong in the same risk file as the engine.
For the short answer, Flowable is a practical fit for BPMN process logic, user tasks and timers that run inside the organization's own infrastructure, since it is licensed under Apache-2.0 and offers Java and REST APIs. Its async executor coordinates timers across nodes through database locks, which matters for SLA clocks that must survive restarts. Temporal is a durable-execution option when work spans days or weeks with many retries and external calls, and the self-hosted server is MIT licensed, although its default configuration allows every API request unless an Authorizer is set. Licensing and CIP scoping decide the final pick: confirm with counsel and your compliance lead which component will sit in scope, and validate the license terms for production use before modeling begins.
Which regulatory requirements shape the BPM build
This table maps each regulatory requirement that applies to energy and utility BPM work to a concrete build decision for the workflow engine, its integrations and its work order data. Read it as a checklist to confirm with your compliance lead and assessor before architecture is fixed, since applicability depends on each asset's impact rating and registration. The main takeaway is that where the engine sits relative to control-system networks and how vendor software is verified often matter more than the BPMN model itself.
| Requirement | What it asks for | Build consequence |
|---|---|---|
| CIP-002-5.1a impact classification | Sorts BES Cyber Systems into high, medium or low impact using bright-line criteria, which set how strictly every other CIP control applies. | Confirm the impact rating of any system the workflow touches before deciding placement. Keep grid-operation triggers out of the engine unless the rating allows it. |
| CIP-005-7 Electronic Security Perimeter | Routable-connected high and medium impact assets must sit inside an Electronic Security Perimeter, and interactive remote access must pass through an Intermediate System with encryption and MFA. | Place the engine outside the ESP and pass only defined messages across a controlled boundary. Route technician access to the engine through an Intermediate System with MFA. |
| CIP-013-2 vendor supply chain | Supply chain plans covering vendor incident notification, vulnerability disclosure, software integrity verification and vendor remote access, reviewed at least every 15 calendar months. | Verify checksums or signatures for every engine release and plugin, document the partner's access path, and add the engine to the annual plan review. |
| CIP-011-3 information protection | Requires protection of BES Cyber System Information through defined handling, storage and disposal methods. | Treat asset topology and substation details carried in process variables as protected information. Encrypt the database and restrict export of work order records. |
| NIS2 Annex I energy scope | Lists electricity, district heating and cooling, oil, gas and hydrogen as high-criticality energy subsectors, with incident reporting and supplier security duties. | Confirm whether the entity is in scope and which subsector applies. Keep audit logs of process decisions and access to support incident reporting. |
| Delegated Regulation (EU) 2024/1366 | Network code setting sector-specific cybersecurity rules for cross-border electricity flows, supplementing Regulation (EU) 2019/943. | Applies mainly to cross-border electricity flow processes such as cross-border outage coordination. Confirm with the regulator whether any workflow falls under it. |
| Access control on work order data | Governing standards expect least-privilege access, separation of duties and documented authorization for field and dispatch actions. | Map crew, dispatcher and vendor roles to engine groups. Use four-eyes approvals for switching-related tasks and record who approved each step. |
| Change and configuration control | Expects tested, approved changes to systems that affect reliability and documented baselines. | Version BPMN models, test timer and deadline logic in a non-production environment, and keep a rollback path for each release. |
Where the engine can run under CIP impact levels
Under CIP-002-5.1a, BES Cyber Systems are sorted into high, medium and low impact using bright-line criteria. High impact mainly covers qualifying control centers, and medium impact includes, for example, generation of 1500 MW or more at one plant or transmission facilities at 500 kV or higher. Once an engine has a routable connection to a system in those categories, its own hosts, databases and interfaces must be assessed in that context. CIP-005-7 requires routable-connected assets of high and medium impact BES Cyber Systems to sit inside an Electronic Security Perimeter, and all Interactive Remote Access to pass through an Intermediate System with encryption and multi-factor authentication. A workflow engine that dispatches work orders to field tools or reads outage data from operational systems can fall into that scope, so the design question comes before the BPMN models.
- Scope decision first: Document which engine interfaces, queues and databases reach an in-scope system, and keep that boundary small.
- Perimeter placement: Plan the engine inside an Electronic Security Perimeter, with defined access points and no direct internet path.
- Remote access: Route any vendor or operator access through an Intermediate System with encryption and multi-factor authentication.
- Vendor controls: Account for CIP-013-2 supply chain plans for the engine and its patches, including software integrity checks.
Confirm with your compliance team and NERC Regional Entity how your impact categorization applies to each interface before you finalize the architecture.
Processes that never reach a BES Cyber System, such as customer connection requests in a CRM, billing disputes or back-office approvals, usually sit outside the CIP perimeter. The engine can then run in the corporate data center or cloud account under the organization's ordinary security baseline. This does not remove the need for controls. Customer data, personal data and the connection request history still require access control, logging and retention decisions, and NIS2 obligations may apply to the entity as a whole. The practical benefit of separation is that the team can change, scale and upgrade these workflows without a CIP change process for every release, provided the network path between the two environments is strictly defined.
- Clear network boundary: Only permit the specific integration flows needed, and block any other route between corporate and operational networks.
- Ordinary baseline: Apply corporate identity, logging and backup standards to the engine and its database.
- Data handling: Decide which customer fields enter process variables and how long they are kept.
- Upgrade cadence: Keep this environment on a normal patch schedule, while documenting why it is outside CIP scope.
Ask your compliance lead to record the scope decision in writing, because a later integration can move a workflow into the in-scope category.
The most common error is treating scope as a property of the process rather than of the connection. A grid connection workflow may look like a customer process, yet if its engine writes instructions to a system that falls under the bright-line criteria, the workflow inherits that scope. Because CIP compliance is monitored and enforced by NERC and the Regional Entities, and the maximum civil penalty is $1,584,648 per violation per day (18 CFR 385.1602), the cost of an unclear boundary is high. The question for each integration is whether the engine can change the state of, or send commands to, an in-scope asset, not whether the process is operational in name.
- Connection-level review: Map every API, message queue and file transfer to the systems it touches.
- Change triggers: Require a scope review whenever a new integration or data feed is added.
- Documented rationale: Keep a written record of why each system is in or out of scope.
- Registry check: Confirm whether your organization is registered in a way that makes CIP applicable at all.
Ask your auditor or Regional Entity contact to confirm the impact categorization of each system before the engine connects to it.
Temporal's deployment guidance says its services should run on hosts that are not reachable from the public internet, with network access restricted to trusted internal networks. This applies to the frontend, the history and matching services, and the database behind them, whichever environment hosts the engine. For a utility, the implication is that the Temporal frontend should never be published on a public address, even for convenience during development. Where workers must reach the engine from another zone, the path should be a narrow, documented flow inside the perimeter or through the approved remote access route. Self-hosted deployments can be built with Docker Compose, Go binaries or Helm charts on Kubernetes, and each option needs the same network restriction.
- No public frontend: Keep the frontend and internode ports off public addresses and off any DMZ that faces the internet.
- Restricted worker access: Allow only the worker hosts and administrative hosts that need the frontend.
- Database isolation: Keep persistence and visibility stores on the same protected network segment.
- Kubernetes exposure: Check ingress rules and service types in Helm deployments before going live.
Confirm the exact ports and internal flows with your Temporal version's deployment documentation and your network team before rollout.
If no Authorizer is configured, self-hosted Temporal uses the default noopAuthorizer, which allows every API request without authentication or access control. This is the single most important configuration check for any deployment, whether it runs in corporate space or inside a perimeter. Temporal provides mTLS with separate settings for internode and frontend traffic, a ClaimMapper that maps JWT or certificate claims to namespace roles, an Authorizer plugin, OIDC single sign-on for the Web UI, and payload encryption through custom codecs and a codec server. Those controls must be configured and tested deliberately, because the default does not enforce them. Process payloads for energy workflows can include asset identifiers, customer data and work order details, so access and encryption choices affect both security and audit evidence.
- Replace the default: Configure an Authorizer and ClaimMapper before any non-test environment is connected to data.
- Mutual TLS: Enable mTLS for both internode and frontend traffic.
- Operator access: Use OIDC single sign-on for the Web UI and map roles to namespaces.
- Payload protection: Plan a codec and codec server so sensitive fields are encrypted in workflow history.
Before sign-off, have a tester confirm that unauthenticated requests are rejected and record the result as evidence.
Which open-source platforms fit grid, field and outage workflows
Grid connection requests, work orders and outage processes need an engine that runs long timers reliably, records every decision, and fits the utility's own infrastructure. The options below differ mainly in license terms for production use, how they handle durable execution, and where they should stop and hand off to a general integration tool.
Flowable for BPMN and CMMN engines
Flowable is Apache-2.0 and provides BPMN process execution, CMMN case management and DMN decision rules, with Java and REST APIs. Its async executor runs timers from a thread pool and coordinates multiple nodes through lock owners and lock expiration times in the database, so jobs held by a failed node are picked up by another. For connection requests that wait months for studies or customer documents, check that timer volumes and node counts have been tested against your database and cluster design. Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, so plan the platform baseline before choosing a version.
Identity and integration reference points in Flowable
Flowable's docs say identity management can be replaced by implementing the IdmIdentityService interface, with an LDAP implementation provided as a reference. For utilities, this matters because dispatchers, field crews and contractors often sit in different directories, and work order assignment must follow the correct group. Confirm how your directory structure maps to candidate groups before the design is fixed. Also confirm which GIS, asset and customer systems will be called through the REST API or Java services, because those integrations usually carry more effort than the engine itself.
Camunda 8 license limits for production
Camunda 8 source code is licensed under the Camunda License 1.0, which permits use only in non-production environments without a commercial license. A utility that plans to run outage or connection workflows in production must include the commercial license cost in its evaluation, or choose another engine. Ask any vendor or partner to state in writing which Camunda components are covered, which environments are included, and how the license applies to test and disaster recovery copies. Camunda 7 transition questions belong in a separate review.
Temporal for durable long-running logic
The Temporal server is MIT licensed, and Temporal Cloud is a separate managed service that a utility may not be able to use for OT-adjacent data. Self-hosting needs a persistence store (PostgreSQL, MySQL or Cassandra in supported versions) and, if you need broad search across executions, Elasticsearch or OpenSearch for visibility. The default authorizer allows every API request, so configure mTLS, a ClaimMapper and an Authorizer before any operator uses it. Temporal suits custom code paths such as multi-day notification sequences, but it is a developer platform, so it needs more engineering capacity than a BPMN engine with a task UI.
Node-RED and n8n as integration glue
Node-RED (Apache-2.0) and n8n (Sustainable Use License, with .ee files requiring an enterprise license) are useful for simple event forwarding, such as passing a meter or outage notice into a process start call. Keep them out of the system of record for timers, approvals and deadlines, because their execution state is not designed as the audit trail for a regulated service-level deadline. Check the n8n license terms for your intended use, and confirm where credentials and execution logs are stored, since they may touch OT-adjacent networks.
Checklist before choosing an engine
Before selecting a platform, write down the timers that carry regulatory deadlines, the number of concurrent cases during a storm event, and the systems each step must call. Then test restart behavior: stop a node during a timer and confirm another node fires it. Ask each candidate for the license terms covering production, test and recovery environments in writing. A selection that passes these checks is far easier to defend in a compliance review than one made on feature lists alone.
Integration points and deployment patterns for utilities
How does a BPMN engine connect to GIS and asset registries?
The engine usually reads and writes asset and network data through a REST adapter that sits in front of the GIS or asset management system, so the process never queries the GIS database directly. The data that crosses includes asset identifiers, substation and feeder references, connectivity status and the outcome of a field survey or design step. Process variables should carry identifiers and status, not full network models, because the GIS remains the system of record. Deploy the adapter and the engine in the same network zone as the GIS, inside the utility's own data center or cloud account, and keep the GIS on its existing segment. Confirm with your GIS vendor which APIs are supported and how versioned geometry is exposed before you fix the design.
What is the pattern for customer and billing system integration?
Customer and billing data is best exchanged through a message queue for events such as a connection request being accepted, a meter being set or a service being energized, with a REST call used only where the process needs an immediate answer, such as a account validation. The data crossing includes account numbers, service addresses, contact details and deposit or fee status, so limit the payload to the fields the process needs. Place the queue broker and the adapters inside the utility network, with the billing system kept on its own segment. Ask the billing vendor whether it supports idempotent message handling, because duplicate events are a common source of errors in connection workflows.
How do field crews receive and complete tasks on mobile devices?
The engine exposes human tasks through its REST API, and a field task UI or mobile app calls that API to list, claim and complete work orders. The data crossing includes work order identifiers, location, asset references, required forms and completion evidence such as photos or meter readings. Offline work is the main design question: the app must cache tasks and queue completions, then submit them when connectivity returns, and the engine must accept late updates without corrupting state. Host the task API in the utility's own environment and place the mobile back end behind the same gateway controls used for other internal services. Confirm how the device management platform and app distribution are handled in your environment.
How should outage events reach dispatch and crew scheduling?
Outage events should arrive through a message queue from the distribution management or outage detection system, and the engine should start or update an outage process for each event. The data crossing includes feeder and device identifiers, customer counts affected, switching states and crew assignments. Long-running timers handle restoration targets and escalation, and the engine's async executor must be configured for the expected event volume during storms. Keep dispatch systems and the outage process inside the operational network boundary, and treat any link to the control environment as an operational technology interface that needs a separate review. Review NIST SP 800-82 Rev. 3 and the ISA/IEC 62443 series with your OT security team before connecting these paths.
How does identity federation work for utility staff and contractors?
Identity federation connects the engine's user management and the task UIs to the utility's existing directory, so that staff and contractors sign in with their own accounts and receive roles tied to their group membership. Flowable allows identity management to be replaced through its identity service interface, and an LDAP implementation is provided as a reference, which makes directory-based groups a workable starting point. Contractor access needs time-limited accounts and clear separation from employee roles. Run the identity provider and the engine in the same trust zone, and place multi-factor enforcement at the access layer. Confirm with your identity team which protocols the directory supports before choosing the adapter.
Which integration pattern fits each system in a utility BPM deployment?
The right pattern depends on whether the caller needs an answer now, whether the event must be processed later, and how much data moves at once. The main patterns are:
- REST adapters for synchronous lookups and task updates, such as GIS queries and task completion
- Message queues for events that start or advance processes, such as outage notifications and connection status changes
- Batch transfers for nightly reconciliation of asset registries and billing extracts, where a full dataset is more practical than individual events
Place each adapter in the zone of the system it protects, and avoid giving the engine direct database access to any source system. Document the pattern for each interface in the design so that auditors and operators can trace data flows. Agree the interface catalog with the utility's architecture team before build starts.
What does a utility BPM integration engagement cover, and who pays for what?
A typical engagement covers interface design, adapter build, the engine deployment, testing against non-production copies of each source system, and handover of runbooks. The utility pays for access to the source systems, vendor licenses and its own staff time for data owners and security reviews, while the implementation partner is paid for design and build work defined in the written scope. Recurring costs include hosting, monitoring and any support retainer after go-live. The cost rises with the number of interfaces, the quality of the source APIs and the number of parties that must approve changes. Ask the partner to itemize interfaces, environments and testing in the quote, and to state which vendor work is assumed to be done by the utility.
How a utility phases a BPM rollout without disrupting running work
The sequence moves from scope classification and modeling to integration, security, a single-region pilot and a phased cutover, so each stage produces evidence that the next one depends on and work already in flight keeps moving.
Classify impact and sign the scope
The compliance lead, OT security owner and process owners classify each system the new processes will touch against the CIP-002 bright-line criteria for high, medium and low impact BES Cyber Systems. The inputs are asset lists, control center and plant inventories, and network diagrams. The output is a signed scope document that states which processes, interfaces and sites are in the first release and which are excluded. The step is done when every in-scope system has a documented impact rating and the signatories have accepted the boundary in writing.
Inventory processes and model the BPMN library
Business analysts work with dispatch, field operations and customer service leads to inventory grid connection requests, field work orders and outage processes, then model each one in BPMN with its human tasks, timers and regulated deadlines. Versioned models are reviewed by the process owners and tested against sample cases from the last year of work. The output is a model library with a named owner for each process, a list of the variables each process carries, and a record of which steps depend on manual decisions. The step closes when owners have approved the models and test cases pass.
Specify integrations and timer behavior
Integration architects define how the engine exchanges data with asset management, GIS and customer systems, including message formats, retry rules and the source of truth for each field. They also set out how timers for service-level deadlines behave when a downstream system is unavailable or a clock change moves a due date. The output is an interface specification with one entry per integration, plus a timer design that states what happens to each long-running wait. The step is done when each interface has an agreed owner and failure path, and timer scenarios have been reviewed against the regulated deadlines.
Map controls and harden the platform
Security engineers map the platform's controls to the CIP requirements that apply to the in-scope systems, including the Electronic Security Perimeter, interactive remote access and supply chain risk management under CIP-013-2. For a self-hosted Temporal deployment, they confirm an Authorizer is configured, since the default allows every request, and they set mTLS, identity federation and payload encryption before any production data arrives. The output is a control mapping document with evidence locations for each requirement. DeployOpen can prepare this evidence, but independent auditors decide whether the controls satisfy the standards.
Run a pilot in one region
The team deploys the models and integrations to one operating region, with a limited set of work orders or connection requests routed through the new engine while the rest stay on existing tools. Operations staff use the human task interfaces daily, and the team records timer behavior, integration errors and any step where staff bypass the process. The output is pilot evidence: a log of completed cases, defects with owners, and a decision record on which fixes are required before wider use. The pilot is complete when the agreed acceptance criteria are met and the operations lead signs off.
Plan the cutover and running instances
Before any further cutover, the team decides how instances already in flight will finish. Some will complete on the old version, others will be migrated to a new model version, and the plan records the rule used for each process. Cutover is phased by region or process, with rollback steps written for each phase and a freeze window agreed with operations. The output is a cutover plan with an instance inventory, migration tests run against a copy of production data, and named approvers for each phase. Each phase starts only after the previous one's exit criteria are recorded.
How timers and regulated deadlines behave in a long-running process
Timers in a Flowable process are executed by the async executor, not by the process model itself. The async executor runs timers and asynchronous jobs from a thread pool, and when several nodes share one database it coordinates them through lock owners and lock expiration times stored in that database. If a node dies while holding a job, the lock expires and another node picks the job up. For a grid connection request that must reach a decision within a regulated window, this means a timer that was due while a node was down fires later, not never. The architecture team should confirm the executor settings, lock duration and node count with the chosen database and Flowable version, then document the worst-case delay the business accepts for each deadline.
Temporal takes a different approach: it records workflow state as an event history and replays it to resume after a failure. Timers are durable events on the Temporal Server, so a sleep or deadline survives worker restarts and deployments without a separate lock-recovery mechanism. The trade-off is operational. Temporal's persistence and visibility stores are separate from the engine, its upgrade path must be followed one minor version at a time, and a default self-hosted server allows unauthenticated API calls unless an Authorizer is configured. Teams comparing the two should not assume equal timer behavior and should test each on its own terms.
Test four behaviors before any deadline is trusted in production: clock precision, restart behavior, clustering and escalation. Clock precision depends on the database column types and the driver, and the Flowable configuration docs note that MySQL versions below 5.6.4 lack millisecond precision. Restart tests should stop nodes during scheduled timers and measure how late each one fires. Clustering tests should kill a node holding locks and confirm recovery. Escalation tests should confirm that a missed service-level deadline raises a task to a named role, with the breach recorded in the audit history. Ask the implementation partner for these test results in writing, keyed to the exact database and engine versions in the design.
What auditors and regulators ask for from process systems
This table maps the evidence items that assessors and regulators typically request from a BPMN process platform to the component that produces each item. Use it to decide which records the process platform must keep, which must come from elsewhere, and which to confirm with your compliance team and regulator. CIP-013-2 supplier review cadence and the three-year audit cycle are included as context, and both should be confirmed against your registration and the current NERC text.
| Evidence item | What it proves | Component that produces it |
|---|---|---|
| Process version history | Which BPMN model version governed each grid connection, work order or outage case when it ran | BPMN deployment repository and engine deployment records in Flowable |
| Audit log of task and decision actions | Who approved, reassigned or changed a case, and when, with the data in force at that time | Flowable history tables and an exported, retained audit trail |
| Monitoring and running instance status | Operational health of timers, async jobs and deadlines for regulated service-level clocks | Flowable actuator endpoint at /actuator/flowable and centralized logging |
| Access reviews for operators and engineers | Only authorized staff can administer models, tasks and integrations with asset and GIS systems | Identity provider groups mapped to Flowable roles, reviewed on a set schedule |
| Change records for models and integrations | Each change to a process or connector was tested and approved before production | Version control, peer review records and change tickets linked to deployments |
| Backup and restore test results | Process state and history can be recovered after a failure, and the recovery was tested | Database backup jobs and dated restore test reports |
| Supplier and software integrity records | Vendor software, connectors and updates were verified and tracked, as CIP-013-2 expects for supply chain risk | Signed artifact records, SBOM or dependency inventory and vendor notification log; review at least every 15 calendar months |
| Audit cycle context | Registered entities in certain roles receive a compliance audit at least once every three years | Confirm the applicable cycle and evidence period with your regulator and compliance lead |
What to ask an implementation partner before a utility engagement
Start with CIP scoping and Electronic Security Perimeter placement. Ask the partner to describe projects where they have mapped a BPMN process to a CIP scope decision, and how they recorded which BES Cyber Systems, if any, the workflow touches. The answer should separate the engine from the systems it calls. Ask who signs off the impact classification under CIP-002-5.1a and how the ESP placement under CIP-005-7 is documented for any workflow host that can reach routable assets. Ask what they will not do without the compliance owner's written decision, and who in your organization holds that decision.
Ask how they keep BES data out of process variables. Process variables are persisted in the engine database and appear in history and monitoring, so an operating point or device identifier copied into a variable becomes a retained record. Ask for the variable naming and data classification standard they use, how references to asset records replace raw values, and how they confirm that history tables, logs and the Flowable actuator endpoint at /actuator/flowable do not expose those values. Ask how this is tested, and how it maps to your CIP-011-3 information protection program. Also ask how they handle Flowable upgrades: how they test a move between major lines (the Flowable 8.0.0 release moved to Spring Framework 7 and Spring Boot 4, with no backward compatibility for Spring Boot 3), who owns the dependency bill of materials, and how they document software integrity for every library, which CIP-013-2 supply chain controls will expect you to show.
Ask how timers are tested under failover, because long-running outage and connection deadlines depend on them. Ask for the test plan: which node is killed mid-timer, how expired async executor locks are recovered by another node, and how they prove a deadline fired once and on time. Ask how they handle Camunda license terms for production. Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license, so a utility should not assume that a Camunda evaluation carries into operations. Request a written statement of which license covers each component in the proposed architecture, and confirm it with your legal team before design starts.
What does a utility BPM implementation cost and need from us?
What drives the cost of a utility BPM implementation?
Scope, the number of integrations and the compliance classification work drive most of the cost. A grid connection process that touches one asset register and one customer system costs far less to build and test than an outage process that reads from GIS, SCADA-adjacent data, a customer information system and a field dispatch tool. Other cost drivers are the number of distinct process variants, the task interfaces for field crews and control room staff, the volume of timer and deadline logic, and how much migration work sits on existing running cases. Ask for a quote that prices each process, each integration and each UI separately so you can see where scope can be reduced.
Which BPM costs are one-time and which recur?
One-time costs usually include discovery, process modeling, integration build, task UI, testing, security hardening and initial deployment into your infrastructure. Recurring costs include infrastructure you run, the engine license if you choose a commercial option, patching and upgrades, monitoring, and support or retainer hours. Keep in mind that the Flowable open source engines are licensed under Apache-2.0, so there is no per-seat or per-process engine fee, but you still pay for hosting, staff time and any support contract. Ask the implementation partner to split the quote into one-time and recurring lines.
Can our internal staff operate the BPM engine after go-live?
Yes, if you plan for it from the start. Operating a Flowable engine involves running the service on your Java and database stack, managing the async executor and database locks in a clustered setup, reviewing process versions and monitoring running instances. Your platform team needs skills in the chosen runtime, and your process owners need a way to change models through a controlled release path. Ask the partner which operational tasks they will hand over, which they will keep under a retainer, and what documentation and training they will deliver.
How long does a utility BPM implementation take?
DeployOpen does not publish durations. Timelines depend on the processes in scope, the number of systems to integrate, the availability of test environments and the approval steps your change board requires. Engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. Ask for a phased plan that starts with one process, such as grid connection requests, and includes the regulatory evidence each phase must produce.
Should we choose Flowable or Camunda for a utility BPM engine?
The choice depends on license terms for production use, your existing tooling and your support model. Flowable's open source engines are licensed under Apache-2.0. Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license, so production use requires a commercial agreement. Check the current terms with each vendor before you decide, and ask your legal team to review them against your deployment plan. Your choice also affects how you handle upgrades and the migration of any legacy engine instances.
What do our compliance and OT teams need to provide?
Your compliance team needs to confirm which systems are in scope for NERC CIP, which BES Cyber Systems the BPM engine could touch, and how the engine would be classified under your CIP-002 categorization. Your OT team needs to define network zones, confirm whether the engine sits inside or outside an Electronic Security Perimeter, and specify how remote access is granted to vendors. Expect to supply architecture diagrams, access lists, vendor access procedures and the change records your auditors will ask to see. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue any audit outcome.
What testing does a utility BPM rollout need before production?
Testing should cover BPMN path logic, timer and deadline behavior, integration error handling, role-based task access and recovery after a node failure. Timers and deadlines need particular attention because regulated service-level clocks must fire correctly across restarts and cluster failovers. Ask the partner to show how they test process versions, how they replay representative cases, and how test evidence is stored for your change records. Confirm the test environment mirrors your production network zones so that integration results are meaningful.
How DeployOpen scopes and supports utility BPM
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including the process engine, its database, its task interfaces and its connectors to asset, GIS and customer systems. For a utility, the first deliverable is usually a written scope that names the process models in the first release (for example, a grid connection request or an outage restoration flow), the systems each service task calls, the timer and deadline rules that carry regulatory clock obligations, and the environment where the engine runs. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. The reader should ask for the list of integrations and the deadline rules to be written out as acceptance criteria, because they decide what is tested and what is handed over.
Security work on the process layer is scoped as its own item. The engine stores process variables, customer and asset identifiers and task history, and its REST and Java APIs need authentication, network restriction and logging that match the utility's CIP or NIS2 program. DeployOpen runs security testing of the APIs, the task interfaces and the infrastructure around the engine, and the findings and fixes are part of the agreed scope. DeployOpen also prepares compliance evidence for the controls it implements, such as configuration baselines, change records, access reviews and backup test results. It does not issue audit reports, attestations or certifications. Independent auditors and the relevant regulators assess the program, so the utility should confirm early which evidence its auditor expects and in what format.
After go-live, operations continue. DeployOpen offers retainers for upgrades, patching, monitoring and support, which suit a process platform that must follow engine and dependency releases on a planned cycle. Ask a partner how upgrades are tested against the utility's own process models before they reach production, who signs off each change, and how long a security fix takes to reach production under the retainer. Those answers, written into the agreement, determine whether the platform stays supportable for the years a grid process typically runs.
