DX API + Public-Facing React App — Avoiding Per-User Operator ID Creation for Case Ownership

User Experience
1

Background / Architecture

We’re building a public-facing React application that communicates with Pega exclusively through the DX API. The flow is:

  • Users register and log in (SSO).
  • Each user creates one or more cases.
  • On return visits (potentially across future sessions), users see a dashboard listing only the cases they personally created.

This requires persistent, per-user identity and case-level access control — not just a stateless/anonymous interaction. Right now, every user gets an Operator ID created for DX API access, which doesn’t scale well and isn’t the recommended pattern.

We came across three commonly suggested approaches for this kind of setup, and wanted to open a discussion on the tradeoffs of each, since most of the documentation we’ve found focuses on portal-rendered UI rather than headless DX API consumers.

1. Anonymous Authentication with Limited Access Groups

Since anonymous requestors have no persistent identity, how would a returning user’s dashboard filter down to only their own cases?

  • Is the pattern here to store a custom ExternalUserID property on each case and enforce visibility via a Report Definition filter, rather than Pega’s native worklist/ownership model?
  • Is this a supported pattern specifically for DX API case-list endpoints (not just portal UI)?
  • Has anyone implemented row-level security this way for a headless/DX consumer? Any guidance or gotchas?

2. Progressive Authentication with Re-Authentication

This approach defers operator creation until “registration” — but in scenarios where essentially every user who wants to track cases will register, operator creation isn’t eliminated, just delayed.

  • Is this pattern intended mainly to reduce volume (only users who complete a case get an operator), or is it meant to eliminate operator creation entirely, even for authenticated returning users?
  • If the latter — how would case ownership persist for a user with no Operator ID?

3. External Identity Provider Integration (SAML/OIDC) — the one we’re most curious about

Our understanding is that even with external IdP auth, Pega’s requestor/access-group resolution for DX API still requires mapping the authenticated principal to some internal security context. Specifically:

  • Does external IdP auth still require an Operator ID instance per user under the hood (via operator ID mapping in the authentication service) — just created differently — or can many external users genuinely share one operator/access group, with ownership tracked purely via claims/external ID in case data?
  • If multiple users share an operator, how does DX API prevent User A from retrieving User B’s cases via case-list or case-view endpoints, given both would run under the same requestor/access group?
  • Is there a reference implementation anywhere for DX API + external IdP specifically? Most resources we’ve found cover portal-rendered UI, not a headless React + DX API setup.

Looking for

Has anyone in the community implemented one of these three patterns (or a hybrid) for a similar public-facing, case-per-user scenario? Interested in real-world experience — what worked, what didn’t, and any pitfalls to watch for before committing to a design .

Thanks in advance!

2

Hi,

I understand it is public website (not only employee facing) but will the users access app in a anonymous way or do they need to register before using app?

Second question, have you consider using SDK ?

3

Thanks for the questions — here’s the detail:

1. Anonymous vs. Registered Access

Users do need to authenticate before using the core features of the app. Specifically, they log in via (SSO) — this isn’t a generic anonymous or guest flow. Once authenticated, users create cases and later return (potentially across multiple sessions) to view a dashboard showing only the cases they personally created.

So while the app is publicly accessible, meaningful use (case creation and tracking) requires an authenticated, persistent identity tied to the user’s login — not a stateless anonymous session.

2. Have we considered the SDK?

Yes — we did try the Pega-provided SDK as a POC for this exact flow. However, we observed that an Operator ID is still being created during authentication, even though the user is authenticating externally . So in our testing, the SDK didn’t eliminate operator creation — it appears to follow the same underlying “one operator per user” pattern under the hood.

This is the crux of our concern: since this design is for a public, national-scale application, authentication via SSO could involve millions of citizens, and creating one Operator ID per user would result in millions of operator records over time — which goes against Pega’s own guidance on operator volume for public-facing apps.

What we’re trying to understand:

If one-operator-per-user is unavoidable with this flow, are there recommended patterns for managing operator records at this scale (archiving, purging, etc.) so it doesn’t become an operational burden?

4

can you please point me to those recommendations - so we are on the same page.

5

We raised this scenario as a support ticket with Pega Support, and their response included the following:

“The Operator ID infrastructure in Pega is designed for internal system users (employees, administrators) with complex security contexts, not for high-volume public user scenarios.”

Based on this, they recommended the three alternative patterns discussed above (anonymous authentication, progressive authentication, and external IdP integration) instead of creating an Operator ID per public user.

Attaching the response document for your review.

Uncontrolled growth of Operator ID.docx (20.8 KB)

6

Thank you for detailed response. Let me investigate it internally and see if I can formulate some best practices.