The BPM Blind Spot: Making Third-Party System Actions Visible

The Invisible Problem in BPM

Business Process Management (BPM) promises transparency. You model your processes, automate tasks, and track execution, but some critical parts remain invisible: User activities and external system calls are black boxes. You see when a task starts and ends, but not what happens inside.

This lack of visibility creates blind spots. Is the user struggling with a poorly designed form? Is the third-party system slow? You can’t tell. Without insights into these (black) boxes, optimization is guesswork.

What BPM sees – and what remains invisible

Why Traditional Monitoring Falls Short

Standard BPM monitoring tracks process instances and calculates KPIs like cycle time. But it stops at system boundaries. External services, developed by other teams or vendors, are opaque. Human interaction in third-party applications during User tasks? Also invisible.

Process mining can help, but it works backward from logs. You’re limited to existing data, and establishing relationships between third-party events and business cases happens after the fact. The granularity is fixed by what’s already logged.

Why We Tolerate the Blind Spot

The blind spot isn't just a technical gap, it persists for organizational reasons. Third-party systems usually belong to a different team or vendor, so gaining information from them means crossing a boundary you don't control. BPM tooling was built to track orchestration, not execution internals, so teams default to what the engine already gives them. And under delivery pressure, wiring up cross-system observability loses out to shipping the next integration. So it becomes something you bolt on after an incident, not something you design in from day one.

The Idea: Combining BPM with Application Performance Monitoring

What if you could monitor third-party systems at runtime, without modifying their source code? Application Performance Monitoring (APM) makes this possible.

APM allows you to dynamically monitor external systems at runtime, without touching their source code. By instrumenting external systems dynamically, you can capture technical events: method calls, database queries, HTTP requests. Capturing technical events (method calls, HTTP requests), it might turn these black boxes into transparent traces. The question is: Can we link these traces back to BPM?"

The key is correlation. Link APM events to BPM process instances using unique identifiers, passed via URL parameters, HTTP headers, or session tokens or naturally contained in your business data. Without event processing, you’re left with isolated streams of data. BPM events tell you what happened in your process, APM events tell you what happened in external systems, but neither tells you how they relate.

The Architecture: How It All Connects

The architecture idea connects previously isolated worlds. At its core, it’s about bringing together two types of event sources.

Process engines emit business events: process instance started, task completed, user interaction recorded. Instrumented third-party systems emit technical events: service calls, database operations, UI interactions. These streams flow into an event processor.

The processor’s job is to correlate these streams. Correlation is what links a database query in a third-party system to the user task that triggered it. Without this step, you have two isolated views: business events that lack technical detail, and technical events that lack business context. A Correlator component could be a custom OTEL Collector or a component working with Complex Event Processing (CEP), a high-level query language to define patterns and aggregate events e.g.

Correlation works by propagating identifiers from the BPM system into the third-party systems. For web applications, these travel via URL parameters or HTTP headers. For non-web systems, business keys like order numbers or case IDs serve as natural correlation points.

The Architecture: Instrumentation and Correlation for a Holistic View

Open Questions

Runtime instrumentation is powerful but not universal. Some prerequisites apply:

Access: You need the ability to attach a monitoring agent to the third-party system at runtime. So how can you gather traces from SaaS applications or tightly controlled environments?

Knowledge: Instrumenting unfamiliar systems requires understanding where to hook in. Without source code or documentation, identifying the right method names and execution paths can be time-consuming.

Language support: Bytecode instrumentation works well for JVM and .NET applications e.g. For other languages, open-source tooling may be limited or non-existent. So how do we handle languages without open-source APM tools? Presumably you need to publish your events in such environments more explicitly.

When instrumentation isn’t an option, alternatives exist. Log analysis can work if logs contain sufficient detail and unique identifiers. Network-level monitoring via port mirroring captures traffic without application changes. As a last resort, modifying the third-party system’s source code to emit events remains an option, though this defeats the purpose of non-invasive monitoring.

Why This Changes Things

End-to-end process visibility transforms how you manage and improve your operations.

With correlated events, you gain the ability to:

• Pinpoint bottlenecks: Identify slow external service calls that delay your entire process, not just the symptoms.
• Analyze user behavior: See exactly how users interact with third-party systems during their tasks, revealing usability issues.
• Measure accurately: Calculate true time-on-task metrics that include all activities, not just the orchestrated steps.
• Detect issues early: Spot anomalies in real-time rather than discovering them during post-mortems.

Instead of managing processes with blind spots, you gain complete transparency. Every action, in every system, becomes visible and measurable. This is more than better monitoring, it’s the foundation for meaningful process optimization.

And with the rise of AI agents acting autonomously in business processes, end-to-end visibility is no longer optional: you can’t improve what you can’t see, and you can’t trust what you can’t trace.