PegaWorld iNspire 2024: Reach for the Stars: Unleash Innovative, Exceptional and Accessible Experiences with Pega Constellation Today!

Welcome to reach for the stars, this year's User Experience breakout session. Brought to you by Pega. My name is Caroline Power. I joined Pega back in 2008, and I've been shadowing our product, engineering and global support teams for 22 months to understand how people are adopting Pega Infinity Constellation architecture. Today, what I want to do for everybody is level set, what Constellation is all about, and then share with you what we've learned in terms of what works for adoption. I'm joined today by Sam Alexander. He's Pega's principal product manager, responsible for all things user experience. Out of the box. Sam's going to talk about the motivations behind Constellation.

I'm also joined by Sean Ward's Pega senior director of Shared User users experiences. He's responsible globally for all of the extension points, all of the out-of-the-box user experiences, and everything else in between for Pega's architecture. Sean's going to talk about the what of Constellation. And last, I'll share how how we envision adoption for the latest and greatest of Pega's user experience architecture. Before we get started though, we're going to take a little trip down memory lane. We're going to talk about 2004. Sam 2004 was a long time ago. I'm trying to think 2004. What was new back then?

George Bush was just reelected president. Web 2.0 was just in its early stages of interacting on the internet, back and forth, not just publishing content and consuming it. Sam, do you remember 2004? I do. I know you're probably surprised. You're thinking he probably wasn't alive back then, but no, I I do remember 2004 very well, and what I remember most about 2004 was a really special vacation. I flew 2000 miles off the coast of California to that magical archipelago, Hawaii. Amazing vacation. Obviously the beaches, the food.

I'm getting some echo. Do you hear that? I do hear a little bit of echo. It gets the. Partiers. There's a party back there. Anyway, back to my more important story. My vacation. Amazing food, amazing beaches, but also exploring lava.

Active lava, but also past lava flows where you could explore. And there would be a sign that would say lava flow from 1978, and it would just go right across the road and the road would end. Amazing. And also snorkeling. And to find sea turtles. Amazing. They would just kind of float by, right? I love it. You know, I was kidding around with Caroline and Sean before this.

I said really quick if I'm going to Hawaii and I've never been there before, what are some essential items I must have? And Caroline said. Hawaiian shirts. A Hawaiian shirt. And that was that was the second thing that I got when I got to Hawaii. But there was something more fundamental that I needed when I was planning my trip to Hawaii, because this was 20 years ago. So the first thing that I went out to buy in planning for my Hawaii trip was a map, a paper map and a paper guidebook, a paper map and a paper guidebook. And. What amazing transformation and modernization has happened since then, right?

We know that the the maps were replaced by. I think we've got some technical difficulties. Modern technology. Thank you. Crowd participation I love it. Those maps were replaced by remember those Garmin devices I remember going to Costco to get one, and then those Garmin devices were replaced by the navigational apps on our phone, obviously. And even when I rented a car in Hawaii, even rental cars are somewhat being displaced by rideshares and even self-driving cars. All of this rapid transformation and modernization that was happening in this was driven by technology, the way we not only navigate, but the way we communicate with apps like FaceTime, the way that we monitor our homes. A few minutes ago, I see that my children are in the backyard, the way that even the way that we get work done in the enterprise, rapid modernization and transformation software at the heart of it.

And during this rapid modernization and transformation in software, Pega was modernizing and transforming. And we're still doing so today. Let's continue taking a trip down memory lane. Sean, tell us about Pega UI circa 2004. Well, Pega was different 20 years ago. 2004 there were, for instance, no stages and steps, no case designer. So one edited workflow via a Visio canvas interface. But 2004 was about the time that Pega introduced sections and harnesses the core of what we now call traditional UI. That's in contrast to Constellation.

