Pega BPM Course in Pune
Pega PRPC, Case Management & PCSA Certification Training

Pega's architecture is fundamentally different from traditional application platforms — understanding the rule-based object model before building anything is what separates developers who understand Pega from those who just know how to click through it.

What BPM means in a Pega context: modelling business processes as configurable rules rather than hard-coded software. Pega's rule-based architecture: everything in Pega is a rule — a UI form, a decision table, a data transformation, a service connection, a report. Rules are versioned instances stored in a Pega database and can be changed and redeployed without application downtime. The Pega class structure: Pega uses object-oriented inheritance for rules. Every application has a class hierarchy — the base @baseclass provides inherited rules for all Pega applications, the Code-Pega-Work class provides case management rules, and your application's custom classes inherit from these. Rule resolution — how Pega finds the correct rule to use when there are multiple versions or class-level overrides — is one of the most important concepts in Pega and a frequent exam topic. Application layers: the three-layer cake (Pega framework layer at the bottom, product/reuse layer in the middle, implementation/organisation layer at the top) — why this separation enables multiple clients to share the same base application while having different configurations. Rulesets and ruleset versions: organising rules into rulesets, the ruleset stack that controls which rules are available in a context, ruleset locking for production stability. Application Studio vs Dev Studio: when to use each, the types of rules available in each, and the relationship between them. Pega Personal Edition installation: system requirements, installation steps, launching the Pega server, and logging into the default application.

Case management is the most important concept in Pega application development. Getting the case design right — identifying the right case types, modelling the stages and steps accurately, and setting up the lifecycle correctly — determines whether the application will work for the business or become a maintenance burden. This module covers case design with the depth it deserves.

What a case is: a case represents a unit of work that travels through an organisation — a mortgage application, an insurance claim, a patient referral, a vendor approval. Cases have a start (the initiating event), a lifecycle (the stages and steps that must be completed), and an end (resolution, approval, rejection, or withdrawal). Case types: top-level cases (the primary business entity) and child cases (sub-processes spawned from a parent case — a mortgage application spawning a property valuation case and a credit check case simultaneously). Case lifecycle design in App Studio: creating a case type, adding stages (major milestones — Intake, Review, Decision, Fulfilment), adding steps within stages (tasks, processes, and approvals), and configuring the stage transitions (automatic when all steps complete, or manual by operator). Primary pages and case data: the primary page is the working memory of the running case — all case data lives here during execution. Work status: the case status values (Open-New, Open-InProgress, Pending-Approval, Resolved-Completed, Resolved-Rejected) and how they affect operator workbaskets. Assignments and work queues: routing case work to specific operators, work queues (pools of work items assigned to a group), and workbaskets (individual operator inboxes). Creating and testing cases: submitting a case from App Studio, progressing through stages, completing assignments, and reviewing the case audit trail.

The data model determines how information is structured, stored, and accessed throughout the Pega application. A well-designed data model makes the application efficient and maintainable. A poorly designed one — where developers dump all data onto the case's primary page without structure — creates performance problems and makes the application hard to extend.

Properties in Pega: the equivalent of fields or variables — the atomic units of data in Pega. Property types: Single Value (Text, Integer, Decimal, Date, Date-Time, TrueOrFalse, URL, Email), Page (a single embedded object — like an Address with street, city, pincode), Page List (a list of embedded objects — like an array of line items in an order), Page Group (a keyed collection of embedded objects), and Value List/Group (simple lists). Defining properties on classes: creating properties in Dev Studio, setting field type, format constraints, and default values. The primary page and its embedded pages: how the case's data is organised as a hierarchy of pages (the primary page contains an applicant page which contains an address page). Data classes vs work classes: work classes hold case instance data (a specific loan application), data classes hold reference data (the list of country codes, the product catalogue) that is shared across multiple cases. Data pages: Pega's caching mechanism for retrieving external data (from a database, an API, or a Pega data class) and making it available to UI forms and decision rules without repeated API calls. Data page scope: requestor scope (available to the user session), thread scope (available to the current case), and node scope (available server-wide). Declare expressions: computed properties that automatically recalculate when their dependencies change — Pega's equivalent of Excel formula cells.

One of Pega's most powerful capabilities is its rules engine — the ability to encode complex business decisions as configurable, auditable rule instances that business analysts can understand and change without developer involvement. This is what allows a bank to change a loan eligibility criterion without raising a software change request and waiting for a developer release.

