I recently went through the Constellation Adoption course again and revamped my notes as a quick refresher. Sharing them here in case they’re useful for anyone who wants to quickly revisit the key components of Constellation or brush up on the Constellation Adoption course.
These are my personal notes and key takeaways from the course. Please feel free to correct, add, or expand on anything I may have missed.
1. What is Constellation?
Constellation is Pega’s modern front-end architecture, built on the Constellation Design System using ReactJS. It separates:
UI / Presentation → Business Logic → Workflow
Three key shifts to keep in mind:
- Customization → Configuration
- Sections → Views
- Stateful → Stateless architecture
Importantly, in a Constellation app the server does not maintain a persistent requestor session — each request is processed independently, and the requestor session ends once the request completes.
2. Configuration over Customization
The recommended approach is:
Configuration → Extension → Custom UI
Constellation also moves away from Traditional UI concepts like Action Sets, favoring more declarative, model-driven behavior.
3. Views instead of Sections
Traditional UI leans on Sections/Harnesses. Constellation uses Views as the primary UI definition, and the UI is largely model-driven shaped by the Case Type Data Model.
Common View types:
- Full Page View
- Partial View
- List View
- Form View
(Views for data objects are also accessible via the UX tab on the data object.)
4. Data Pages in Constellation
No temporary pages here, the preferred approach is Data Pages/Data Views.
Because Constellation is stateless, there needs to be a way to tie server-side cached Data Pages to the right browser/request context that’s what psync_id is for.
A few things worth remembering:
- Editable Data Pages aren’t cached
- Single-page Data Pages aren’t cached
- Data Pages can also be cached client-side for performance
- Inspect client-side Data Page info via
PCore.getDataPageUtils()in the browser console
5. Portals, Landing Pages, and Views
Portal → Landing Page → View
- Portal: the overall UX/container (e.g., Work Portal, Self-Service Portal)
- Landing Page: major destinations within a portal (e.g., My Work, Explore Data)
- View: the actual UI used to display/interact with data or cases
6. Extending Constellation
A useful decision path when facing a requirement:
Can configuration solve it? → Can an existing component solve it? → DX Component → SDK / DX API
Lower investment:
- Constellation Portals
- Web Embed
- Constellation DX Components
Higher investment:
- Constellation SDKs
- Constellation DX API
7. Web Embed
Lets you embed Constellation UI components/widgets into external web pages , a common use case is exposing Pega-powered forms inside an org’s existing web app while keeping the experience seamless.
8. Constellation DX Components
Used when an out-of-the-box component can’t meet a requirement. Built with React, integrated with the design system and low-code authoring experience. Familiarity with PCore and PConnect client-side APIs is important here.
Three common types:
- Field Components – custom display for a field
- Widget Components – custom UI/functional experiences
- Layout Template Components – custom layouts
(DX Component Builder is installable via npm.)
9. Constellation SDKs
For building custom Constellation experiences with a different design system/front-end framework:
- Pega + Angular
- Pega + React
- Pega + Web Components
Useful when an org has strong branding/design-system/architecture requirements.
10. Constellation DX API
DX = Digital Experience. A set of model-driven REST APIs exposing Pega case data and UI metadata (from View Rules). Enables:
- Viewing/creating/updating cases
- Working with assignments
- Consuming Pega UI metadata
Key concept: the same DX APIs power both the out-of-the-box Constellation experience and custom front ends.
Pega Case + View Metadata
↓
Constellation DX API
↓
React / Angular / Web Components / Other Front End
11. Debugging Constellation Applications
- UI Inspector:
PCore.getDebugger().toggleInspector(); - XRay:
PCore.getDebugger().toggleXRay(true) - Tracer: use the View Rules option when troubleshooting View-related processing
- DebugPegaAPI: enable this Dynamic System Setting for verbose API debugging
12. Debugging Views
Inspect View JSON from Dev Studio by enabling the appropriate Constellation dev setting, including the pxEnableC11nDev When Rule where applicable useful for understanding what’s actually configured behind a View.
13. Browser DevTools
- Console – run PCore commands, inspect client-side behavior
- Network – filter by Fetch/XHR to inspect DX API calls (payloads, status, timing)
- Application – inspect Local Storage, Session Storage, browser-cached info
14. Debugging Data Pages
Client-side cached Data Pages are maintained outside of Redux. Inspect via:
PCore.getDataPageUtils();
Also handy: React Developer Tools, Redux DevTools.
15. Clipboard
Only partially supported in Constellation. Notably, it can’t be launched directly from the end-user portal the way it can in Traditional UI. This is why Browser DevTools, Tracer, UI Inspector, and XRay matter more here.
16. Portal Experience
- Work Portal – for complex, recurring workflows
- Self-Service Portal – for guided, occasional experiences (employee/customer self-service)
17. Traditional UI + Constellation Coexistence
You don’t have to convert an entire app at once. Some things to be aware of:
pyEnableTraditionalUICoexistencerule- Application definition/context setup
- Adding Traditional UI case types to the application
- Saving config into the correct application ruleset
- App Studio → Settings → Traditional UI in Constellation
- Generating required assets
Hope these notes are useful to anyone going through the Constellation Adoption journey.