The new section rules presented a Wysiwyg or I would say Wysiwyg ish experience, wherein a lot of core application business logic was captured directly into the UI. So thus app building from 2004 on became UI first what I call UI first, which means that your apps start essentially with a blank UI canvas. You drag elements like buttons and fields onto that canvas, and then you apply business logic, data, and actions to each element. This UI or canvas based approach is visual first, and what it does is it locks critical business logic into the presentation. Since developers at that time were focused only on a single channel type, there was no mobile in 2004 and had a very limited toolbox to work from essentially only tables and what we call smart layouts. At that time, what was built in the field had relatively little customization, but by the mid 20 tens, with the advent of Cloud Rest APIs, statelessness, single page application tech, the iPhone mobile apps, the expectations for UX and UI had mounted considerably. So in Pega seven, we introduced a much modernized set of tools, which were then added to traditional UI. But that essential architecture UI first approach the blending of business logic, data and presentation. It remained, and this opened the door for enormous customization.

Now, traditional UI has had a very, very strong run in those 20 years. Indeed, Pega became $1 billion business as much on the back of traditional UI as anything else. But we did hear from you about some critical challenges. We did, and it has had a long run. But we did hear from you about some critical challenges, challenges that we noticed, but challenges that you told us about. I want to step you through some of those challenges with the traditional UI development. Let's start with the number. Number one item here, UI development was disproportionately costly to you. Costly in time and money.

And why is that? Well, as we know, Pega UI development required deep knowledge. I like to refer to it as a PhD in Pega UI. We have Pega centric constructs like harness. That was my favorite when I joined Pega. What is it? does it perform? Harness a confirm harness. Right.

We had these constructs. Container format, container dynamic layout, property panels, action sets, all these very deep Pega UI constructs. Right. And in addition to that, you incorporated other front end technologies that also require deep knowledge in CSS and HTML and JavaScript. So disproportionately costly in terms of requiring deep knowledge for that type of thing. Also, Pega UI development was costly in that it required long development cycles of heavy design and then development. Right. I'm going to have a designer. They're going to build a UI, and I'm going to hand it over to the developer, and you build it and you make it pixel perfect, right.

So beyond that, not only that, but also there were even long discussions on UI preferences, customers would, you know, talking about in a modal dialog, should the buttons be on the right or should it be on the left? Right. So long discussions on UI preferences. And also, as Sean mentioned, because this traditional architecture was really powerful and you could build any UI you want to. Often that resulted in business logic being interwoven into the UI programing to the channel, right? Returning different markup depending on if it's mobile or if it's desktop or something like that. So that was one of the biggest challenges related to that. Another thing that we noticed and that you told us about was that UI upgrades were, we say, very hard, but it was sometimes horrible. I do have one customer that is on UI kit version one, right?

And we're at UI kit version 15 these days, right? So why is that? It's because the same thing, because of the save as mentality of building UI. We give you a UI and you can do a save as a fork. Right? And that's the same thing as getting a Microsoft word document that you're collaborating on. If you do a save, as in the original changes. Now you have to reconcile your changes with the original document. And that's the same thing with Pega EY.

If Pega would come along and make a critical bug fix, or an accessibility bug fix or something, make a change or an improvement in that piece of UI, now it's up to you to reconcile your changes with ours, and also because you would incorporate tons of CSS and JavaScript that often resulted in broken UI upgrades. So UI upgrades were very hard just by water. We noticed, and you told us increasingly that accessibility is becoming front of mind accessibility, compliance. This is a big deal. I don't know about you, but I can't keep track of the changes in accessibility that are happening. Take a look at that screenshot. Can you tell the difference between complementary and. Center info. I can't remember, I'd have to go look it up.

This is the point because you could build any UI you wanted to. It was up to the developer to have deep skills in accessibility, and you must make sure that you set the right accessibility rules in your UI. Right. And this is a big deal. I put a screenshot here of a recent Forbes article from a few months ago. Lawsuits regarding failed accessibility are on the rise, so this is something to pay attention to. Let's move on to the next one. We noticed and you heard us. We noticed and you told us that duplicating UI is costly, right?

