The LSA's role is to know which UI architecture is going to best position the customer for success given the customer's goals and roadmap. The LSA does not need to be an expert front-end developer but does know the capabilities and limitations of each of the Pega UI architectural approaches and feature set.

The more acquainted the LSA is with modern front-end development technology and design, the better they can have these conversations. The key thing is that LSA knows what Pega has to offer and how to help the client make the best architectural choice for their organization.

The Pega UI developer in Constellation configures user experiences in App Studio by assembling channels, landing pages and insights. For each of the steps in a case type workflow, a view is configured. At the View level, they focus on identifying the fields that need to be shown or captured to complete a step in the workflow; each configured to use the most appropriate component available from Constellation for the situation. Constellation also makes best practice user experience patterns available (for example, the "Search and Select" pattern as showcased in this event) for Pega UI developers to configure outcomes in their application, rather than custom-building these patterns from scratch.

In the rare case where customized components are needed that are not available from Constellation's component library, professional front-end developers can be engaged to implement these as reusable components using React and publish them to Pega Infinity. Once published, the components become available for selection in App Studio in the right context and become available to the users' browser alongside the Constellation component library.

Pega System Architects are not expected to become professional front-end React developers, and it is expected that the Constellation component library will meet the vast majority of your clients' user experience needs. Delivery teams will benefit from having access to such front-end development expertise whose involvement would likely be on-demand.

The Pega Docs do cover a lot of the limitations. We endeavour to keep these updated and current, as well as providing insights into future features.

If you follow the "Choosing a UI for your application" flow-chart based on your current (and near future) understanding you should be OK.

Constellation offers rich capabilities for working with tabular data including grouping, sorting and filtering.

Constellation also offers the preview panel, allowing users to preview another object (case or data object) without navigating away from a table of objects. The preview panel can show additional information about the object.

Nested table and the traditional master/detail are not in Constellation, however with a mindset of delivering the required outcomes (over resurrecting patterns unique to the Traditional UI architecture), Constellation's OOTB UX can likely achieve the required outcome.

Constellation's goals include consistency of common high value patterns across the application portfolio, faster development time, less errors, and OOTB front-end and Accessibility best practices. To achieve this, many typical UX patterns developers repeatedly built with Action Sets are now offered in Constellation OOTB. Developers configure the pattern in App Studio, rather than custom-building the pattern in Dev Studio.

As an example, consider an "Add" button positioned at the top of a table:

• Configured with OnClick and an Action Set in the traditional architecture, the button renders a modal to capture inputs for a new record and refreshes the table.
• In Constellation, developers use App Studio to simply enable "Add new" on the table; Constellation generates everything needed to fulfil the same end to end outcome - the UX, the eventing, and the plumbing.

See also the "Search and Select pattern" videos above for another example.

For very advanced use cases, Constellation provides developers an extension point: a way to build a custom DX component. The components in Constellation's design system are available at https://design.pega.com in the event that a pattern not yet available in Constellation needs to be implemented.

For increased consistency, faster time to value, less errors, and less code maintainence, we encourage clients to leverage OOTB configurations where possible and leverage custom DX components only for advanced use cases.

We encourage clients to leverage App Studio to configure the outcomes they need.

For advanced use cases that require putting together Constellation's presentations components in a different way to build a new pattern, front-end developers experienced in React, HTML, CSS, and JavaScript can extend the UX library using custom DX components.

Are we suppose to do the UX/UI designs with Summary, Activity, Utility (SUA) panels introduced recently or can we continue using the client's branding guidelines? 

Will we miss out a lot in future upgrades if we do not stick to SUA panel design?

Using App Studio's branding and theming capabilities (and the presentational component's design tokens for more granular control of supported styling customizations), developers can adhere to the organization's styling and branding guidlines (font-face, rounded corners, color schems, etc).

If this question is about using an entirely different design system instead of Constellation OOTB design system, then the Constellation architecture is built to allow customers the flexibility to use their own design system using Constellation SDKs for React, Angular and Web Components. While this requires more investment compared with using pure Constellation, and you own the front-end, you're still leveraging the power of the model to build the flow, field validations, layouts, visibility conditions, etc. This still saves you time over a custom-built front-end, as you configure the workflow and UI needs once - in Pega's model - and the front-end implementation reflects the changes.

Constellation added Get Next Work in Pega Platform 8.8, but its not available in 8.7. Is there any way to achieve Get Next Work in Constellation for 8.7?

What version is Web Embed being introduced?

Will Mashups be possible and/or discouraged going forward?

Web Embed was introduced in 8.7.

• Pega Web Mashup is for embedding UI built using Traditional UI architecture;
• Web Embed is for embedding UI built using Constellation UI architecture.

We continue to support both, and Pega Web Mashup remains a critical capability.

In my application, can I have both UI-Kit and Constellation built-on applications?

Most of our organization layer extends UI-Kit. Now the only way I see to adopt Constellation is to create another app rule with a new name and the same set of rulesets.

As of 8.8, this is not recommended best practice. As of 8.9, we expect to communicate a clear co-existence strategy and guidance on tooling. 

You can run the complete case built with either Traditional UI technology or Constellation UI technology in the same portal. However, you cannot intermix the lower level UI components.

