Yes: baw_configuration in the custom resource is a list - each entry is an independent Workflow runtime (own name, database, Process Server pods, routes, admin user, replicas, resources) inside the same namespace, sharing the platform services (Zen / IAM, LDAP, Business Automation Navigator, Workplace, Process Federation Server, BAI, monitoring):
spec:
sc_deployment_patterns: workflow
baw_configuration:
- name: bawfin
replicas: 2
database: { type: db2, server_name: db2.example.com, database_name: BAWFIN, secret_name: bawfin-db-secret }
admin_user: bawfinadmin
- name: bawhr
replicas: 1
database: { type: db2, server_name: db2.example.com, database_name: BAWHR, secret_name: bawhr-db-secret }
admin_user: bawhradminWhat is isolated and what is shared:
- Isolated: BPMDB / PDW (own databases), installed process apps and snapshots, Process Admin (own admin user and role mappings), routes and REST base paths (each instance has its own URL prefix built from its name, listed in the endpoints ConfigMap), Event Manager, JVM sizing, the custom XML secret, and log / trace settings.
- Shared: the Zen user registry and LDAP (the same people exist in both; authorisation per instance is done with the instance's own role mappings and teams), Workplace (shows tasks of both instances federated by PFS - a user sees only what they are entitled to in each), BAI, Workflow Center (one authoring environment - each runtime is a separate deployment target), the operator and the upgrade cadence (all instances upgrade together with the CR), and the cluster's resources.
When one Cloud Pak is not enough: separate namespaces (one CP4BA per namespace with its own foundation services) give independent upgrade cycles and full administrative separation at the cost of duplicated platform pods; separate clusters are the choice for regulatory isolation. Most organisations run one CP4BA per lifecycle stage (dev / test / prod) with several baw_configuration entries for business units within it.
References