DX API to instantiate case in another Pega application

User Experience
1

Hi Team,

Happy new year to all.

I have two applications built on same division layer. Let’s assume App - A and App-B. App A has a case which used for user registration, another case in App B wants to call Registration case in App A. What are the design alternatives we have to implement this scenario.

  • We can use DX API to instantiate Registration case from App B. We need to create REST connector in App B and call DX API to instantiate Registration case from App B.
  • We can use Remote case feature to call Registration case in App A from App B.

Which design alternative is best suited in this scenario or is there any better way to implement the same. Please share your opinion on this.

Thanks

Rajesh

2

@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

3

Thanks @JayachandraSiddipeta for your reply.

4

@RajeshKumarY6297 all options provided by @JayachandraSiddipeta are valid. Please consider if you need runtime reuse (dx api and remote case types) or also design time reuse (option 3)

5

@RajeshKumarY6297

My 2 cents…

The best option is to go with a modular application or common application that will be built on both App A and B. This helps to ensure to scale for future applications.. We noticed a lag time while launching the remote cases because it has to make the connection and render the screens. The Proxy cases created in Application B with the remote case type. Please go over the limitations with Remote case type before you take the decission - Pegasystems Documentation

  1. If the information is readily available in Application B, then use DX APIs to create the Registration case in Application A

  2. If the intake process for the Registration needs to happen in Application B as the users may have more context, then use Remote case type.