The same fundamental patterns, slightly different. The same pattern being implemented in different ways. When you build the same pattern over and over again, obviously development time is increased. But also your rule maintenance increases, your rule maintenance increases, and your risk of introducing bugs increases. And then also for our end users, it's an inconsistent user experience for the same fundamental pattern. Why not have one pattern and build it in one way? Users want to know what to expect. So finally, if we go to the next slide, we notice in you told us that scalability and performance is critical. The traditional stateful architecture made it very difficult to scale up and down nodes in the cluster in a cloud environment, and to make current to make concurrent requests to the server for lightning fast speed parallelism.

Right. So this is something that we noticed and you told us so in review UI development very costly UI upgrades were horrendous. Accessibility became front. And mind you were duplicating code over and over again. And finally scalability and performance. So we have a plan for that. And I'll turn it back to Shawn to tell us about that. Well, what we did was we envisioned modernizing the tech stack for improved performance, for scalability, reduce build time, maintenance, everything that Sam outlined that we noticed and you told us about, we declared basically that business logic should be out of the UI, right? We should have a separation of concerns.

The server would handle the business logic and data access, and the client UI handles presentation logic. We would be Center-out. That's what we call it now. We would have a Rest API based open client server architecture using industry standards that allow integration at different layers of the stack. We would use single page app technology, which delivers true cross-channel compatibility and great performance. Single page app tech, often built on React or Angular is typically Rest API based, typically stateless, and usually follows an essential principle that that an entire UX system exists on the client, the browser, or the mobile device before any data is exchanged and before any business logic is initialized, right? So you've all experienced this principle when you've downloaded a mobile app from the App Store, what you download typically is just the UI. And then once set up, now data is exchanged with the server, and that happens seamlessly without waiting on the server for UI. And this ensures a great user experience.

So thus we decided to build a complete UX system to be delivered to the client to the browser. OK. Thus, the birth of Pega Constellation. And we announced our plans in 2019 and it has been delivered. It's now very mature and it's now being used in production applications all over the world by many customers. All Pega developers should be feeling comfortable with Constellation. Now I'm just going to pause to define what the term Constellation Pega Constellation is for anyone who's not familiar with it, but it is a feature of the Infinity platform. It's the name of our current UI architecture, our current UI technology, our current UI authoring experiences, and also the name of our current out of the box end user experiences. So a complete UX system out of the box.

And if we were going to redesign such a system from the ground up, it made sense to deliver one that accelerates end user productivity. Designed around how Pega uniquely delivers workflow to users. A little bit more on that in just a moment, and one that puts accessibility first. A complete UX system to help minimize build time by creating outstanding experiences out of the box and an authoring experience focused on outcomes, not UI creation. And at the same time, an architecture which is going to allow you to bring your own UX if you need it. OK Constellation is to UI what stages and steps the case designer was for workflow before the case designer spaghetti flow monsters like this one dominated. And I actually met a customer today that their business is built on 9000 of these that are pre stages and steps. Developers built apps in an ad hoc manner without structure. And the result was opaque business logic which took probably too long to deliver and which only the original developers really understood.

This is Pega smart dispute by the way before stages and steps. And this is it. After being converted to stages and steps, stages and steps created a really clear organization, a structure, a rule schema where app building became more predictable and easier for both business and it to understand and to collaborate upon. Constellation does the very same thing with UI. Just as we battled Spaghetti Flow monsters, we battled spaghetti section monsters where business logic in the form of conditional visibility, embedded sections, action sets also made business logic opaque and took too long to deliver. Constellation provides a new framework for UI, which abstracts and organizes data and workflow logic and places them into a semantic structure which corresponds to regions on the screen. As a UX person, this is an incredibly exciting Evolution. The Constellation authoring experience extends the case designer, which did the same thing for workflow, greatly reducing enterprise application building. Indeed, Constellation UI authoring is literally a tab in the case designer.

