Connecting Blueprint design to Pega Infinity

The previous topics focused on designing the business solution. You evaluated the business outcome, Case Lifecycle, Workflow behavior, Work Orchestration, and Case relationships needed to support the Tour Booking journey.

Those design decisions are represented in Pega Infinity through Rules, configurations, and application assets. While the implementation details may differ from the Blueprint design surface, the business purpose remains the same. The Case Type still represents the agreed outcome. Workflow Rules still support the intended progression. Routing, timing commitments, Decisions, and Case relationships still need to reflect the design intent established with stakeholders.

The Blueprint design and the Pega Infinity implementation serve different purposes, although they represent the same solution. Understanding how the design is represented in Pega Infinity helps the Solution Designer validate that the agreed business outcome, progression, ownership, and relationships remain clear throughout implementation.

The following groups connect familiar Blueprint designs to the relevant Pega Infinity components. The final column identifies the design intent that should remain clear throughout implementation.

Represent Case structure

The Case structure developed in Blueprint becomes the foundation of the implemented solution. Understanding how that design is represented in Pega Infinity helps ensure that the agreed business outcome, progression, visibility, and organization of work remain clear as implementation progresses. The following table shows how those design elements are represented in Pega Infinity.

Review the implemented Case structure

Tour Booking should remain recognizable as it moves from Blueprint into Pega Infinity. The Tour Booking Case Type still represents the business outcome being managed. Stages such as Booking Requested, Booking Confirmed, Tour Prepared, and Tour Completed should continue to communicate meaningful business progress. Processes, user-driven work, Automation Steps, Notification Steps, Decisions, and Case Status should continue to support progression toward the intended outcome and recognized alternate outcomes.

Viewed as a complete design, the implementation should still tell the same business story that stakeholders validated in Blueprint. A stakeholder reviewing the implemented solution should be able to recognize the business outcome, understand how progress is communicated, and identify the responsibilities, system actions, communications, and work that support that outcome.

The review focus is whether the implemented Case structure continues to preserve the agreed business outcome, progression, visibility, communication, and responsibility established during Case Design.

Represent user-driven work

User-driven work establishes who is responsible for acting, what information they need, and what completion enables. In Pega Infinity, several components work together to present the Assignment, collect or review information, route work to the appropriate participant, and support team-based responsibility.

Review participant responsibility and routing

In Tour Booking, user-driven work remains centered on business responsibility. Collect Booking Details, booking preparation activities, and exception reviews should still reach the participant responsible for completing them. The implementation should continue to support the ownership model established during design, whether responsibility belongs to an individual participant, a business role, or a team sharing work.

Assignments, routing, Work Queues, and approval behavior work together to represent that responsibility in Pega Infinity. A Tour Operator should continue to receive work associated with operational preparation. Shared operational work should remain available to eligible team members. Branch Manager approval should continue to represent authorized judgment rather than routine processing.

Viewed as a complete operating model, the implementation should still reflect the ownership, authorization, participation, and information-collection decisions established during Work Orchestration. The review focus is whether responsibility, authority, team participation, and participant experience remain aligned with the design validated in Blueprint.

Represent Case hierarchy and relationships

Case hierarchy and relationships allow related work to be managed independently while continuing to support the broader Tour Booking outcome. Parent and Child Cases, dependencies, information sharing, references, and duplicate-Case handling help coordinate work that extends beyond a single Case.

Review Case hierarchy and relationships

In Tour Booking, related work contributes to the broader booking outcome in different ways. Guardian Consent may be managed through a Parent-Child relationship, dependencies may determine when the booking can continue, information may be shared between related Cases, and readiness information may be obtained from independently managed work without creating hierarchy.

These relationship decisions should continue to reflect the same business intent in Pega Infinity. Related Cases should still represent independently managed work, Create Case Steps should continue to initiate that work under the correct conditions, and dependencies should continue to reflect the outcomes the Parent Case requires before progression can continue. Information-sharing and reference relationships should remain aligned with the coordination needs established during design.

Viewed as a complete Case architecture, the implementation should continue to reflect the accountability, coordination, visibility, information requirements, and dependency decisions that stakeholders validated in Blueprint. The review focus is whether related work continues to support the intended Tour Booking outcome while preserving clear ownership, relationships, and progression.

Represent AI Agent-enabled work

AI Agent participation should reflect the business purpose being served. Whether an Agent performs a business action, supports information collection, or initiates approved related work, the design establishes the required context, expected result, and governance. Pega Infinity represents these patterns through different Rules and constructs.

Review AI Agent participation

In Tour Booking, AI Agent participation supports specific business responsibilities rather than controlling the overall Case journey. An AI Agent may draft a booking confirmation, summarize information, classify content, extract details, support information collection, or help initiate approved related work. Each use of an AI Agent should remain connected to a clearly defined business purpose and expected result.

The implementation should continue to preserve the boundaries established during design. AI Agent-driven work should operate with the required context, knowledge, permitted actions, and expected outcomes defined in Blueprint. Agentic Assignment Processing should continue to support information collection from an identified Assignment owner while maintaining the completion, validation, and follow-up requirements established for that work.

