During my ongoing discussions with clients and partners about the adoption of Constellation, one topic consistently surfaces: buttons and action sets.

Historically, Pega was well-known for its flexibility and the ability to be fully customized, which set it apart from competitors. With Constellation, the focus has shifted to a more prescribed approach. Has Pega lost the ability to meet the diverse business requirements of its enterprise clients? Let’s explore this further.

Why Can't You Place Buttons Anywhere on the Screen?

You might wonder why you can’t place buttons wherever you like and attach custom logic to action sets. Technically, Pega could support this, but it's not implemented for several reasons:

• Action sets with multiple actions and screen refreshes are hard to debug.
• They're difficult to maintain.
• Hardcoding business logic into the UI is a poor practice.
• It leads to designs that don’t follow a center-out approach, meaning you'd need to reimplement logic for different channels.

Let’s be honest, developers have overused action sets because it was often the quickest way to implement client requests. The typical scenario? A client wants more and more features in the same screen, pushing for something like "Excel inside Pega." Developers keep adding these features, to keep business happy but at the same time leading to messy code that's difficult to maintain.

The Solution: Focus on Business Outcomes

The key to solving this common issue is to focus on business requirements and outcomes, rather than UI elements. When implementing Pega with Constellation, we should translate requirements into data model entities and case management features, not directly into UI controls. Constellation’s prescribed approach starts with the case lifecycle and supporting data model—then the UI follows. The UI is dictated based on the data model, not in the opposite direction.

Let’s now look at the options Constellation and Pega’s case management offer to achieve business outcomes. Remember, a button is never a requirement—it’s just one way to implement a particular need. You can still render buttons within Constellation. It’s not a technical limitation, believe me. Constellation simply aims to avoid cluttered screens with unnecessary buttons placed in random places.

Constellation's way of working

With Constellation, you have several options that replace the need to add buttons arbitrarily across the screen, while still providing rich interactive UI elements.

1. Calculated Fields

You can use Calculated Fields to create interactive UIs. When the input to a calculation changes, the field is recalculated and automatically refreshed if displayed on the current screen.

2. Flow Refresh

A new configuration is available on Flow Actions, allowing you to specify "watched fields." If a user changes one of these fields, a configured Data Transform runs in the background to modify the data. This powerful pattern allows you to react to user actions without cluttering the UI.

3. Break Complex Screens into Steps

Pega is neither a website builder nor an Excel clone. We should leverage Pega’s strengths— particularly its case management capabilities. Complex screens should be broken down into smaller, atomic assignments. This allows you to take full advantage of features like SLAs, routing, case locking, and data processing. While it might require from a user an extra click or two, this is the most effective way to design in Pega.

4. Model Processes Within the Case Lifecycle

One of the biggest issues with action sets is that they allow for embedding case lifecycle logic into the UI. This is a shortcut that leads to solutions that are hardcoded for one channel and difficult to maintain or debug. It’s also not inclusive for citizen developers, who may struggle to understand action sets' configuration. However, if the logic is modeled within the case type lifecycle, it can be seen and understood from App Studio. Keeping the logic within the case lifecycle (e.g., automation in flows triggered upon step submission) is far more sustainable than embedding it in buttons.

5. React to Events

Thanks to Constellation's modern architecture, along with its Messaging Service and DX Components, you can implement a Publish-Subscribe pattern to refresh the UI based on background events. This replaces the outdated pattern of users manually refreshing the screen, which wasn't ideal from a UX perspective.

6. Use Out-of-the-Box Patterns

While you can’t directly add a button to a View, configuring some patterns can result in a button being present on the screen. This is the case with the Search and Select pattern, where configuring it with Data Reference fields will display a search button. 

If You Still Need a Button

In rare cases where the solutions above don’t meet your needs, you can add a button to the screen using a DX Component. Check out the Actionable Button component here: Pega Constellation UI Gallery.

Keep in mind that this component triggers a Local Action, not an activity directly. As mentioned before, the goal is to keep logic out of the UI and within the case lifecycle. Since Local Actions are part of the case lifecycle, they are returned via DX APIs, meaning they can be implemented across multiple channels and UIs, this is what we strive for.

However, if a Local Action can be displayed under the Actions menu on a case, ready to use whenever needed (and controlled by a When rule), do you really still need a button cluttering the screen and confusing users? In most cases, it’s unnecessary.