If you've tried Pega Blueprint and I hope you have by this point, you can see an almost magical display of this semantic structure in action. Blueprint flows data and workflow into the essential framework that makes up Constellation. Screen regions, forms, menus, panels, utilities, etc. it's structured. It has. It is organized and it's instantly assembled. This would not, could not, will not be possible with UIKit with the previous architecture. So there's great value in adopting to Constellation standards for Pega apps. The Constellation UX system conforms to front end best practices out of the box, including accessibility.

Indeed, Constellation has been developed as accessible. First, everything we add to the system has been pored over for accessibility, working with some of our most accessibly conscious customers. For instance, the United States government and their agencies, such as the Internal Revenue Service and Social Security Administration, these are agencies I met with FBI today on this. These are agencies very serious about making sure that every application is accessible to every United States citizen. An accessibility is not, as Sam noted, something that can be done in an ad hoc manner without a structure. It must be systematized. And our efforts have been noted by third party accessibility auditors such as Level Access. You can read a quote here. Customization of UI can hurt accessibility and also potentially open you up to security threats as well.

So at the core of this complete Constellation UX system is best a best front end practices for accessibility and security. And then there's also nuts and bolts usability right out of the box. Crisp interfaces, perfect alignment spacing quick and responsive. The system also provides leaps in core end user productivity, adding essential value to your Pega applications. People using Constellation will get more work done faster. I've highlighted a lot of these core usability features at PegaWorld. Compact spacing. Use of panels. Tabs.

Preview panel. Today I'm going to highlight just a few examples of some newer features that we're adding in upcoming releases or in the release that's about to come out and talk about how they deliver great experiences while radically shortening development time. So one such example is the out of the box Constellation search and select pattern, which is which is critical to the new Constellation version of Pega Customer Service. So typically in business apps, agents or caseworkers need to quickly find a single customer out of possibly millions. The Constellation search and select template helps an agent do just that very efficiently. And equally important, can be delivered in minutes. So let's pretend that as an agent, we're on the phone with a customer. We choose a single. We choose whether or not it's a consumer or a business.

This is what we call the search for category. We then search by particular fields name, maybe Social security number if we have it. Then we sort of filter through those all maybe multiple of the same name in our system, and we select the specific customer. The selection columns in this can actually be different from the search fields because as we might want a field to input a Social security number, we don't want probably a list of Social Security numbers on display. Submitting the form submits a single value that then advances the workflow. All of this experience is really a giant single control set on a single field. The search and select pattern is a business app necessity. The end user experience here seems simple enough, which is good. I actually believe that any UI that looks like it was easy to design is a great design.

Um, and each end user feature we design and develop needs to come up with an authoring experience and the model driven authoring of a complex control like this in traditional UI. This pattern was constructed across many, many different applications in many, many ways, myriad ways. There's now a search and select template and it's extremely easy to use. Developers select data pages representing the search for categories, and then create discrete search by criteria as field groups, and then finally selection criteria as columns in a table. It's as simple as that. Another typical example of how we think about a complete UX system for enterprise applications is the use of what we call promoted filters and promoted actions. Now these are promoted. Filters and actions help users and users take quick use of quick filtering of a list, maybe of a data visualization, or take quick action on a business object such as a Pega case. Promoted filters are presented just above the list or the visualization and promoted actions present in the Constellation summary panel just below the case header.

Similarly to Search and select, these are common patterns in business apps, but previously each implementation was completely custom, bespoke, not consistent, and sometimes took weeks to build with a clear and organized approach to development. Now adding promoted filters and promoted actions to your apps is as trivial trivial as clicking a few checkboxes and determining what data or which actions should be promoted. My last example of a complete UX system is forms, which are at the core of of a caseworker's experience with a Pega workflow. Forms in Pega are different from other platforms, though. I mean not really the forms themselves per se, but how they're delivered to end users. Pega is distinct in how forms are delivered by being just in time. They're rendered dynamically for specific users at the correct time in a workflow. Anyone who's ever observed the receptionist at a dental office, say, understands what happens without this guided workflow. The poor receptionist has this enormous form with dozens of tabs, and he or she is trying to navigate through all of that to input the right data for the current situation.