Viewed as part of the complete Tour Booking solution, AI Agent participation should complement user-driven and system-driven work rather than replace the Workflow decisions that govern progression. The review focus is whether each AI Agent continues to support the intended business purpose, operates within its defined boundaries, and produces results that can be used reliably by the surrounding Workflow.

Represent Decisions and Business Rules

Decisions and Business Rules preserve the business policies that influence progression. Together they determine how the solution responds when circumstances require a different outcome.

Review business logic and Workflow variation

In Tour Booking, Decisions and Business Rules help the Case respond appropriately to changing business circumstances. Determine Tour Viability, for example, applies business policy to decide whether a booking can proceed, wait, be rescheduled, or be canceled. Conditional behavior such as Guardian Consent requirements helps ensure that work occurs only when the relevant business conditions apply.

These decisions should continue to reflect the same business intent in Pega Infinity. Decision Steps should still represent the business questions stakeholders expect the solution to answer. Business Rules should continue to express the policies, conditions, and criteria that support those decisions. Conditional behavior should remain aligned with the circumstances identified during Workflow design. During implementation, Workflow variation may be achieved through Decisions, Business Rules, Workflow conditions, routing behavior, or other supported configuration. The review focus is whether the intended business circumstance and resulting behavior have been preserved.

Viewed as part of the complete Tour Booking journey, Decisions and Business Rules help explain why the Case follows one path rather than another. The review focus is whether the implemented logic, conditions, and resulting outcomes continue to reflect the business policies, Workflow variation, and stakeholder expectations established in Blueprint.

Represent timing commitments

Timing commitments establish the business expectations that protect customer, operational, and compliance outcomes. In implementation, those commitments become measurable and actionable through components that monitor progress, increase visibility, notify participants, and support intervention when deadlines are at risk.

Review operational commitments

In Tour Booking, timing commitments help protect customer expectations, operational readiness, and business outcomes. Equipment preparation may need to complete before a departure cut-off, an exceptional safety review may require timely attention, and unresolved booking issues may need visibility before they affect the customer experience. These commitments were established during Work Orchestration as part of the broader operating model.

The implementation should continue to represent those commitments in a way that supports timely intervention. Service-Level Agreements, notifications, correspondence, urgency adjustments, and escalation behavior should work together to make emerging risks visible and help the business respond appropriately when commitments are threatened.

Viewed across the complete Tour Booking journey, timing commitments are not simply deadlines. They express the business promises, operational expectations, and intervention points that help keep work progressing toward the intended outcome. The review focus is whether the implementation measures the correct commitment, provides visibility to the appropriate participants at the appropriate time, and supports the expected business response when attention or action is required.

Blueprint import uses supported design elements to create a starting set of Pega Rules and application assets. The imported result reflects the Blueprint design and the capabilities supported by the current Blueprint import capability.

Tour Booking example

The Determine Tour Viability Decision Step illustrates how Blueprint import carries a validated design into Pega Infinity. Import can create a starting Flow Rule containing a Decision shape and initial decision logic. The delivery team validates that this foundation preserves the business question, returned values, and intended paths represented in Blueprint before refining the implementation during Authoring.

An Agent-driven Step follows a similar pattern. Blueprint import provides an Agent Step as a starting point in Pega Infinity. The imported Step retains its position in the Process and the goal established in Blueprint. During Authoring, the delivery team reviews and completes the context, knowledge, permitted tools and actions, expected result, access controls, and participant-intervention conditions required for implementation.

Recognize the import context

A Blueprint can provide the starting point for a new application, add supported design elements to an existing application, or represent an existing application for further design. The imported outcome may depend on related Case Types, Rules, data, Personas, integrations, and supporting relationships represented elsewhere in the Blueprint. These dependencies should remain visible so that the intended journey can be implemented coherently. The Solution Builder determines the detailed import and application architecture.

Other generative AI and Agentic requirements may be preserved as design intent rather than created as fully configured Rules. Confirm what the current Blueprint import capability creates directly, then complete the remaining Rules, Channels, tools, mappings, access, and experience configuration during Authoring.

Blueprint may reveal that part of a design could support more than one journey, Case Type, or application. The Solution Designer's responsibility is to identify where the reusable business value exists before assuming that the complete Case journey should be reused. The Solution Builder determines how the related Rules and assets should be shared in Pega Infinity.

Determine the level of reuse

The complete Tour Booking journey should be reused only when the business outcome, progression, ownership, timing commitments, and Case relationships remain substantially the same. In many situations, the reusable value exists at a lower level, such as a Decision Table, Data Object, integration, Persona, or Agent responsibility. The Solution Builder evaluates how that shared capability should be implemented and governed within the broader application architecture.

Blueprint and Pega Infinity have different but connected purposes. Blueprint develops and validates the intended business solution and preserves the intent for participant, system, generative-AI, and Agent work. Pega Infinity implements that solution through the appropriate Rules, constructs, and application assets. Blueprint import provides supported starting Rules and application assets; other agreed intent is completed during Authoring.

The Solution Designer does not need to configure every Rule. The Solution Designer does need to recognize the principal Rules behind the design, understand the intent they carry, and identify whether the reusable value belongs in the complete journey or an underlying Rule or asset.