Process Automation Manager, priced per process engine core.

JBoss Process Automation Manager licensing meters by core on the host running the process execution engine at runtime. The product is the supported distribution of the jBPM workflow engine and the Drools rule engine, packaged with the kie server for runtime execution, the Business Central authoring environment for the business analyst, the case management user surface for the operational worker, and the integration with JBoss EAP and Quarkus as the runtime base. The metered unit is the execution core; the authoring environment, the process repository, and the case worker user count are not metered separately under the standard entitlement.1

The product sits in a category of business process management platforms where the metering shape varies dramatically across vendors. Some vendors meter by named case worker, others by case volume, others by the number of process definitions in the repository. The Red Hat per execution core model favours estates with stable process volumes and predictable runtime patterns; the cost scales with the engine footprint rather than with the size of the process portfolio or the size of the operational team.

For the broader middleware practice context, see the JBoss and middleware practice hub. For the benchmarking observations that underlie the unit price ranges, see the benchmarking service hub.

Three counting traps recur on Process Automation Manager estates. Each is correctable through reshape before audit or renewal.

The first trap is counting cores on the authoring environment as runtime cores. Business Central runs the process authoring environment for the business analyst; the kie server runs the workflow execution engine. The runtime entitlement applies to the kie server cores. Operators sometimes count the Business Central host alongside the kie server hosts, which doubles the entitlement on infrastructure that does not need it. The reshape is to confirm which hosts run the process engine and entitle only those.

The second trap is licensing every kie server replica in a clustered workflow runtime separately. A clustered Process Automation Manager runtime normally runs three or more kie server instances behind a load balancer to absorb a continuously growing case load. All replicas are in scope as active members of the cluster. The reshape is to confirm the cluster size reflects the operational load rather than overprovisioned headroom; the seller side does not exclude replicas from the count.2

The third trap is treating the case management surface as out of scope because the case workers are not Red Hat licensed users. The case management surface is part of the same entitlement that covers the kie server runtime. It is bundled, not separately metered. Operators sometimes assume that adding case workers implies a per user cost; the entitlement model does not work that way. The reshape opportunity sits in the engine cores, not in the operational user count.

The runtime model on a Process Automation Manager estate shapes the entitlement footprint more than the process portfolio itself. Three patterns dominate. The first is the dedicated kie server cluster pattern, where workflow execution runs on a separate cluster of kie servers and applications call the engine over the network. The entitlement is sized to the kie server cores. The second is the embedded engine pattern, where workflows execute inside application JVMs and no separate cluster exists. The entitlement applies to every host running an application that embeds the engine. The third is the hybrid pattern, where some processes execute on a central cluster and others embed inside application JVMs.

The cost shape across the three patterns is non trivial. The dedicated cluster pattern usually produces the smallest entitlement count because the runtime footprint is concentrated. The embedded pattern often produces the largest count because every application host carries the engine. The hybrid pattern lands in the middle, with the cost depending on the share of execution that sits on the central cluster versus the embedded hosts. For estates considering a runtime consolidation, the reshape opportunity sits in moving embedded execution onto a central kie server cluster.3

One operational note matters. The kie server runtime base can be either JBoss EAP or Quarkus depending on the deployment. The runtime base does not change the Process Automation Manager entitlement count but does change the adjacent entitlement footprint; for the Quarkus reading on a per core supported build, see the Quarkus licensing note. For the sibling reading on the rules engine that pairs with the workflow engine in most case management deployments, see the Decision Manager licensing note.

jBPM is an upstream open source project. The community distribution runs the same workflow engine as JBoss Process Automation Manager, with the paid build providing support, certified compatibility within the Red Hat platform, and a long term maintenance commitment on selected versions. The boundary against community use is consequential where the workflow platform sits in a regulated case management flow or in a production critical operational path.

Three boundary patterns work in operational practice. The first is paid build on regulated case flows, community build on internal back office workflows. Regulated case flows that affect customer outcomes, claim adjudication, or compliance decisions normally require vendor support and the paid build. Internal back office workflows that automate task routing across a small operational team can often run on community jBPM where the operational consequence of a failure is lower.

The second is paid build on the central case platform, community build on team owned workflows. Where the central case platform handles cross domain workflows and team owned platforms handle local automations, the entitlement attaches to the central platform alone. The reshape requires technical separation between the central platform and the team platforms.

The third is paid build only on long term support versions of the engine. Where the paid build's maintenance commitment is the actual value, the reshape is to license only the kie servers that pin to a long term version and let the rest run the community release. This pattern is less common on Process Automation Manager than on Quarkus or Keycloak because the workflow platform tends to be more conservatively versioned and the case continuity value carries weight. For the surrounding industry reading where workflow platforms sit inside production critical case flows, see the healthcare audit considerations note on claim adjudication and benefit determination case estates.

The renewal posture on a Process Automation Manager estate has three components worth preparing before the seller side prices the next term. The first is the runtime inventory, which should resolve every kie server and every embedded engine host to its core count and confirm that authoring hosts have been removed from the runtime count. The second is the consolidation review, which should test whether embedded execution can move onto a central cluster with a smaller aggregate core count. The third is the community boundary, with the technical enforcement documented for each environment where the paid build and the community build coexist.

The seller side at renewal often positions Process Automation Manager as part of a broader Red Hat Process Automation or Runtimes commitment. The buyer side reading is to treat any bundle conversation against the actual consumption pattern. Where the estate runs the workflow engine standalone without the rules engine, the bundle does not pay. Where both products run on overlapping host bases, the bundle may pay; the analysis is mechanical. For the sibling reading on the messaging tier that often pairs with case management on event driven workflows, see the AMQ Streams licensing note.

For estates evaluating Process Automation Manager licensing ahead of a renewal or audit, the engagement is normally a subscription assessment scoped to the workflow estate plus a runtime model review and a community boundary check. To begin, see the contact page.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.