@RajeshKumarY6297Yours is very common cross-app orchestration question in Pega.

When two Pega applications live in the same Division layer, this is less of an integration problem and more of a reuse and ownership decision.

You have App A, which owns a Registration case, and App B, which wants to initiate that registration flow. There are a few valid ways to do this, but not all of them are equally suited as per the nature of application and ecosystem it exists in.

Option 1: Remote Case (Recommended in most cases)

Using Remote Case feature, App B can invoke the Registration case in App A while App A continues to own the full lifecycle.

This approach keeps both apps loosely coupled and aligns well with Pega’s case management principles. You get OOTB handling for status updates, data exchange, erroneous scenarios, and overall case visibility. All this without writing REST plumbing.

Best fit when:
Registration is a real business process with its own lifecycle and App A should remain the system of record.

Option 2: DX API via REST Connector

Technically, App B can call App A’s DX API to create the Registration case using a REST connector. While this works, it’s usually not the best choice when both apps are on the same Pega platform.

DX APIs are designed more for external or headless consumers, not internal app-to-app orchestration. This option adds tighter coupling, more maintenance, and manual error handling, all this without much benefit in this scenario.

Best fit when:
Apps are on different Pega systems or the caller is a non-Pega client.

Option 3: Shared Case via Framework or Common App (Cleanest Architecture)

If Registration is a core, reusable capability, the cleanest solution is to move it into a shared framework or base application that both App A and App B are built on.

This avoids integration entirely with no REST calls, no remote configuration and just straightforward reuse through inheritance.

Best fit when:
Registration is an enterprise capability expected to be reused across multiple apps.

My Recommendation

Since both apps are on the same Division and same Pega system,

• Best long-term option: Shared framework / common app
• Best decoupled option: Remote Case
• Avoid unless necessary: DX API

Simple thumb rule : If it’s a case, use case patterns (shared or remote). If it’s a service, use APIs.

This keeps the design clean, scalable, and aligned with how Pega is meant to be used.

Let us know you if you any further queries on the above recommendation. Other community members may also want to add their 2 cents here.

Regards

JC