Automation Workstream Services (AWS in IBM's naming, "workstreams") is a CP4BA capability for business-user-defined lightweight workflows: a user builds a "workstream" in Workplace from steps (tasks assigned to people, forms, approvals), runs instances, and tracks them - no Process Designer, no deployment. It is meant for checklists, ad-hoc collaboration and simple approvals that never justified a BAW project.
- Relation to BAW: it is a separate engine (Liberty based) deployed by the operator (workstreams pattern); Workplace shows workstream tasks and BAW tasks in one federated task list (through Process Federation Server); a workstream step can start a BAW process or call an application built with Application Designer, and BAW processes can create workstream instances through the Workstreams REST API - so the two complement each other: modelled, governed processes in BAW; user-defined lightweight flows in workstreams.
- Not a replacement: no BPMN, no complex data models, no integrations beyond the provided connectors, no snapshots / versioning like process apps; when a workstream grows business rules and integrations, it is a candidate to be rebuilt as a BAW process.
- Licensing / deployment: part of the Cloud Pak entitlement; enabled with sc_deployment_patterns: workstreams (can be combined with workflow); needs PFS and Workplace.
spec:
sc_deployment_patterns: workflow,workstreams
sc_optional_components: baw_authoring,bai
workflow_authoring_configuration: ...
# plus the workstreams section of the CR (see the CR reference of your release)
Guidance for a landscape: offer workstreams to business teams for their own checklists, keep BAW for cross-system processes, and use Workplace as the single entry point so users do not care which engine runs their task.
References