PEGACPBA24V1 Practice Questions

The Send Notification automation step is the most suitable and correct choice. In the Pega Platform™, this step is specifically designed to configure and send various types of communications to users, including push notifications, emails, and SMS messages. For an e-commerce website needing to provide an order update, the Send Notification step offers the necessary functionality to alert the customer through the most appropriate channel, such as a push notification to their mobile app or an email, making it the correct and encompassing automation for this scenario.

B. Update Case: This automation modifies data within the current case or another Pega case; it does not send communications to external users.

C. Push Notification: This describes a type or channel of notification, not the name of the automation step itself in modern Pega. The correct step is "Send Notification."

D. Post to Pulse: This is used for internal collaboration among case workers within the Pega application, not for communicating with external customers.

---

1. Pega Academy | Pega Platform 24.1 | Business Architect Mission | Module: Communicating with users | Topic: Sending notifications.

Reference: "The Send notification step sends push notifications

emails

and SMS messages to a single user or a group of users." This official courseware explicitly names the automation step as Send Notification and lists push notifications as one of its functions.

2. Pega Documentation | Pega Platform 24.1 | Case management | Automating case processing | Available automation shapes | Send Notification shape.

Reference: "Use the Send Notification shape to automatically send a notification to one or more users... You can send notifications through different channels

for example

by email

push notification

or a notification in a web portal." This documentation confirms that Send Notification is the name of the automation shape and that "push notification" is a channel configured within it.

In Pega, the case life cycle is designed to progress through stages sequentially. To handle optional stages based on business logic, you configure a "Skip when" condition on the stage itself. In this scenario, the "Customer Survey Stage" should only be executed if the customer agrees. The most direct and standard configuration is to define a condition that skips the stage when the customer does not agree to the survey. When the skip condition is met, the case bypasses the stage and moves to the next step, which is resolution.

A. Configure the Customer Survey Stage to never skip.

This is incorrect because it forces the stage to always execute, which contradicts the requirement for it to be conditional.

B. Configure the Processes in the Customer Survey Stage to start if the customer indicates interest in filling out a survey.

This is incorrect because the condition must be evaluated at the stage level to control entry, not on the individual processes within the stage.

D. Configure the Customer Survey Stage with a custom condition to start when the customer indicates interest in filling out a survey.

This is incorrect because for primary path stages, the standard Pega configuration is to define the exception condition for skipping the stage, not the positive condition for starting it.

1. Pega Platform Documentation - Configuring stage entry and skipping: "You can configure a stage to skip for a specific condition... In the case life cycle

in the stage that you want to skip

click Configure stage behavior... In the Stage configuration pane

in the Skip stage when list

select a condition that determines whether to omit the stage from the case life cycle." This directly supports using a "Skip stage when" condition.

Source: Pega Platform™ 24.1 Documentation

"Configuring stage entry and skipping".

2. Pega Academy - Business Architect (24.1) Mission

Module: Configuring a case life cycle: This module details the configuration of case stages. It explicitly demonstrates using the "Skip stage when" option in the stage's property panel to control the case flow based on a when rule or a simple expression. The logic is to define the circumstances under which a stage should be bypassed.

Source: Pega Academy

Pega Certified Business Architect (PCBA) 24.1 learning path

"Configuring a case life cycle" module

"Optional actions" topic.

Pega's Center-out business architecture is a model that places the customer journey and business outcomes at the core of the design. It orchestrates work by applying business logic and rules to automate processes and guide human tasks. This approach ensures consistent and context-aware interactions across all channels (such as web, mobile, and call center), effectively aligning human intelligence and process automation to deliver optimal, high-value solutions.

B. Customer-centric: This is a general business strategy and a key principle of the Center-out approach, but it is not the specific name of Pega's architecture.

C. Business-first: This describes a general development philosophy that prioritizes business needs, not the specific name of Pega's architectural model.

D. Pega Express: This is a light, agile delivery methodology for building Pega applications, not the name of the underlying business architecture itself.

---

1. Pega Academy. (2024). Pega's Center-out approach. In the "Pega Business Architect" mission. This module defines the Center-out business architecture as the model that "breaks down organizational silos and delivers a consistent customer experience across all channels" by starting from the customer outcome.

2. Pega Documentation. (2024). The Center-out business architecture. Pega Platform™ Documentation. This section states

"The Center-out™ business architecture from Pega helps you deliver a consistent and seamless experience across all channels... It combines customer-centricity with business logic and process automation to deliver real-time

one-to-one customer engagement."

3. Pega Documentation. (2024). Pega Express methodology. Pega Platform™ Documentation. This resource explicitly defines Pega Express as "our light

design-focused delivery methodology

" distinguishing it from an architectural concept.

