How do case solutions and BAW processes work together (case activity starting a process, sharing case properties)?

Question

BAW combines case management (from IBM Case Manager) and process. When should something be a case activity versus a process, and how does a case start a BPD and pass its properties back and forth?

Answer 1

Rule of thumb: a case is the long-lived, document-centric container with ad-hoc and mandatory activities (a claim, a customer onboarding); a process (BPD) is a predictable, sequenced piece of work. In BAW a case activity can be implemented by a process: "Assess damage" in the claim case starts the BPD "Damage assessment" - the case only knows that the activity is running or completed.

• Wiring: in the case type (Case Builder inside BAW), an activity's implementation is either a task (a human step) or a process chosen from the same process app / toolkit; the BPD's input variables are mapped from case properties (properties of the case type, stored in Content Platform Engine) and the BPD's outputs map back to case properties when the process ends.
• Data flow: keep the case properties as the shared "record" (they are in FileNet, searchable and auditable); the BPD copies what it needs at start and writes back results at the end; during the process, a service flow can read or update the case through the Case REST API (add a comment, attach a document, change a property, start another activity).
• Documents: case documents live in the case folder of Content Platform Engine; coaches use the content controls (Document List / Viewer) pointing at the case folder id, passed to the BPD as an input.
• Lifecycle: completing the BPD completes the case activity; terminating the process leaves the activity failed - a case rule or the case worker can repeat it; closing the case cancels its running activities.

// process inputs mapped from the case (activity implementation = this BPD)
tw.local.caseId          // case identifier, for REST calls back to the case
tw.local.caseFolderId    // folder id for the ECM coach controls
// updating a case property from a service flow through the Case REST API (same platform, current user or a system user)
PUT /CaseManager/CASEREST/v1/case/{caseId}
{ "properties": { "ClaimStatus": "ASSESSED", "AssessedAmount": 1250.0 } }

Design guidance: use the case for the "what" and for decisions people make ad hoc (discretionary activities, stages, precondition rules), processes for the "how" that must run the same way every time; do not duplicate state in both (one owner per field); case solutions need the case-enabled BAW deployment (Content Platform Engine and the case database) - on CP4BA that is the workflow pattern with the case components enabled in the custom resource.

References

• Case REST API
• BAW documentation - case management in Business Automation Workflow