Business rules and decision logic

The Compliance Director shows the team a complex spreadsheet that has become legendary at U+ Bank. It contains rows of “if this, then that” logic that determines which customers qualify for specific account types and features. The challenge is not only the complexity. This business logic is locked in spreadsheets, interpreted manually for each application, and often outdated when regulations change.

The Branch Manager adds the operational reality: “When Compliance updates these rules, we receive an email with a new spreadsheet. Staff continue using old versions because no one knows which one is current.”

This situation represents a fundamental challenge that most organizations face: business logic is disconnected from the systems that need to enforce it, and it cannot be maintained by the business experts who understand it best.

Before addressing U+ Bank's challenge, the Solution Designer explains a key design principle: business rules and workflow serve different purposes and change at different rates.

Cases and workflows define what happens and when—the sequence of Stages and activities in the customer journey. Business rules define how decisions are made by determining eligibility, pricing, routing, approval authority, and risk classification based on specific conditions.

By separating these concerns, Pega solutions enable business owners to maintain decision logic independently from the workflow structure. Intake workflow stages (Intake, Identity Verification, Credit Check, Account Approval) remain stable; however, the rules determining account eligibility based on credit score, income, and customer status change frequently. Business rules must be maintainable by compliance without modifying the workflow or waiting for IT.

In the following image, click the + icons to explore the key steps in the account intake process:

The Solution Designer can configure some Decision Rules in Blueprint today. Advanced Decision Rules are implemented later by Solution Builders in App Studio or Dev Studio. Blueprint also captures business rule requirements and documents the decision logic required.

Using the Compliance Director’s spreadsheet, the Solution Designer adds annotations to the Assess Eligibility workflow shape in Blueprint to document the following requirements for eligibility logic:

• Basic account tier: Age 18-24, credit score under 650, income under $30K → limited features, no overdraft protection
• Standard account tier: Age 18-24, credit score 650-699, income $30K-50K → moderate features, limited overdraft
• Premium account tier: Age 25+, credit score 700+, income $50K+, existing customer → preferred rates, enhanced features
• Senior advantage tier: Age 65+, existing customer 2+ years → special rates, enhanced protection

These annotations tell the Solution Builder exactly which decision logic to implement, without requiring the Solution Designer to configure the technical Decision Rules.

In the center of the following image, drag the vertical line to see how the Solution Builder defines the Decision Table in Blueprint by editing columns and clicking the Add icon to implement the requirements the Solution Builder received from the stakeholders:

To help stakeholders understand what is possible, the Solution Designer explains that Pega solutions support different types of business rules for different decision patterns:

Decision tables evaluate multiple conditions simultaneously to reach an outcome. They are ideal for eligibility matrices, such as the Compliance Director's eligibility spreadsheet. For example, when you need to consider age AND credit score AND income together to determine account type and features, create a decision table that the Pega application processes automatically.

Decision trees evaluate conditions sequentially, where each answer determines the next question that follows. The Fraud Detection Manager describes their process: "First, we check if the transaction amount is suspicious, and only when this is true do we check frequency. And only when the transaction amount is also unusual, then we analyze historical patterns." This sequential logic maps perfectly to a decision tree.

When Rules handle simple, single-condition logic that is fast and straightforward. For example: "When credit score is above 750 and customer tenure exceeds five years, route to immediate approval." Use a When Rule instead of a complex table when the logic is simple.

The transformational power of business rules in a Pega application becomes clear when the Compliance Director asks: “After go-live, when regulations change or we launch a new product tier, do I have to wait for IT to update these rules?”

This area is where Rule delegation creates lasting business value. The Solution Designer explains that specific Rules can be configured as "delegated Rules" during implementation. This approach allows business owners to update those rules directly in production through a business-friendly interface without developer access or IT tickets.

After go-live, when the Compliance Director needs to update eligibility criteria, the director logs  in to the Pega  business portal and works in the same business-friendly decision table format—not code, not technical fields, but a clear eligibility matrix. The director can add new account tiers, modify income thresholds, or adjust credit score requirements. Each change follows the appropriate approval workflows and governance controls, but Compliance owns the logic.

The IT Director oversees workflow structure, technical integrations, and system architecture. Business experts own and maintain the logic that defines eligibility because they understand it best.

While Blueprint captures requirements, the Solution Designer demonstrates how these business rules are displayed in production by using tools such as App Studio and Dev Studio. These demonstrations help stakeholders visualize how complex spreadsheets become decision tables, how sequential logic becomes decision trees, and how rules are maintained after go-live.

These demonstrations bridge the gap between Blueprint's design features and stakeholders' need to see the tangible solution, which builds confidence that their business logic will be both automated and maintainable.

Everything designed in Blueprint—including all business rule requirements documented in annotations—flows directly into what the Solution Builder implements in a Pega application. Blueprint annotations specify which decision tables, decision trees, and When Rules to build. Demonstrations show the format and structure to create, and the delegation strategy identifies which rules business users maintain.

This connection ensures that the Solution Designer’s vision for business-owned, automated decision logic becomes reality in the implemented solution.

In the following image, click the + icon to see how to see how Blueprint implements the Assess Eligibility Step:

For U+ Bank, this approach transforms how business logic is managed. The Compliance Director’s spreadsheet becomes a decision table that is enforced automatically, audited with every use, and maintained by Compliance when regulations change. The Branch Manager’s staff no longer performs manual lookups; the Pega application applies Rules consistently and instantly. The IT Director gains a sustainable architecture where changes to business logic do not require workflow modifications or IT involvement.

Most importantly, U+ Bank shifts from "business logic trapped in spreadsheets and emails" to "business logic owned by business experts and enforced by the platform automatically."

The next topic explores how the Solution Designer uses layers and specialization in Pega to support multiple product lines without developing separate applications, where the power of reuse becomes clear.