The business requirement is to allow the parent case to proceed independently of its child cases. The Wait step is used to pause a case, often to wait for child cases to reach a certain status. To meet the requirement for independent processing, the Wait step must be configured to not enforce a dependency. Option A describes configuring the step to allow the parent case to continue regardless of the child case status, which directly fulfills the requirement by effectively removing the pause condition related to the child cases.

B. Configure the step to continue the parent case when the child cases reach auditor approval.

This creates a specific dependency on a child case status, forcing the parent case to wait, which contradicts the requirement for independence.

C. Configure the step to continue the parent case when the child cases reach the payment pending review status.

Similar to option B, this imposes a wait condition based on a child case status, preventing the parent case from proceeding independently.

D. Configure the step so that only one child case must be resolved before the parent case can continue.

This configuration still forces the parent case to wait for a child case to be resolved, which is a dependency, not independent processing.

1. Pega Academy: Business Architect (24) mission

Module: Pausing and resuming case processing

Lesson: Pausing a case. This lesson explains the configuration of the Wait step

including options to wait for dependencies (like child cases) or to allow the case to proceed. The option to allow users to continue the process manually or to set no wait condition aligns with making the parent case independent.

2. Pega Platform Documentation: Adding a Wait step to a case. The documentation details the "Wait for" options

which include pausing until child cases are resolved or reach a specific status. To achieve independence

one would not select these dependency-based options and instead configure the step to allow immediate or manual continuation.

Optional actions (formerly known as local actions) are the standard Pega feature for allowing users to perform discretionary, single-task activities that are not part of the primary case path. By configuring an optional action for each user profile page (Account ID, Contact Info, Open Orders), you empower the customer to update any of this information individually and at any point during the order placement stage. This design provides flexibility without disrupting the main workflow of placing an order.

B. Add an alternate stage to the case life cycle.

An alternate stage is used to model exceptions or deviations from the primary case path, not for optional, user-initiated tasks.

C. Add a button for each profile page to each assignment.

While technically feasible, this is not the standard Pega design pattern. Optional actions are the designated, out-of-the-box feature for this purpose, providing better maintainability.

D. Add an optional process to the case workflow.

An optional process is designed for a multi-step sequence that a user can choose to run. For updating a single page of information, a more granular optional action is the appropriate choice.

---

1. Pega Academy

Business Architect (24.1) Mission

"Case life cycle design" Module

"User actions" Topic.

Reference: This module explains that "An optional action allows a user to perform a single task outside of the primary path of a case." It clarifies that users can launch these actions at any time within a stage or specific assignment

which directly supports the requirement to allow individual updates during the order placement stage.

2. Pega Platform™ 24.1 Documentation

"Adding an optional action to a case type."

Reference: This document states

"Optional actions enable users to perform tasks in any order and at any time

outside of the structured workflow of a case." This directly aligns with the need to allow customers to update profile pages individually and at their convenience.

3. Pega Platform™ 24.1 Documentation

"Alternate stages."

Reference: This section defines the use case for alternate stages: "Use alternate stages to organize process steps that are not part of the normal course of events... For example

a case might transition to an alternate stage if a manager rejects a request." This confirms that alternate stages are for exception handling

making option B incorrect.

4. Pega Platform™ 24.1 Documentation

"Optional processes."

Reference: This document describes an optional process as something users can run "to complete a task that is not a part of the main case workflow." It emphasizes that this is a process (a flow with potentially multiple steps). This distinguishes it from an optional action

which is better suited for the single-screen updates described in the question

making option D less precise than A.

The requirement is to sort cases so the most recent 'Create Date' appears at the top. This is a descending sort order. In a Pega report definition, sorting a date or numeric column from "Highest to Lowest" arranges the records in descending order. The highest date value is the most recent date, fulfilling the manager's request to see the newest cases first.

B. Making the Create Date the first column only changes its display position in the report grid; it does not control the sort order of the records.

C. Selecting "Lowest to Highest" would sort the cases in ascending order, placing the oldest cases at the top, which is the opposite of the requirement.

D. This is a filter condition, not a sorting option. It would incorrectly attempt to show only cases created in the future, resulting in an empty report.

1. Pega Academy: Business Architect Mission

Module: Reporting

Topic: Creating a report. This module explains that to sort data

you use the sorting options in the report definition's Query tab

and a descending sort (Highest to Lowest) is used to show the most recent items first.

2. Pega Platform Documentation: Creating a report definition

Section: Report Definition Query tab. The documentation specifies that the "Sort" section on the Query tab is used to define the record order. For date properties

selecting "Highest to Lowest" as the "Sort Type" configures a descending sort.

According to Pega best practices, a child case is ideal for handling a part of a business process that can be instantiated multiple times, involves different parties, and can run in parallel. In the automobile insurance claim scenario, a single claim (the parent case) can involve repairs for multiple vehicles. Each vehicle repair is a distinct unit of work, often handled by a different third-party repair shop. Creating a "Repair" child case for each vehicle allows these processes to be managed independently while the parent "Claim" case tracks their overall progress and awaits their completion before it can be resolved.