Decision rules in Pega: the rules that evaluate conditions and return results — used for routing cases, determining eligibility, calculating amounts, setting field values, and controlling SLA timers. Decision Tables: a spreadsheet-like rule with rows of conditions and a result column — ideal for decisions with multiple conditions evaluated together. Creating a decision table: defining input conditions (property comparisons), condition operators (equals, less than, greater than, contains, starts with), and the Otherwise row for the default result. Decision Trees: a sequential evaluation rule that tests one condition at a time, branching based on yes/no outcomes — better than decision tables for hierarchical logic. When Peg conditions: inline conditions on properties, assignments, and router rules — equivalent to if/else statements in code. Map Value rules: simple lookup tables mapping a single input to a single output — useful for currency conversion rates, tax codes, and category mappings. When rules: boolean-returning rules that evaluate a condition — used in flow decisions, UI visibility conditions, and validation rules. Validate rules: rules that enforce data quality on case properties — checking that required fields are present, that numeric values are within range, that dates are in the future. Pre-activity processing: calling validate rules automatically before a case step completes to prevent invalid data from advancing. Using decision rules in flows: routing assignments to different queues based on case value, skipping steps based on application type, and calculating approval thresholds.

Pega's user interface is how operators interact with cases — filling in application forms, reviewing submitted information, making approval decisions, and tracking case progress. The quality of the Pega UI directly affects user adoption and process efficiency. Pega's modern Constellation DX framework provides component-based, responsive UI that works across desktop and mobile without separate development.

Pega UI frameworks: Constellation DX (the modern framework introduced in Pega 8.5 — component-based, built on React, responsive by default), the older Full DX framework (still in use in many legacy implementations), and when each is appropriate. Constellation DX architecture: Views (the primary UI building block — a view is a reusable, configurable display of case data), Templates (pre-built view layouts — Wide Narrow, Narrow Wide, Narrow Narrow, Four Column), and Components (the individual UI elements — Text Input, Dropdown, Date Picker, Table, Rich Text Display). Building case forms: creating input views for data capture, display views for read-only information presentation, and summary views for case overview. Configuring UI fields: adding properties to views, setting labels and help text, configuring field visibility conditions (showing a field only when another field has a specific value), marking fields required, setting default values. Tables in Pega UI: displaying Page List properties as editable tables (inline editing for adding and removing list items), display tables for showing related cases or search results. Case explorer: the side panel showing case stages, related cases, and case history. Constellation design system: using Pega's built-in component library to maintain visual consistency. Localisation: configuring field labels and messages for multiple languages. Accessibility: Pega's built-in WCAG 2.1 compliance features and accessibility testing. App Studio UI builder vs Dev Studio view rules: building views in App Studio's visual editor and accessing the underlying view rule in Dev Studio for advanced configuration.

The flow rules that define the process logic within each stage — how assignments route between operators, how approvals work, how automated steps execute — are where the business process modelling expertise of a Pega developer is most visible. Well-designed flows handle all the exceptions and edge cases that real business processes produce. Poorly designed flows create bottlenecks and routing errors.

Flow rules in Pega: the visual process diagrams that control what happens within a case stage. Flow shapes: Assignments (work items given to an operator), Subprocesses (calling another flow), Spinoffs (creating a child case), Decisions (conditional branching using When rules or Decision Tables), and Utilities (automated steps executing activities). Assignment routing: Route to Operator (directly to a named user), Route to Work Queue (to a shared queue for a group), Route to Work List (to the current user), and routing based on a property value computed by a decision rule. Approval processes: human approval steps where a manager or committee must review and approve/reject a case. Single approval, concurrent approvals (all approvers must respond), sequential approvals (chain of approvers), and consensus approvals (majority must approve). Escalation paths for approvals that time out without a response. SLA rules (Service Level Agreements): configuring response and resolve goals for assignments — the yellow urgency threshold (approaching deadline) and the red overdue threshold. Notification actions triggered by SLA escalation — email notifications to operators, managers, and applicants. Automated activities: Pega activities are Java-based procedural code units — using standard activity steps (Obj-Save for saving case data, Call for calling another activity, Property-Set for setting property values, Decision for branching, Service for calling external systems). When to use activities vs flows. Case locking: understanding pessimistic and optimistic locking in Pega and how conflicts are handled when multiple operators work on the same case simultaneously.

No enterprise Pega application operates in isolation. Loan origination applications need to call credit bureau APIs. Insurance claims need to pull policy data from a core insurance system. Customer service cases need to query the CRM for account history. Integration is a core part of almost every Pega project, and understanding how Pega connects to external systems is essential for any Pega developer.

