Samenvatting Low-Code App Builder PDF

1. Low-code defined T1: Low code application development Low-code → visual, declarative techniques instead of programming. Enable faster, more agile collaboration between business stakeholders and developers by using a common visual language, improving productivity and allowing teams to focus on bus...

1. Low-code defined T1: Low code application development Low-code → visual, declarative techniques instead of programming. Enable faster, more agile collaboration between business stakeholders and developers by using a common visual language, improving productivity and allowing teams to focus on business logic rather than code to rapidly deliver value. Pega → create robust, omnichannel applications that integrate data from multiple systems. Enabling seamless business processes across web, mobile, email, and chatbot channels, far beyond the limitations of simple tools like spreadsheets. The platform empowers both citizen and professional developers by enabling rapid, visually driven application development, allowing non-developers to create apps and experienced developers to build and extent robust solutions that can be reused across the organization. T2: Studios 4 rule-based studios: 1. App studio – authoring space for designing cases, managing data, and building user interfaces. 2. Dev studio – advanced features for application development. 3. Prediction studio – features to build machine-learning models for adaptive, predictive, and text analysis. 4. Admin Studio – Runtime information and configuration options for monitoring and debugging system resources. Each studio has a header, a navigation pane, and an authoring space. Navigation pane: Overview – basic info Case Types – visual representation of reusable business processes/work Data – information required to process and resolve business cases Channels – Provides a way for users to interact with the application Library – Visual representation of reusable assets Users – Participants interacting with the application T3: App Studio App studio → core low-code featured for application development. Enables you to visualize and design business processes by connecting stages, personas, communication channels, and required data, helping to manage development workloads. Supports agile development with real-time UI design capabilities. Application profile → captures user stories, bugs, and feedback to facilitate agile development, promoting collaboration between technical and business team members. Apps are designed using a modular approach, where rules governing application behavior are organized into reusable layers, allowing for consistent branding and functionality across multiple applications. Each layer can be maintained independently, with rulesets facilitating the sharing of entire sets of rules, thus reducing development times and enhancing application quality. Pega offers 2 application architectures: 1) Constellation architecture – view based UI (Constellation ruleset) 2) Traditional UI – section-based UI (Theme Cosmos ruleset) T4: Generative AI in Pega Socrates – interactive dialogue-based learning experience tailored to individual learning needs through various modules and challenges. Autopilot – detailed instructions and suggestions for building and editing applications in App studios. Coach – expert advice and feedback for end-user tasks during application runtime, task specific guidance. Knowledge buddy – Assists clients by answering specific questions using Pega GenAI alongside their procedural documents and knowledge bases, delivering contextual information. Search Assistant – Help users find relevant materials across various resources OpenAI search – Asking questions directly in search bar Blueprint → collaborative SaaS tool that enables rapid application design by allowing users to outline their business needs without requiring a Pega instance. Describe the needs in business terms and export generated designs into Pega. GenAI Connect Step → integrates generative AI to enhance application customization, allowing users to configure Pega Connect Rules for specific needs, such as summarizing complex cases or listing required documents for customer service. With Pega infinity ’24 users can create a connect generative AI automation step in app studio by defining a prompt that sends requests to the Pega GenAI engine. The AI can respond in three formats: a structured single response, a structured lists or an unstructured response, which can be mapped to appropriate fields in the Data Model. Additionally, the system allows for the making of sensitive data and supports localization based on user settings. T5: Integrating with external applications Modern enterprise applications often need to connect to multiple systems of record (SOR) to access and update data. Pega simplifies integration with external systems through various protocols and standards, allowing businesses to focus on their needs rather than technical connectivity. When APIs are available, Pega can connect directly using API connectors. However, for legacy systems without API support, Pega Robotic Process Automation (RPA) can be used to automate data entry tasks by interacting with system interfaces. ➔ Allowing businesses to align their integration strategy with their long-term goals. As the bank modernizes its systems, Pega’s design enables easy replacement of RPA with API connectors, minimizing disruption to the application. 2. Pega Constellations design system T1: Pega Constellation design system A design system ensures a consistent user experience by organizing design rules, patterns, and assets into a structured framework. This system includes a shared library of UI elements, styles UX patterns, themes, and guidelines, allowing development teams to build and maintain applications more efficiently. It also incorporates abstract elements like brand values and UX mindsets. The Constellation design system in Pega Platform enables rapid application development with a prescribed presentation layer, supporting information architecture, interactions, accessibility, and data visualizations. Pega offers two design systems: Constellation for modern architecture and Theme Cosmos for traditional UI architecture. T2: Prescribed design in Constellation Prescribed design → set of informed default designs and templates with preset configurations to reduce design time, allowing the designer to create pages and flows that focus on user needs. Prescribed design evolves over time with new use cases and allows customization of patterns and components. By standardizing common design choices, it reduces planning time and resources, helping designers concentrate on key user experience aspects, such as the content and flow of modals in the application. The Pega Constellation design systems uses prescribed design concepts to streamline and unify application design across platforms. Key terms include design tokens, themes, patterns and components: Design tokens: Tools that standardize design and UX principles across different platforms. They unify style elements like colors, spacing, and typography. 4 types: 1) Primitive – Raw design elements (color, spacing) 2) Meaningful – Functional combinations of Primitive tokens (heading styles) 3) Component-shared – Repeated parts shared across components (input-border) 4) Component-specific – Tokens unique to a component’s styling (checkbox-border-radius) Themes: settings that style applications according to brand standards, including elements like text, colors, and buttons. Patterns: scalable combinations of components and user flows that create consistency, such as search results, error messages, and navigation flows. Components: individual UI elements that perform specific functions, like text fields. Complex components with focused business goals, called widgets, can function independently, such as a Home page welcome message. A prescribed experience in a design system is a holistic approach where design patterns, UI components, technical behavior, and visual elements are used together in a specific way to address business problems, improve user efficiency, and meet legal requirements like accessibility and localization. While the system sets guidelines, it still offers flexibility for designers to make decisions on content placement, workflow, and branding. Designers focus on organizing and optimizing flows to help users achieve their goals. Style guides are brand-specific and UI-focused, while pattern libraries are varied and non-prescribed. Design systems combine both, offering auto-upgrades, regulatory compliance, and being technology- agnostic.  3. Defining a customer Microjourney T1: Pega Express delivery approach Pega apps enhance customer interactions, known as customer journeys. Pega Express: uses agile approach to quickly deliver a Minimum Lovable Product (MLP) by breaking down customer journeys into smaller segments called Microjourneys, each aimed at achieving a specific goal. An MLP release provides a valuable solution that addresses a business need or pain point, ensuring it is quickly deliverable and eagerly adopted by end users. The focus is on delivering one goal at a time, guided by three core elements (1) Microjourneys, (2) Personas and channels and (3) data and interfaces. Microjourney: small part of the overall customer journey and focuses on accomplishing a specific goal (e.g. changing an address) Personas and channels: Personas determine who interact with the application. (customer/employee) Channels determine how a Persona interacts with the application. (Web Portal/chatbot) Data and interfaces: Data is the information that the microjourney interacts with to accomplish the customer’s goal Interface defines where the data comes from or where it is persisted T2: Case Life Cycle A Case Type is an abstract model of a business transaction; they model repeatable business transactions. A Case is a specific transaction instance. The Case Life Cycle in Pega defines the workflow for a business transaction, representing the model of a Microjourney. It outlines the path a case takes to resolution and consists of three key elements: 1) Stages: mark significant status changes or transfers between coworkers 2) Processes: are sequences of Tasks or Steps within each Stage 3) Steps: can be user actions or an automated actions performed by the system Naming conventions: Stages → noun, noun phrase, gerund Processes & steps → verb + noun T3: Case Life Cycle design Case Life Cycle design modeling technique → see and interact with a case the same way you think about it. Create Stage (first stage): green bar, case-ID assigned Primary Stage: majority goes through this stage, completion is part of usual case processing, processes in this stage are key component, action in this stage required for positive resolution Resolution Stage: red bar, case finishes life cycle. Multiple resolution stages are possible Alternate Stage: handle deviations from the primary path. Represent a negative resolution stage/handle exception Create Processes: Create stage contains a Create Process, modifiable to meet business needs.  Parallel Process: You can configure two or more processes that users can perform in any order as parallel processes. Collect information step: green icons, Assignments Automation Step: yellow icons, performed by system. Stage transitions: 1) Automatically move to next stage 2) Wait for user action 3) Resolve the case Step transitions: Default: submit to advance to the next step. T4: Multi-step Forms A form is an interface for collecting data from users and processing the work. A Multi-step Form represents a single Assignment completed by a ingle user: guided, linear. Presents information in multiple focused and concise views. Three navigation styles: 1) Horizontal 2) Vertical 3) Standard Users navigate using ‘Next’ and ‘Previous’. Submit option is available on the last View. T5: Draft mode Draft mode (default) allows you to quickly run the Case Type to check the run-time behavior even with incomplete configurations. Guardrails are app design best practices that help reduce the risk of introducing issues 4. The Data Model T1: Data modeling Data model: visual representation of all the data elements and the connections between them. Define the data that is required. There are three variations: 1) The Conceptual Data Model 2) The Logical Data Model 3) The Physical Data Model The Conceptual Data Model: ‘living document’. For visualization of the data entities and attributes (E.g. Address is a data entity and Address type, street and city are attributes). Helps to mitigate the risk of rework due to misunderstandings in the early stages of the project. Solid starting point. Logical Data Model: converts the data entities and attributes of the Conceptual Data model into objects and fields resp. fields → reusable UI components. Consists of name + field type (determines format of the  data) data object → Structure for describing an entity by grouping a set of related fields. The Physical Data Model: reflects data as it is stored a accessed in the application. The Integration Designer → accessing the data objects, data object dependencies, and systems of record in application. Data Pages retrieve data for the data object from a source and caches the information in memory. Integration Map: diagram of the data objects for the application and the system of record from where they are sourced. T2: Data Records Data objects are defined by a collection of fields. The unique collection of fields and values for a single instance of the data object is called a Data Record. Data records define the permissible values for data fields (not all fields have Data Records; they limit input values, reduce errors, allow for automation). Data objects represent key business entities, such as a customer. Data objects contain all the fields that are necessary to describe the object: Customer data object → First name, Last name, Email, Phone. Change to Data Record → no associated change in the business process to support the chance Change in the Data Object → change in the business process. Data Records can be input directly into the data object form the Records tab, but you van also configure a data object to retrieve data form an external data source, such as a database or a website. T3: Data Pages and the Visual Data Model Data Pages show how your application uses data and defines the data associated with a data object; they provide links between Data Records and the application. They are a data sourcing feature – they identify how to obtain data form a system of record. A Data Page for the Customer data object specifies how to connect to the source system and which fields to map. This allows applications to access detailed customer information without developers needing to understand the underlying data storage. The separation of data integration from application logic means developers can change data sources without affecting how the application utilizes that data. For example, if the source for Orders needs to be updated, it can be done in the Data Page without modifying the user interface. Default Data Pages are available for various data objects. Easy explanation of Data Pages: Data Pages are like templates that help applications get data from different sources without needing to know the details of where that data comes from. Imagine you’re ordering food online; the menu shows you the dishes, but you don’t need to know where the restaurant gets its ingredients. When a developer sets up a Data Page, they define how to connect to a data source (like a database) and which pieces of information to pull (like customer names and orders). If the source changes—say the restaurant switches suppliers—the developer can update the Data Page without needing to change how the app displays that information. This keeps things flexible and makes it easier to manage data in applications. T4: Integration Designer Integration Designer provides a single location in App Studio for viewing all the data objects, Data Pages, object dependencies, and external systems in an application and also provides insight into how these entities are connected. Integration Map is a diagram of data objects, Cases, and systems of records in te application and where they are sourced. 5. Capturing and presenting data T1: Fields Fields → collect information/present case information. Each field is a named reusable UI component. Each field stores a unique value that is associated with a Case. Data element: combination of field name and the stored value. E.g. a field named Metro and a value of Boston. When you create a field. You also assign a Field Type → ensure users provide valid info and ensure the system displays data in the correct format. You have: Simple field Types: Text, Boolean, Currency, Date & time, Data, Email, Integer, Percentage, Phone, Picklist, Time Only, URL, Address, User reference, Prediction. Fancy Field Types: Attachment, Location Primary field are the fields that are most relevant to a case Type T2: Calculated values Calculation: expresses a relationship between fields by setting the value of the calculated fields based on one or more input fields. E.g. Total cost calculated by price and quantity. 3 types of calculations: Functions – Iterate over items in a list Supported for Decimal, Currency, and Integer field types. 4 basic functions: 1) Sum of 2) Average of 3) Maximum of 4) Minimum of Expressions – Calculate a field value by referencing any combination of simple fields, fancy fields, and data relationships. When you configure an expression, you reference fields by name using the dot operator (“.”). Expressions support common operations, such as +,-,*,/, grouping, AND, OR. You can define an expression for any Simple field type except Email, Phone and Picklist. For text → concatenation  Decision tables – Use a set of conditions to test property values and return an appropriate response. To identify the relationships between fields, a network of calculations is established. T3 Views A view is a component of the user interface that gathers information from a user of displays information to the user. During View creation, you determine the information that users need to see or collect to perform specific tasks. A field group is a cluster of individuals that, together, present related data inside a View. Difference between Views and Forms: The view is a reusable configuration of UI elements. The form is an interface for collecting data from users and processing the work. A form can have one or more Views. But the view is not always a form. View → UI elements. Forms → submit and cancel buttons 6. Full Case Views T1: UI configuration in Constellation The new Constellation UI model offers greater flexibility for connecting front-end components with back-end APIs. It follows the Principle of Separation of Concerns, promoting modularity by dividing the application into distinct parts. New apps → automatically generated set of views. Full Case view: represents a single Case in Pega Platform: 1) Summary panel 2) Work area 3) Utilities panel Details: read-only case data Pulse: post, view, reply to messages. Edit: renders a form when users click Edit Create: renders a form to capture data necessary to create the case. List: Provides controls to efficiently configure a list of Cases of this Case Type with various behaviors. Default → list that contains all open cases. 7. Creating a data relationship T1: Data objects A data object is a template for describing an entity, such as a person or item, by grouping a set of related fields. E.g. Account data object includes fields that describe an account, such as Account Number, Current Balance and Next Statement Date. The collection of Case Types and data objects in your application holistically defines the Data Model for your application. Structure: The structure of data objects in Pega Platform consists of data types that define the technical implementation of the data, including field names and types. Each data object encompasses a collection of fields that represent a specific type of entity. When a data object is created, its corresponding data type is automatically generated. In development, the terms "data object" and "data type" are often used interchangeably, but developers work directly with data types in Dev Studio. For instance, an HR application might use a Candidate data object to gather information like First name, Last name, Email, and Phone for job applicants. Data objects can also encompass Views and related Rules. For example, a Candidate data object can include a calculation to create a full name from first and last names. Data objects can reference other data objects to extend their structure. This means the fields from the referenced data objects are integrated into the referencing data object's data type. For instance, a Candidate data object might reference Address and Employment history data objects to include additional information, where Address captures a single address and Employment history may include multiple entries for past employers. Overall, this hierarchical structure allows for organized data management within applications. Inheritance: Data objects can be created to leverage existing assets through inheritance, allowing for a parent-child relationship. For example, "Person" serves as a generic parent data object, while "Customer" and "Call Center Representative" (CCR) are specialized child data objects. They share common fields like Name, Telephone, and Email defined in the Person data object, enabling reuse. Specific fields, such as Tax Identification Number and Membership Number, are exclusive to the Customer data object, while Employee ID is unique to the CCR data object. This structure promotes efficient data management by centralizing shared attributes in the parent object while allowing specialized fields in the child objects. Sourcing: Data objects in Pega Platform can be sourced in three ways: 1. Locally from a Pega Platform system of record: This involves using data that is already managed within the Pega system. 2. Externally from a different system of record: Data can be sourced from existing databases, such as HR or inventory systems, that the company uses. 3. Directly from user input during application processing: This includes data entered or modified by users or case participants that aren’t tied to any specific system of record. When deciding how to source a data object, it’s important to consider various factors to ensure proper integration and functionality within your application. T2: Data relationships A data relationship is a framework for associating related fields without actually storing data. It connects elements of an application that hold data (like data objects and Case Types) with those that require that data to effectively resolve a Case. Data relationships can link data between different data objects, between Case Types, and between data objects and Case Types, facilitating data integration and application functionality. There are different relationship Field Types: Embedded Data – when information is collected from user input into a case Data reference – when you need to reuse another data object from outside the case Case reference - when you want to reuse data from another case Query – for read-only access to information that is external to the case.77 Data relationships are configured to reference either a single record or list of records. Single record → only a single set of fields and values from a data object are used to resolve a Case List of records → a list of grouped fields and values from a data object are used for Case resolution Embedded Data Relationship An Embedded Data relationship uses an Embedded Data Field Type to source data directly from user input within a Case instance. This data is stored within the Case, ensuring consistency in format across the application, but it is not accessible outside the Case for sharing between Cases or Case Types. E.g. in an Online Order application, a Credit Card data object captures details like Card type, Card number, and Expiration date. In the Delivery Order Case Type, a field called Payment information is created using the Credit Card data object as an Embedded Data field, allowing the user to enter credit card details directly for each order. Since only one credit card can be used per order, the Single record option is selected. When users enter their credit card information, it is stored in the Pega database alongside the Case instance, which includes a reference to the Credit Card record through a unique Pega ID. This structure provides access to all fields in the Credit Card data object while maintaining data integrity within the specific Case context. Data Reference Data relationship For data sources outside of the case. Data ref is used when the data needed in a case is sourced either form locally stored Data Records or data accessed from an external system of record. For instance, in an Online Order application, a Customer data object contains fields such as First name, Last name, Full name, Email, and Phone, with this information stored in an external system maintained by the supermarket's IT department. Each Delivery Order Case is linked to a single customer, so the Single record option is selected. By establishing the Ordering customer data relationship, the Delivery Order Case Type can access all relevant fields and data associated with the Customer data object, allowing for seamless integration of customer information into the ordering process. Data relationships between data objects Data relationships not only allow fields and values from a data object to be used within a Case Type but also enable referencing one data object within another. For example, in an online delivery order scenario, a Product data object includes fields like Name, Description, Price per unit, and SKU, sourced from an external database. Customers can specify quantities for the products they wish to purchase. To facilitate this, a Product line data object is created, which includes a Quantity field and a Products field that establishes a data relationship with the Product data object. This relationship is defined as a Data reference due to the external sourcing and is set to List of records since it contains multiple items. To integrate the Product line data object into the Delivery Order Case Type, another data relationship is created. This relationship uses an Embedded Data Field Type for the Ordered products, allowing users to enter quantities while presenting a list of available products to order. 8. User guidance T1: Case Status Case Status indicates the progress of a Case towards resolution. The Case Status values of your application should hold meaning. Use prefixes “new”, “open”, “pending”, “resolved”. If you set the Case Status on a Stage, the Case Status is automatically updated. Sometimes, you might want to configure more specific case statuses at the Step level. Also automatically updated. T2: Assignment Instructions Step instructions identify what users must accomplish in that assignment. 9. Routing Assignments to users T1: Routing work Sometimes there is more than one operator to complete work on a case → careful and appropriate routing design increases efficiency. You can route assignments to: Current user – if the user who completed the preceding assignment needs to complete the current task. Specific user – if an individual user must complete the assignment. A worklist is a list of all open assignments, in order of importance for a specific user Work queue – A work group (teams) identifies a cross-functional team that uses a work queue (A work queue is a list of all open assignments, in order of importance for a group of users) to distribute work. Assignments stay in the work queue until a user associated with the work  queue selects an assignment, or a manager sends an assignment in the work queue to a specific user. Use business logic- When you want conditional routing by using business logic 10. Designing an approval Process T1: Work Approval Case approvals are points in the case life cycle at which one or more users decide whether to approve or reject a case. Configured by using the Approve/Reject step. To configure an Approve/Reject step, you define who is assigned to the approval and how the case proceeds if the case is approved or rejected. You can assign approvals to the worklist of a specific user, a work queue or business logic to assign work based on custom conditions. You can configure the consequences (continue, change stage, resolve) of approval and rejection by defining the flow. 11. Completing work on time T1: Service-Level agreements Service level agreements (SLA) establishes a work completion deadline; ensure work is completed within the expected time intervals. They use milestones to indicate the expected turnaround times for the assignment: 1) Goal – How long should the assignment take 2) Deadlines – longest amount of time the assignment may takes before it is ‘Late’ A each milestone, you can adjust the assignment’s urgency (10-100) Milestone missed → send notifications, transferring assignment to other user. You can configure SLAs on case types, stages, processes, and Collect Information and Approval steps Work is prioritized based on urgency. There are two primary types: 1) Case urgency 2) Assignment urgency Get Next Work functionality assigns high-urgency tasks before low-urgency tasks. You can also prioritize by deadline. Escalations actions are actions that your application takes to facilitate faster resolution times based on a specified service-level agreement: Notify, Reassign Resolve T2: Additional tasks for setting goals and deadlines  12. Sending emails during Case processing T1: Email correspondence Pega can send automated email correspondence to all relevant parties. 1) With whom do I need to communicate? You can send to a consistent email address, but user reference makes more sense, in case the email changes. Two user reference fields, Create Operator and Update Operator, are automatically defined in the data model for each data type associated with the case type. Case participants are people, businesses, and organizations that are involved in a case; you can share important updates with them. Default participants: Owner – case creator Customer – the person on whose behalf the case is transacted Interested – tracks progress, but does not process the case 2) How will the communication be composed? There is a rich text editor where you van reuse data from the case. 3) When does the communication need to be send? There is a Send email automation step. But email notifications van also be configured at the case level. At the case level, you can automatically send a notification when an assignment in the case is routed to a worklist.