For instance, when to schedule your next visit. We've all seen this. If the office visit workflow had been orchestrated by Pega the moment you finished your time in the dentist's chair, the correct form for scheduling your next visit would already be in front of the receptionist. That's what we call Pega guided workflow. Sometimes teams UX teams not familiar with Pega's guided workflow principles have ended up creating nonproductive Experiences, so Constellation is designed around guided workflow and allows at least three distinctive modes of forms within this Pega guided workflow construct. The first is our default, which is what I would call one and done. In other words, an individual is given a simple form of fields to fill. He or she presses submit and the form is gone and the assignment completed. Then there's conditional screen to screen.

Here a form behaves like a wizard. Multiple sequential screens are presented to the user. Subsequent screens may be conditional ized by earlier inputs. And then there's a new hierarchical long form meant for an individual or a team who may need to enter a lot of data non-sequentially over time, for instance, over weeks instead of minutes. For example, in due diligence processes and banks. This is this is common information needed for a particular step in the workflow is entered non-sequentially, and what's needed is form fields that can be organized in a logical, hierarchical manner. The structure of these form groups can be set up hierarchical for really easy navigation. And the authoring experience for these hierarchical long form, which is to the right here is Center-out. It's agnostic of the presentation.

Here we change a standard form to hierarchical long form. Right. We add some form groups which present as tabs. We believe that providing these templated experiences that cover critical business application use cases, and which can be configured at a 10th of the time it takes to build custom and which deliver crisp and consistent secure interfaces with proper accessibility and most of all, honor the semantic structure of Pega that we provide maximum value to you. Thus, if you're building in Constellation, you should build as much as you can using the out-of-the-box options. Build the app out first. Just out of the box, and then get feedback before assuming you need anything custom. Yes, sophisticated apps may need extension points, and when used appropriately, extensibility is there for you with Constellation. If you need a fingerprint reader in your UI, for instance, and we don't have one.

You could assemble constellations, presentational components of which there are many. Put them together with third party tech or your own tech for net new componentry, which can be used and reused by app developers. As Caroline will outline shortly, you should make careful business decisions on investing in custom components for employee portals, simply because someone in the business wants buttons to the left versus the right does not mean that as builders, you want to be on the hook for endangering the considerable value you get from front end. Best practice. Crisp and consistent, secure interfaces with proper accessibility and most of all, the semantic structure of Pega, especially if solutions. And we've seen some are not taking into account core design principles of the Constellation UX system. Remember, Pega serves workflow to users differently from most platforms, and that needs to be appreciated and respected. On the other hand, for self-service use cases directly connecting to your customers, we recommend taking advantage of the Constellation open architecture and extending your Pega solution into your enterprise's existing digital assets. This is enormously valuable.

For instance, your website self-service should be consistent with other experiences your company provides for customers. That's important. A mapping layer provided by the Constellation SDKs allows you to bring your own UX system. And there's a booth this year specifically on self-service, which we recommend. I think you're on it. Right. There you go. Excellent. So these are some highlights of Constellation as a complete UX system.

The what that we delivered after, um, 20 years of traditional UI. So this is a system that accelerates end user productivity, designed around how Pega uniquely delivers workflow. It puts accessibility first. It radically minimizes build time. It adds a semantic structure and a clear organization to this critical aspect to to UX. Critical aspect of enterprise application building and an architecture which allows you to bring your own UI. Make no mistake, Constellation is a critical strategic direction for Pega. This is where our investment in UI is and will be, and it is our expectation. Expectation that you are at least experimenting with Constellation now.

And Caroline is going to discuss how you should take advantage of all this. Thank you John. All right. So let's we talked a lot about the past 20 years and all of the changes that happened. Let's talk about adopting for change. So to recap what John and Sam shared, your shortest time to value is using Pega's out of the box UI. We believe that great UX is all of those things you see on the left from accessibility through trainability consistency is your best friend in your back office. Consistency is what lets you train less and deliver more. Everything in between.