For example, you can't use a traditional Button control with an Action Set inside of a View built with Constellation.

In terms of existing applications built with UI-Kit, the case itself will look different than the case built with Constellation. The common overall portal (that wraps everything) is intended to bring a common header and common nav, which hopefully reduces the confusion.

If the existing case type is built with Theme-Cosmos, then the experience is the same as Constellation, so the users will likely not notice a difference.

Custom DX components are intended to be built only by professional front-end developers as they will also need support in production, so the audience for this training is a bit different. Availability of a training course - and whether Pega Academy is the right place for it - is still under discussion.

We are soon releasing comprehensive tutorials focused on the developer experience when creating custom DX components and how to use Storybook.

Strongly challenge whether a custom template or widget is actually needed. The same business outcome can likely be realized with the OOTB Constellation component library., and custom components add to your client's total cost of ownership.

If you really need to you can create custom DX components for Template Form/Details/Page Layouts or Widgets, these are custom Javascript components. The DX Component Builder will provide generated code samples to get you started as well as a sample story for Storybook.

Suppose you wanted a Slider control for specifying the value of an integer field. You could use our tooling to:

1. Scaffold the control
2. Build the presentational component in tooling of your choice
3. Publish it back to the Pega Infinity server

Then when when configuring a View in App Studio that captures Integer data, you could then choose to render the Integer as the Slider instead of a numeric text box

Is overriding the existing DX component implementation allowed? If I need to enhance the component with an additional parameter for example?

I am concerned that it might become similar to "Save As" or a "fork"?

Overriding out-the-box components is not planned. Aim of how to get the business outcome needed from the OOTB components available to minimise your client's total cost of ownership and update risk.

App Studio does not make buttons and other types of controls (that we are used to from the Traditional UI architecture) available when configurating Constellation views.

Is customizing how a field is rendered only possible using a custom DX component?

Constellation is not intended to be a one for one replacement for Traditional UI architecture.

Challenge whether you can accomplish the required business outcome using the OOTB Constellation components and their configuration options. You should be able to build the right outcome by keeping within the model and avoiding custom DX components unless there is no other way and your client is accepts the cost of ownership this would introduce.

The main options here are:

• Custom DX component authoring to extend the usage of the Pega-native Constellation UI to include client-specific controls
• Use the SDKs in React, Angular and Web Components if your client is pushing for adopting a complete design system onto the Constellation architecture

The Constellation Angular SDK is for rendering a custom front-end based on Angular.

In App Studio, you author Constellation apps the same as you do now, even when they are intended to be presented in Angular. App Studio captures the UI model, and this in turn drives how the Constellation apps render using Pega's OOTB Constellation UI, as well as UIs based on the Constellation SDKs.

The SDKs are not intended as a drop-in replacement for Constellation front-end and there will not be feature parity between SDKs and Constellation Design System rendered applications.

Constellation DX API is intended for use with Constellation based applications. Some endpoints will work for both where there is no View-based data.

Avoid mixing and matching APIs for normal case processing.

Does Pega provides a Typescript project template for front-end developers who want to start with development of the UI from scratch (not using Constellation)?

We have a set of open source SDKs for Constellation, built on Typescript available at Pega's GitHub site. Look for React ADK, Angular SDK and Web Components SDK.

Everything you need to get started is included. There are a comprehensive set of components as well as sample applications to get you started quickly. You can also submit Pull Requests and get involved.

Migration Planning Accelerator will be offered as a downloadable RAP in Pega Platform 8.9.

It is compatible with apps built in Pega 7.x and above.

What are the UI/UX considerations for a customer modernization journey?

How can we better assure that the modernization journey does not get derailed by extensive UI/UX rework?

Modernization means not only improving the UI/UX, but also the performance, maintainability, and cost of ownership of the entire application.

Clients should consider the value proposition of Constellation's prescriptive UX. That is, adopting the OOTB UX patterns that are quick to configure, deliering quicker time to value, with built-in front-end and accessibility best practices.

• For Client-Managed Cloud clients: yes
• For Pega Cloud customers: this is all transparent

The static UI service can be downloaded as a container.

See the following articles for more information:

• Constellation UI service
• Constellation service deployment

Insights leverage both the Pega database and Elasticsearch for querying, depending on the complexity of the Insight design and the configuration options of the Report Definitions that retrieve the records used by Explore Data.

When Explore Data can retrieve data from Elasticsearch, the performance impact on the Platform is minimized.

Can I explore single-page embedded pages on cases?

For example: a Delivery Address embedded in Purchase Order cases

Insights can be built from external data sources only when that data is brought into the Pega ecosystem. We are looking towards expanding upon that in future, but as of version 8.7 it is internally-focused.

Can Insights help to load huge data volumes, such as historical data say up to one year old?

Insights will query the Elasticsearch index when instructed, falling back to the application database when querying for a feature that is not yet supported in Elasticsearch.

Having the data driving these insights indexed in Elasticsearch can help with performant data analysis of large volumes of data. Your client's business intelligence requirements may still dictate that extracting this data to a data warehouse is preferred to performing this analysis on the operational database. As such, data extraction using tools like BIX remains part of the story.