A. Verification: This is the final, concluding phase of the parent case itself, not a separate, repeatable unit of work that would justify a child case.

B. Submission: This is the initiation step of the parent case. A case cannot be a child of itself or its own starting point.

C. Review: This is a core, sequential stage within the parent case life cycle, typically performed once by the adjuster for the entire claim.

1. Pega Academy

Pega Business Architect (24.1) Mission: In the "Case Design" module

the topic "Creating a child case" explains the rationale for using child cases. It states

"You create a child case when a case includes a separate business transaction that can run in parallel to the main case... For example

an auto accident claim may require separate cases to process the vehicle damage claim for each vehicle involved." This directly maps to the "Repair" phase in the question.

2. Pega Documentation

"Case relationships": The section on "Parent-child relationships" provides guidance on when to use this pattern. It states

"Use a parent-child case relationship to manage complex business transactions. For example

in an auto insurance claim

the main parent case can have multiple child cases for processing claims from each party that is involved in an accident." This confirms that processing individual vehicle-related tasks (like repairs) is a primary use case for child cases within a larger claim.

This solution maps Pega Platform automation shapes to their specific business requirements:

1. Send email: Used to generate and send automated correspondence (confirmations) to interested parties.
2. Change to a stage: When a case is rejected, the workflow must often revert to a previous phase (e.g., a "Correction" stage) to allow the employee to modify data. This shape transitions the case flow to a specific stage.
3. Push notification: Specifically designed to send alerts to mobile devices, matching the requirement for a "mobile notification."
4. Create PDF: This automation converts a section or view of the case data into a portable document format (PDF) and automatically attaches it to the case file, satisfying the requirement to attach a finalized report.

Pegasystems Inc., "Sending emails," Pega Academy, [Online]. Available: https://academy.pega.com/topic/sending-emails/v1. (Accessed for verification of correspondence automation).

Pegasystems Inc., "Controlling the flow of a case," Pega Academy, [Online]. Available: https://academy.pega.com/topic/controlling-flow-case/v1. (Describes the "Change to a stage" automation for alternate paths like rejection).

Pegasystems Inc., "Sending push notifications," Pega Academy, [Online]. Available: https://academy.pega.com/topic/sending-push-notifications/v1. (Confirming mobile-specific alerting).

Pegasystems Inc., "Creating PDF files," Pega Academy, [Online]. Available: https://academy.pega.com/topic/creating-pdf-files/v1. (Verifies the functionality of generating and attaching case reports).

In Pega Platform, reporting is categorized based on the type of metrics used: Business Metrics or Process Metrics.

Business reports analyze the actual data entered into a case to track operational performance or volume. The item "Total customer inquiry cases per state per product line" aggregates case data based on business properties (State and Product Line), classifying it as a business report.

Process reports track the performance of the workflow itself (how work is performed), utilizing system-generated metrics like time, effort, and SLA compliance. The item "Average duration and timeliness per assignment" measures the efficiency of task completion and adherence to deadlines, which identifies it as a process report.

Pega Academy, "Reporting concepts", Section: Business and process metrics.

Quote: "Business metrics represent the data that you enter into a case... Process metrics represent how work is performed."

Context: Defines the distinction between tracking case data (Business) vs. tracking time/throughput (Process).

Pega Platform Documentation, "Report Browser" & "Standard reports".

Context: Documentation on standard reports confirms that "Timeliness" and "Duration" fall under "Monitor Process" or "Analyze Performance" categories (Process reports), while case counts by property fall under "Analyze Quality" or "Monitor Assignment" business data views.

In Pega Platform case design:

• Collect Information steps create an assignment for a user to input data into a form, matching the action where a user enters reservation details.
• Approval steps are specific assignments routed to a supervisor (manager) to explicitly accept or reject a case, matching the timesheet review scenario.
• Decision steps are automated processes where the system evaluates logic or conditions (such as checking a request type) to determine which path the workflow should take next.
• Automation steps perform system-side actions without human intervention, such as sending correspondence (emails) or updating databases.

Pega Documentation: Configuring the Case Lifecycles. "Collect information... Assigns a task... to a user... to collect users' personal details." / "Approve/Reject... Assigns a task to a user, typically a manager... to approve or reject the Case." / "Decision... Evaluates an Expression... to determine which Step is next." / "Automation... Provides preconfigured functionality, such as sending an email..." (Source 1.4)

Pega Academy: Designing a Case Life Cycle. "Collect information Steps are Steps that require user action or input." / "Automation Steps are steps performed by the system... send emails..." (Source 1.1, 1.2)

Pega Academy: Work approval. "Case approvals are decision points at which one or more users decide whether to approve or reject a case." (Source 2.1)