Between extensibility, maintainability and as Sean and Sam shared with you, accessibility from the bottom up. But we know that sometimes you need your own custom UI. Sometimes your design system, your customer portal, and your differentiators are what your business demands. And for that, extension points are going to be your friend. And Constellation has more than ever before. So when you're choosing Constellation, you want to be choosing it for the right things. You want to be choosing it for new workflows. If you have a new case type. Deliver it with Constellation.

When you have a multi-channel back to front office or self-service workflow is another great opportunity where you can have the different UIs where they make sense. You can save that money on the back office, and you can spend it a little bit more by creating custom UI for your customers. and the last one is hidden value drivers. These are the things that feel invisible to people. These are the regulatory things that come at you faster than you can respond. These are security requirements that, again, are mounting all around us that we need to respond to with a modern architecture. This is the metaphor I like to use for this change. And it's changing highways. We're all driving down the traditional UI highway and we need to make a shift.

We're not stopping. We're just going to make a turn. The most important thing we got to know is when to do it. We got to know where we're going. We have to have leadership that understands that we're taking a lot and balancing it as engineers. We can't just deliver everything perfectly the way that engineers would love to. So knowing where you're going is really important. The next one is preparation and we recommend not skipping it. We have some new courseware out.

We recommend everybody take those before trying to size, scope and deliver new projects. What I always tell people is for your teams reserve points for training, whether it's Constellation or a different change in technology, you're going to want to give your people time to adopt those things incrementally. I also recommend pairing people in your retrospectives. Ask them to come back. What did you learn in your training? How was it? What did you understand versus what did you understand and have them collaborate? Always be watching for potholes when you're changing. This is just standard risk mitigation I'm sure you're all familiar with.

And the last one is probably the most important one. The first and the last is like running a 4x4 in track. They're the the anchor in the bring it home. The last one is accelerate. Once you have Constellation in your toolbox, you can build workflows at like size and scale that you've never seen before. And you want to get that time that you put into all of that training, all of that leadership back. And we believe that you can get that back through rapid, rapid delivery and release cycles. These are just some more specifics through adoption that we've seen work better keeping us so that mindset. How many of you use an agile practice in your development cycles?

Awesome. All right. We'd love to be agile. All right. So in the user story, you're all very familiar with the format that says as a user I want some capability so that it's the so that that lets your engineering teams come back to the business and say, here's all your options. We can do it this way, we can do it that way. Here are all the ways that we can deliver this change to you, because there's usually not one. There's usually a number of ways. And what I put over to the right are a series of images.

This is a GenAI friendly conference. I generated those with Jen AI and I put the same prompt in different, and I said, give me a swing that two people can fit on that will swing, and I got all different swings. You guys might remember that a long time ago there was a cartoon and they had all different swings, and that was the first cartoon I saw when I became an engineer, and it always stayed with me. There's lots of great ways to engineer things. You've got to find the one that hits the right timeline with the right budget and makes everybody happy. You're like, no big deal, right? No big deal. We all do that. Like I said, restore, reserve those story points for training.

Um, have open discussions. One of the best parts about the new architecture is it draws a clean line between what you get out of the box and what you customize, and that lets you have the best conversations you can imagine. It lets you say no to things. You can have that, but it's going to cost you a little bit more. Do you want the working software instead that we have? Those are great conversations to be able to have this next one. Using a decision matrix when you're customizing, if it's going to improve your NPS score, spend some money on it. If it's going to get you data more timely, if it's going to get you better quality data, spend some money on that UI. The last two are just potholes that we recommend avoiding.

Some teams say, should we stop everything? Time out. Go learn how to do Constellation and then come back and I say no. You always have to be delivering for your business. I was in it for ten years. If I ever said, hey, I just want to take a pause. I want to take a step back. Six months later, I'll come back and I'll deliver great stuff for you. They would have kicked me out of the room.