Pega integration architecture: Connect rules (the outbound connection definitions), Integration Designer in App Studio (the simplified integration setup tool), and the Service rules for exposing Pega functionality as external APIs. Connect REST rules: configuring a REST connector in Pega — endpoint URL, HTTP method, authentication (no auth, basic auth, OAuth 2.0, certificate), request body mapping, and response mapping. Testing REST connectors in Dev Studio. Connect SOAP rules: connecting to SOAP/WSDL-based web services — importing the WSDL, configuring the endpoint, and mapping request/response elements. Authentication profiles: storing credentials securely using Pega's authentication profile rules — avoiding hardcoded credentials in connector rules. Data transforms: the Pega rule for mapping data between structures — mapping a REST API response (with its structure) to the Pega case properties (with a different structure). Data transform operators: set (assigning a value), append to (adding to a Page List), copy properties (copying an entire page structure), and conditional transforms. Error handling for integration: catching connector errors using a Try/Catch pattern, logging errors, creating error messages for operators, and retry logic for transient failures. Exposing Pega as a service: creating Service REST or Service SOAP rules to allow external systems to initiate Pega cases, query case data, or trigger case actions — making Pega accessible to mobile apps, portals, and other enterprise systems.

Complete Pega development competency requires understanding how to secure applications, build meaningful reports for business stakeholders, and work with Pega's automation capabilities. This module covers all three areas that appear consistently in Pega project work and in the PCSA exam.

Pega security model: Access Groups (collections of access roles assigned to user accounts — the entry point to Pega security configuration), Access Roles (collections of privileges that define what an operator can do — Admin, User, Manager), Privileges (granular permissions for specific operations — Create, Read, Update, Delete on specific case types, access to specific screens, ability to perform specific actions). Access Manager: the visual security configuration tool in App Studio. Operator roles and personas: matching real job roles to Pega access groups. Record-level security: using access policies to restrict which case records an operator can see based on the case's data values (e.g., a regional manager can only see cases from their region). Reporting in Pega: List reports (tabular display of case data), Summary reports (aggregated data with counts, sums, and averages grouped by dimension), and Cross-tab reports (two-dimensional matrix reports). Report browser and Report Definition rules. Configuring report columns, filters (user-specified at runtime, hardcoded in the report definition), and sorting. Scheduling reports for email distribution. Pega Insights: the modern analytics layer in Pega Infinity — interactive dashboards with drill-down capability, trend charts, and KPI monitoring for business stakeholders. Creating Insight panels and embedding them in case manager portals. Pega Robot Manager: Pega's robotic process automation (RPA) orchestration tool. Understanding the difference between attended bots (running on an operator's desktop, triggered manually) and unattended bots (running on server infrastructure, triggered by Pega cases automatically). Configuring robot queues in Robot Manager, creating robot run requests from case flows, monitoring robot execution, and handling robot errors. The Pega + RPA combined approach: using Pega cases to orchestrate robot tasks as part of a larger business process — the combination that makes complex process automation genuinely effective.

The final module brings everything together through a complete Pega application project and prepares students for the Pega Certified System Architect certification exam and job interviews at Pega implementation partners.

Capstone project — Loan Origination Application: students build a complete end-to-end loan origination case management application. The project includes: application design in App Studio (case type definition, stages, steps, data model), decision rules for loan eligibility and interest rate calculation, Constellation UI forms for applicant data capture and officer review, approval workflow for credit manager and branch manager, SLA rules for regulatory response deadlines, integration with a mock credit bureau REST API, data transforms mapping the API response to the Pega case, reporting dashboard showing pipeline KPIs, access security with separate roles for applicants, loan officers, and managers, and full end-to-end testing. Best practices discussion: the Pega Guardrails — Pega's quality standards for application development covering naming conventions, rule organisation, data model structure, UI patterns, and code-free development. Understanding Guardrail scores and how they affect application quality. Pega Certified System Architect (PCSA) exam preparation: exam format (60 questions, 75 minutes, 66% passing score, online proctored), topic weighting (case design 25%, data model 20%, decision rules 20%, UI 15%, integration 10%, security 10%), study resources (Pega Academy missions, practice exams), exam strategy and time management, common question patterns and tricky areas. Pega developer interview preparation: the most common Pega interview questions (explain rule resolution, what is the three-layer cake, how does a data page work, difference between flow and activity, how do you implement security in Pega), scenario-based architecture questions, and resume building for Pega PCSA roles.