Designing robust and maintainable applications in Pega often comes down to choosing the right process architecture. Two of the most powerful tools in our toolkit are subcases and callable processes. But when should you use each? Drawing from our internal best practices, here’s a practical guide to help you decide.
Subcases vs callable process.pdf (141 KB)
Thanks for publishing this. This document seems in line with how I might do things as well. I’ll just throw out another interesting edge case where you would use a combination of both. Let’s say that you have a centralized complaints application and each of your lines of business need to be able to generate complaints from their applications. When implementing this, the owner of the complaints application can create a reusable application (a complaints module) that the complaints app and host applications can include in their stack. The complaints app can provide a subflow that allows an application to document complaint details as defined by the complaints team and then the flow can invoke a service on the complaints implementation app that creates and tracks a case that lives in the complaint application (presumably on another Pega environment). So you have a subflow that plugs into your host case type that provides consistent execution of the host process generation without the host having to become an expert in complaints. You also could provide a full fledged case type in that module that could live in the host environment based on whatever makes the most sense. So, if you wanted to spin off and track that complaint in the host app, it could be spun off as a separate case, child or otherwise.
@ChrisBoone Great example! I really like how this approach combines reuse with visibility. I could see the complaint scenario you describe as very relevant in multiple industries–as well as the underlying combo: a reusable module with a subflow to capture complaint details consistently, then a service call to the central app to create and track the case. This design gives flexibility without losing standardization. Thanks for sharing!