They would have said, no thanks. We're not interested in that. We need you always delivering. The last one is to start out with hello, world. When you're starting to learn something new, no matter how advanced an engineer you are, start with something small and bring your skill levels up incrementally. Double clicking into skills. The skills for building might feel like they've changed very drastically. They haven't. The same Pega that you know and love.

Data transforms all of those cool things that you're familiar with are still there, and they're still the foundation of building with Pega. Nothing in that arena has changed. Familiarity with the API is always important. You may not be integrating, but that's how all front ends connect to the Pega engine, so you're going to want to be familiar with it. Extending Constellation that other side, that clean line that we talked about, that's when you're going to want some new skills. We noticed that a lot of lsas, a lot of SSAs do have JavaScript skills. They have an easy time upskilling. Some don't. And that's okay.

When you need to extend using what Shawn referred to those components, you're going to need react skills. That's to build maintainable, accessible, secure UI that's just appropriate when you're building your custom UI. You can do that with react, angular and Web Components. So Pega provides three SDKs that will make it easier for you to connect to your customer portals, your websites, or to build something net new. Where do we see the community today? Well, we're working on awareness for DX componentry, and the reason why is we know that you need to extend. We want everyone to be aware so that they can have those cost trade off conversations. In terms of architects, we see most people falling into the functional and advanced user areas, and I'll define those real quick. So a functional user is one that they can take a DX component from Pega's open source library, which we have on the web or designed at Pega.com, where you'll see the complete design system.

And you can take a component that maybe isn't available in App Studio yet. Guys, make them available in App Studio and then download it, put it into your application and deploy it for use in advanced user is somebody who can do all of those activities but augment the component, change it, add a little bit of an enhancement to it, and then expert usage of the platform extending in any way. Building your own custom front ends. Bringing your own websites. That's going to be best done through a Pega architect that has those react skills, or if it's web components or angular, those skills, or a Pega architect. We see very well work paired with a front end engineer. When you put those two skill sets together, you can accomplish really anything you need to. And it doesn't mean that you have to have that react person on staff all the time. It may be somebody that supports multiple teams, multiple projects, and you bring them in when you need that fingerprint reader.

You may not have to have that person or their skills available to you 100% of the time. Adoption strategies from an application perspective, like we talked about new stuff, new workflows, a singular case type. Absolutely. It's appropriate for Constellation. Modifying select functionality. This is maybe that time to expose your back office workflow. Connecting it to your customer portal might be a great opportunity for that. The last one we call it the Infinity factor. How many of you have somewhat complicated stacks with lots of different layers in them?

That wonderful layer cake? Do we have any layer cakes? A few hands, thank you. If you have what I call the Infinity factor, you may have certain constraints that make it more difficult to choose how to adopt. And for those we want you to come talk to us, let us know how it's going. Let us know what those constraints are and how you're thinking about them, and we'll help you to create a strategy that's custom to your situation. I think we lost a slide there. All right. Oh.

It's back. All right. So we recommend beginning your journey like you heard Alan talk about. Tech is never over. You're never there. Begin your journey today. We talked a lot about how things have changed over the 20 years. Right? We heard about how you had trouble upgrading all of the challenges that traditional UI posed to you.

We heard about accessibility and security. We heard about how you were forced to build the same thing over and over again. So we want to get those things out of your way. The last two decades have meant that we need to balance delivery alongside maintenance in a different way. We need to have a different and more flexible strategy. And that's what the new UX complete system is all about. With Pega Infinity Constellation architecture, your teams are empowered with the complete toolset to automate at that speed and scale that you need. You're armed with the power of Pega that Center-out business architecture and you are limited with Constellation only by your imaginations of what screens you'd like to build. Sam, Sean and I want to thank you so much for being here today.

We sincerely believe in all of the work that you do with the platform, and we want to thank you for helping us make it better every day. We hope that you'll come find us in the Innovation Hub and ask all your technical questions. Um, and if anybody has any questions, we have a whole minute and 25 to answer them. Does anybody have anything they'd like to ask? A good question. So the example about the flows. Complex flows. Right. And the steps and stages for conversion.

