Business Process Model and Notation (BPMN) is the de facto standard for visualizing business workflows, yet one of the most common sources of confusion for modelers is distinguishing between what should be shown internally versus what should be exposed externally. In complex ecosystems involving multiple organizations, partners, or customers, exposing every internal operational detail is not only unnecessary but often detrimental to security, intellectual property protection, and model clarity.
BPMN addresses this through specific submodel classifications: Private Processes and Public Processes. Understanding the distinction between these two modeling perspectives is critical for accurate system architecture, effective cross-organizational collaboration, and compliant service design. This guide provides a comprehensive breakdown of these concepts, structural rules, practical examples, and best practices for implementing them effectively.
To understand where Private and Public processes fit, it is necessary to view the broader BPMN modeling environment. BPMN categorizes modeling into three primary submodels:
Processes (Orchestration): Defines the flow of activities within a single entity. This category includes both Private (internal) and Public (external interface) processes.
Choreographies: Defines the expected message interactions between two or more independent participants without dictating internal logic.
Collaborations: Combines Processes and/or Choreographies to show how pools interact, including conversation views.
Private and Public processes are both subsets of the Process (Orchestration) submodel, but they serve fundamentally different audiences and purposes.
Private Business Processes represent workflows that are strictly internal to a specific organization. Often referred to as workflows, BPM orchestrations, or internal procedures, these models capture the complete step-by-step logic required to achieve a business goal.
Pool Containment: A private process must reside entirely within a single Pool. If modeled in a Collaboration diagram, it occupies one lane or set of lanes within that pool.
Sequence Flow Integrity: Sequence Flows (solid lines with arrows) define the execution order and cannot cross pool boundaries. Crossing a boundary with a Sequence Flow is a fundamental BPMN syntax error.
External Communication: Interaction with entities outside the pool occurs exclusively via Message Flows (dashed lines with open arrows), which are permitted to cross pool boundaries.
Granularity: Includes all operational tasks, decisions, data objects, and exception handling relevant to internal execution.
| Type | Definition | Use Case |
|---|---|---|
| Executable Process | Modeled with precise technical attributes (e.g., XPath expressions, script definitions) intended for direct deployment to a BPMN execution engine. | System automation, workflow engines, microservice orchestration. |
| Non-Executable Process | Modeled for documentation, analysis, training, or human understanding at a modeler-defined level of abstraction. Omits formal execution semantics. | SOPs, compliance documentation, process improvement workshops. |
Consider an internal insurance underwriting process. To an external applicant, this is a "black box." Internally, however, it is a rigorous sequence of validation and decision-making.
Process Flow:
[Start] ➔ [Determine Order Complete] ➔ [Check Applicant Record] ➔ [Calculate Premium] ➔ [Approve/Reject Decision] ➔ [Notify Applicant] ➔ [End]
Task Breakdown:
Determine Order is Complete (User Task): An underwriter validates that all required fields and documents are present.
Check Record of Applicant (User Task): Manual review of applicant history against internal risk databases.
Determine Premium of Policy (Business Rule Task): Automated calculation using proprietary rating algorithms and actuarial tables.
Approve or Reject Policy (User Task): Senior underwriter makes the final binding decision based on calculated risk.
Notify Applicant (Send Task): Triggers an external email/SMS notification system.
Critical Insight: The proprietary rating algorithm in Step 3 and the internal risk database query in Step 2 are never visible in a Public Process model. They are competitive advantages and operational secrets protected by the Private Process boundary.
A Public Process represents the external interaction protocol between a private process and outside participants. Historically termed an "Abstract Process" in BPMN 1.2, it functions as a behavioral interface or contract.
Touch-Points Only: Contains only Send and Receive tasks (or message events) that constitute the external communication sequence. All internal calculations, approvals, and data transformations are excluded.
Message Flow Visibility: The model explicitly shows the direction, sequence, and content of messages exchanged with external pools.
Non-Executable Nature: Public Processes are inherently abstract. They cannot be deployed to an execution engine because they lack internal implementation logic.
Contractual Function: Serves as an API specification or SLA definition for external partners, showing them how to interact without revealing what happens inside.
A healthcare provider’s internal clinical workflow is highly complex and regulated. However, the patient only needs to know the communication touch-points.
Public Process Touch-Point Sequence:
Receive Doctor Request: Accepts "I want to see doctor" message from Patient Pool.
Send Appointment Confirmation: Returns "Go see doctor at [Time]" message to Patient.
Receive Symptoms Report: Accepts "I feel sick / [Symptom List]" message from Patient.
Send Prescription Pickup Notice: Sends "Pickup your medicine and you can leave" message to Patient.
Receive Medicine Request: Accepts "need my medicine" message from Patient.
Send Medicine Delivery: Delivers "Here is your medicine" message to Patient.
What Is Hidden: Behind each of these six touch-points lies a massive Private Process: EHR lookups, doctor availability checks, insurance pre-authorization, pharmacy inventory management, controlled substance logging, and clinical decision support. None of this appears in the Public Process.
| Dimension | Private (Internal) Process | Public Process |
|---|---|---|
| Primary Audience | Internal staff, developers, auditors | External partners, customers, API consumers |
| Scope | Complete end-to-end operational workflow | External message exchange interface only |
| Task Types Included | User, Service, Script, Business Rule, Manual, Send, Receive | Send and Receive Tasks / Message Events only |
| Execution Capability | Executable or Non-Executable | Always Non-Executable (Abstract) |
| BPMN 1.2 Legacy Term | Private Process | Abstract Process |
| Analogy | Kitchen operations in a restaurant | Menu and ordering interface presented to diners |
| Governance | Internal change management | Contractual/API versioning with external parties |
Use a Private Process when: Documenting SOPs, configuring workflow engines, conducting internal process mining, training employees, or performing internal compliance audits.
Use a Public Process when: Defining B2B integration contracts, publishing API behavioral specifications, creating customer-facing service catalogs, or establishing choreography participation interfaces.
Leaking Internal Logic into Public Models: Including internal approval gates or database queries in a Public Process violates abstraction principles and exposes proprietary information.
Using Sequence Flows Across Pools: This is syntactically invalid. Always use Message Flows for inter-pool communication.
Treating Public Processes as Executable: Attempting to deploy a Public Process to a BPMN engine will fail due to missing implementation details.
Neglecting Version Alignment: When a Private Process changes internally, assess whether the Public Process interface contract is affected. Internal optimizations should not break external contracts.
A Public Process often serves as the participant view within a larger Choreography model. While the Choreography defines the global message exchange protocol among all parties, each party’s Public Process defines their local conformance to that protocol. The Private Process then implements the internal logic needed to fulfill that conformance.
Mastering the distinction between Private and Public Processes is foundational to effective BPMN modeling. Private Processes protect and document internal operational reality, while Public Processes enable clean, secure, and well-defined external collaboration. Together, they allow organizations to maintain operational transparency internally while presenting simplified, contractual interfaces externally—balancing agility with governance.
For practitioners implementing these concepts, professional modeling tooling significantly enhances accuracy and productivity. Visual Paradigm offers robust BPMN 2.0 support with dedicated features for distinguishing Private and Public process types, automated syntax validation to prevent Sequence Flow boundary violations, and seamless transition from abstract Public Process definitions to executable Private Process configurations. Its collaborative workspace also facilitates sharing Public Process models with external stakeholders while keeping Private Process details securely internalized, making it an excellent choice for organizations managing complex multi-party process architectures.
By applying the principles outlined in this guide and leveraging appropriate tooling, modelers can create BPMN artifacts that are simultaneously operationally precise, externally interoperable, and strategically protective of organizational knowledge.
