Modeling Reusable Processes with BPMN Call Activities: A Practical Guide in Visual Paradigm

Introduction

Business processes often share recurring work: verifying a customer, approving a request, checking credit, or issuing an invoice. Modeling that logic separately in every process creates duplication. When one copy changes and the others do not, teams can end up with inconsistent procedures.

BPMN’s Call Activity provides a way to reference a separately defined process from another process. It makes repeated work visible as a single activity in the main flow while allowing the called process to be modeled and maintained independently. In Visual Paradigm, this approach can help keep diagrams organized and make reusable process logic easier to discuss and refine.

 

 

Key Concepts

Call Activity

A Call Activity is an activity in one process that invokes a separately defined process—or, in some BPMN cases, a global task. It is the BPMN mechanism to consider when the behavior itself should be reused, rather than merely grouped for readability. Visual Paradigm describes a Call Activity as referencing an activity defined outside the current process definition.

In BPMN diagrams, a Call Activity is commonly shown with a thick border. A collapsed subprocess, by contrast, is embedded within its parent process and is commonly marked with a small plus sign. This visual distinction signals whether the activity references reusable behavior or contains detail belonging to the current process.

Called Process

The called process contains the work performed when the Call Activity is reached. For example, a reusable “Validate Customer” process might include checking required information, confirming the customer’s status, and returning a result.

A process is a good candidate for reuse when its purpose and steps are sufficiently consistent across its callers. If different teams use the same label for substantially different procedures, making one shared process may create confusion rather than consistency.

Calling Process

The calling process contains the Call Activity and the flow around it. It decides when the reusable work is needed and what happens afterward. For example, an order process might call “Validate Customer” before proceeding to payment.

Inputs, Outputs, and Contracts

A reusable process needs a clear agreement with its callers:

• Inputs: What information must the caller provide?

• Outputs: What result or information does the called process return?

• Outcomes: What should the caller do after success, rejection, or an exception?

BPMN execution tools may require explicit data mapping between the calling and called processes. Even for diagrams used only for communication, documenting these inputs and outputs helps make the process understandable and reusable.

Call Activity vs. Embedded Subprocess

Element	Best suited for	Relationship to parent process
Call Activity	Reusing separately defined process logic across multiple processes	References a separate process
Embedded subprocess	Grouping related steps that belong to one process, or simplifying its diagram	Defined within the parent process

Use an embedded subprocess when the goal is to organize detail. Use a Call Activity when the goal is to invoke a separately defined process.

When to Use a Call Activity

Consider a Call Activity when:

• The same well-defined procedure appears in more than one process.

• A shared procedure should be maintained separately from its callers.

• You want the main process diagram to show when reusable work happens without displaying every internal step.

• Different process owners need a common view of the responsibilities, inputs, and outcomes of a shared procedure.

Avoid creating a reusable process simply because two activities have similar names. First confirm that their purpose, rules, expected inputs, and outcomes are genuinely alike.

Example: Reusable Customer Validation

Suppose an organization validates customer information during both Order Processing and Loan Application Review.

The high-level flows could be:

Order Processing:
Start → Capture Order → Validate Customer → Check Inventory → Confirm Order → End

Loan Application Review:
Start → Receive Application → Validate Customer → Assess Application → Notify Applicant → End

In each parent process, Validate Customer is a Call Activity that references the same separately modeled process.

 

Its internal flow might be:

Start → Check Required Information → Verify Customer Record
      → Customer Valid?
          ├─ Yes → Return “Valid” → End
          └─ No  → Return “Needs Review” → End

Before implementing this in an executable workflow, define what information the callers must provide—such as a customer identifier and contact details—and what results the called process returns. Decide how each parent process responds to “Valid” and “Needs Review.” Those decisions make the reusable process’s contract clear rather than leaving callers to infer its behavior.

Modeling a Reusable Process in Visual Paradigm

Visual Paradigm supports BPMN modeling and provides tools for creating and organizing process diagrams. Its BPMN guidance describes Call Activities as references to activities defined outside the current process definition.

A practical modeling sequence is:

1. Choose a recurring procedure.
   Identify work that appears in multiple processes and confirm that it is consistent enough to standardize.

2. Define its purpose and boundaries.
   Give the reusable process a clear name, such as “Validate Customer.” Specify what starts it and what counts as completion.

3. List inputs and outcomes.
   Record what information callers must supply and what results they need back. Include important rejection or exception outcomes.

4. Create the called-process diagram.
   In Visual Paradigm, create a BPMN process diagram for the reusable procedure. Add its start and end events, tasks, gateways, and any relevant exceptions. Keep the diagram focused on the work the process actually performs.

5. Create each calling-process diagram.
   In the parent processes, place the Call Activity at the point where the reusable work occurs. Name it for the action—such as “Validate Customer”—rather than using a vague label like “Subprocess.”

6. Reference the reusable process.
   Set up the Call Activity to point to the separately defined process using the reference or linking mechanism available in your Visual Paradigm edition. Tool controls can vary by version, so check the application’s current BPMN documentation if a specific command is not visible.

7. Show the surrounding flow.
   Connect the Call Activity to the preceding and following activities with sequence flows. Use gateways where the returned result leads to different paths, such as continuing with an order or routing a customer record for review.

8. Review each caller.
   Confirm that every calling process provides the information the reusable process needs and handles its possible outcomes. Validate the model with the people responsible for both the shared procedure and the parent processes.

Good Modeling Practices

• Use action-oriented names. Prefer “Validate Customer” over “Customer Process.”

• Keep the reusable process cohesive. Its steps should support one clear business purpose.

• Make the interface explicit. Document inputs, outputs, and outcome meanings so each caller knows what to provide and how to continue.

• Handle exceptions intentionally. Decide what happens if required information is missing, a check fails, or the process cannot finish normally.

• Keep the parent diagram readable. Show the Call Activity and its place in the larger flow; keep detailed reusable logic in the called-process diagram.

• Review change impacts. A shared process change can affect every process that calls it. Identify and review those callers when updating its behavior.

• Do not confuse reuse with visual nesting. A Call Activity references a separate process; an embedded subprocess groups logic within its parent.

Common Mistakes

Using a Call Activity just to hide complexity: If the work is unique to one process and only needs grouping, an embedded subprocess may better express the model.

Leaving the process contract unclear: Callers may expect different input formats or interpret outcomes differently. Define these expectations before treating the process as reusable.

Modeling similar-looking work as identical: Two activities may share a name but differ in policy, decision rules, or ownership. Check the real work before consolidating it.

Ignoring downstream effects: Changes to a reusable process can affect all its callers. Review the calling processes and test relevant paths after a change.

Overcomplicating the shared process: Reuse is most helpful when the called process has a clear, stable purpose. If it accumulates unrelated responsibilities, consider whether it should be split or redesigned.

Conclusion

BPMN Call Activities help model shared business work as a separately defined process that can be invoked from multiple parent processes. They keep high-level diagrams focused while making reusable logic easier to standardize and maintain. In Visual Paradigm, model the called process separately, reference it from each caller, and clearly define the information and outcomes exchanged. The result is most useful when the shared work is genuinely consistent and every calling process understands its responsibilities.