Right. So if you take steps conversion of the example I think happy 2014. Time frame number of 24. In 2014 when that happened, I don't think there was any tool that actually. Write. Those topics flows directly to stages. But now Two that will come up. So that. Was.

Yeah. So the question is for stages or for non stages and steps workflow. Is there some sort of tool. Um this is an experiment we could try which would be to export the flow in a um like a BPMN format or BPL format and then import it into Blueprint. I've never tried it, but we could try it, I don't know. Um, but that's sort of how we're going to end up moving, not just, um, workflow, old workflow, but into Constellation is increasing our ability to do this with automated tooling. So that's all coming. But I think the Carolyn's point is really critical that you should know and understand what Constellation is, how it works, how easy it is to deliver, and then figure out what makes sense for your apps. Awesome.

Oh, yeah. Go ahead. And there's another over here, too. Okay, so. Um. So Pega ships a repo, doesn't ship it, but has a GitHub repo of DH components. What's the story of why those components aren't part of the product and fully supported? These are you're talking about components that are part of the system but are not operable in App Studio I presume. He's talking about is.

Your question. Oh, the GitHub, the custom DH components. Yeah. So those are those are just those are things essentially that we will productize probably at some point. But we it was easy enough for us to create them without doing the full product lifecycle on them. So it's not a great answer to be completely honest. It's just it's just a matter of, you know, someone could come up with like a Kanban, um, you know, react component. So we did. But to actually really productize it is a little bit more involved for us.

It means we have to basically support it, you know, forever. So we, we just we take that when we can with our resources. But that's a good question. But I think meanwhile we will have that, that GitHub repo there and add to it. And I could see us kind of opening it up to kind of a marketplace of react developers that want to contribute to that could be kind of cool. My question actually, my question is kind of extension to that one. Yeah. So you were saying that your the JavaScript API, right. Is it that traditional like sections of branches.

Yes, yes we have you're talking about action sets and the kind of procedural logic that we had in that UI first model, which was we dragged. We had a blank canvas. You would drag a button on it, and then you would apply the the action that the button is supposed to do. Yes, we're moving away for that because it caused all of the problems. Not I shouldn't say it caused the problem. It it contributed to concerns about maintainability upgrades. Um, and it also is against the core principle of this single app, single page application technology that for us is critical to delivering great UX. So again, single page application tech demands the way we see it demands that an entire UI exists on the client before anything else happens. So that means we have to provide that, you know, or you have to provide your own.

But um, that's that's our take on it. So therefore the notion of, um, traditional UI meant that you were the server was delivering UI on call. We don't want to do that anymore. Uh. Well, again, you don't need to. You don't. I mean, you don't. It's what I say is a lot of people in the Pega ecosystem want to just start customizing immediately. So it's to me, it's like buying a brand new car.

And the first thing you do, you drive it off the lot and you take off the steering wheel and you put it on the roof. Well, you could, but is that the best decision? I don't think so. I think the best decision is to drive it around for a while before you determine that you really want to be sitting on top of the roof, you know, steering or something like that. So, um, we recommend again that you build out of the box using everything that we have and then get feedback. Don't try to customize it until until you there's a good business reason to. If there's a good business reason to, then yes, you should, because it's a good business. But as you mentioned, it's a separate us. Completely different.

Yeah. It's. Yeah, the the UI should be, um, should be dumb. It should have no business logic in it. Yeah. So that's a, that's a big. Yeah. I mean I'm a UI guy and I say UI should be dumb. I try to be as dumb as I can possibly be every day.

One beer at a time, anyway. All right. Any other questions? I think we're over time. Yeah. We're over. But, um, if there are questions on this, we can. We can meet in the hallway. We can also meet at the, uh, whatever they call it.

The Innovation. Hub. Innovation Hub. Yeah. Thank you all. Thanks, everybody.