We’re designing an automation solution for complex approval workflows that involve legacy systems without APIs. The debate in our team is whether to use RPA bots to navigate the legacy UIs and make approval decisions, or to extract data via RPA but keep the decision logic in BPM microflows.
The RPA-heavy approach would have bots handle the entire flow including decision-making based on business rules. The BPM-centric approach would use RPA only for data extraction, then process decisions through Mendix decision microflows.
Key considerations for us: auditability of automated decisions, long-term maintainability as business rules evolve, and integration complexity with our legacy systems. What are others’ experiences with these architectural patterns? Which approach provides better auditability? How maintainable is complex logic in RPA platforms versus BPM decision microflows?
After implementing both patterns across multiple clients, here’s my analysis of the three key considerations:
Auditability of Automation:
BPM-centric architecture wins decisively here. Mendix decision microflows provide:
- Built-in audit logging at every decision point with full variable state
- Visual representation of decision flows that non-technical stakeholders can review
- Integration with process mining tools to analyze decision patterns
- Compliance-ready audit trails with timestamps, user context, and decision rationale
RPA platforms have audit capabilities, but they’re typically focused on ‘what actions did the bot perform’ rather than ‘why was this decision made.’ For regulated industries (finance, healthcare, government), the BPM approach provides audit trails that map directly to compliance requirements.
Maintainability of Logic:
Again, BPM-centric approach is superior for several reasons:
- Business rules in microflows are maintained through standard SDLC with version control, testing, and deployment pipelines
- Changes to decision logic don’t require RPA script modifications, reducing brittleness
- When legacy system UIs change, you only update data extraction scripts, not decision logic
- Non-developers can understand and validate microflow decision logic more easily than RPA scripts
- Microflows support unit testing; RPA scripts are harder to test in isolation
The ‘rule duplication’ argument for keeping logic in RPA is actually a hidden benefit of BPM approach - you’re creating a modernized, maintainable version of business rules that can eventually replace the legacy system entirely.
Integration with Legacy Systems:
This is where the pattern choice matters most. Recommended architecture:
-
Data Extraction Layer (RPA): Bots navigate legacy UIs, extract data, and POST to Mendix REST endpoints. Keep this layer thin and focused solely on data access.
-
Decision Layer (BPM): Mendix microflows apply business rules, make approval decisions, and orchestrate the overall process. This layer owns the business logic.
-
Action Layer (RPA): When decisions require legacy system updates, Mendix queues actions that RPA bots execute. The bot receives structured instructions, not decision-making responsibility.
This separation provides:
- Resilience: Each layer can be independently scaled and recovered
- Flexibility: You can replace the RPA layer with APIs when legacy systems are modernized
- Clarity: Each component has a single responsibility
- Testability: Business logic can be tested without running RPA bots
Hybrid Approach for Pragmatism:
In practice, some decisions may need to stay in RPA temporarily:
- Decisions that require real-time data from multiple legacy screens with complex navigation
- Approval logic deeply embedded in legacy system workflows
- Scenarios where extracting decision data would require excessive RPA complexity
For these cases, implement a ‘decision justification’ pattern: RPA bot makes the decision but POSTs detailed justification data to Mendix for audit purposes. This provides audit trail while keeping integration practical.
Implementation Recommendation:
Start with BPM-centric architecture as your default pattern. Use RPA for legacy system integration (data extraction and action execution), but keep all business rules and decision logic in Mendix microflows. This provides the best balance of auditability, maintainability, and integration practicality. As your modernization progresses, the RPA layer can be gradually replaced with API integrations without touching your decision logic.
These are excellent perspectives. Susan, your point about creating a single source of truth resonates with our modernization goals. We’re not planning to keep these legacy systems forever. Raj, can you elaborate on how you structure the handoff between RPA data extraction and BPM decision processing? Do you use intermediate entities or direct microflow calls?
The handoff pattern Raj mentioned is critical. We use a queue-based approach: RPA bot extracts data and creates records in a staging entity, then triggers a microflow via REST API. The microflow processes business rules, makes decisions, and if action is needed in the legacy system, it queues a task back for the RPA bot. This decoupling provides resilience - if either the RPA bot or BPM engine has issues, you don’t lose data. For auditability, every stage is logged separately: extraction audit, decision audit, action audit. This satisfies even strict regulatory requirements.
I’ll offer a counterpoint. If your legacy systems contain the authoritative data for decisions and have complex navigation logic, keeping decision-making in the RPA bot can reduce integration complexity. You’re not duplicating business rules between systems. That said, this only works if your RPA platform has strong audit logging. Modern RPA tools like UiPath and Automation Anywhere have decent audit capabilities, but they’re not as granular as BPM engines. The maintainability concern is valid though - RPA scripts are more brittle than microflows when UI changes occur.
Kevin raises a good point about rule duplication, but I’d argue that’s actually a benefit of the BPM-centric approach. Extracting business rules from legacy systems into Mendix creates a single source of truth that can serve multiple processes. You’re essentially modernizing your decision logic while still operating the legacy systems. For auditability, consider regulatory requirements - can your RPA platform provide the audit trails that compliance needs? Most BPM platforms are designed with audit requirements in mind from the ground up. The integration with legacy systems argument cuts both ways - yes, RPA bots navigating UIs is complex, but that complexity should be isolated to data extraction, not entangled with business logic.