3.4 Duplicate Case Detection, Automation Shapes & Automated Correspondence
Key Takeaways
- The Search duplicate cases step compares an in-flight case against existing cases using basic conditions (every one must be true) and weighted conditions, flagging a potential duplicate only when the summed weights meet or exceed the configured threshold.
- Weighted condition weights and the duplicate threshold are both integers between 1 and 100, configured in Case Designer under Settings > Track duplicates.
- Automation shapes are system steps that run without a user: Create case, Send email, Create PDF, Change stage, Change status, Run data transform, Persist case, and Post to Pulse are the ones most often tested.
- Choose an assignment step (Collect information, Approve/Reject) when a human must act, and an automation step when the platform can complete the work unattended.
- A Send email automation sends correspondence from inside the life cycle using a correspondence rule or email template, while an Email channel handles inbound email that creates or updates cases.
3.4 Duplicate Case Detection, Automation Shapes & Automated Correspondence
Two official Case Management objectives sit slightly outside the stage-and-step material covered so far: identifying duplicate cases and understanding when to use automation shapes. Both describe work the platform performs without a human assignment, and both appear on the exam as scenario questions where the wrong answer is a hand-built process that duplicates a configuration Pega already provides.
1. Duplicate Case Detection
Enterprise intake channels leak duplicates constantly. The same customer submits a claim through the web portal on Monday, phones the call center on Tuesday, and emails a scanned form on Wednesday. Without detection, three separate cases consume three separate adjudication budgets and can produce three conflicting outcomes.
Pega solves this with a Search duplicate cases step. When a case reaches the step, the platform compares the current case against existing cases of the same case type and returns a list of potential duplicates for the user to review.
Basic Conditions vs Weighted Conditions
Duplicate logic is deliberately two-tiered, and the exam tests the distinction.
| Condition tier | Evaluation rule | Purpose | Typical example |
|---|---|---|---|
| Basic conditions | Every basic condition must be true before a case is even considered a candidate | Cheap, high-selectivity filter that narrows the comparison set | Case status is not resolved; same product line |
| Weighted conditions | Each condition that evaluates to true contributes its weight; the weights are summed | Fuzzy similarity scoring across several fields | Same customer ID (weight 60); same loss date (weight 30); same policy number (weight 40) |
The decision rule is a threshold comparison. In Case Designer, on the Settings tab, select Track duplicates. In the Case is duplicate when sum >= field, enter a threshold between 1 and 100. Each weighted condition's Weight is likewise an integer between 1 and 100. If the sum of the weights of the conditions that evaluated to true meets or exceeds the threshold, the platform flags the case as a potential duplicate.
Worked Example
An auto insurer configures duplicate detection on a First Notice of Loss case type:
- Basic conditions: the candidate case is not resolved, and the candidate case is the same case type.
- Weighted conditions: same policy number (50), loss date within one day (30), same vehicle VIN (40).
- Threshold:
Case is duplicate when sum >= 70.
A new claim shares the policy number (50) and the VIN (40) but was reported for a different loss date. Sum = 90, which is at or above 70, so the case is flagged. A second claim shares only the loss date (30). Sum = 30, below the threshold, so it is not flagged.
Note what the platform does not do: it does not automatically resolve or delete anything. Flagged duplicates are surfaced to the user, who decides whether to mark the case a duplicate (and resolve it) or continue processing.
Exam Traps
- Trap 1: Treating weighted conditions as mandatory. Basic conditions are the "all must be true" tier. Weighted conditions are additive and individually optional.
- Trap 2: Writing a report definition and an activity to find duplicates. That is the guardrail-violating distractor. Use the configured duplicate search.
- Trap 3: Assuming a threshold above 100 is possible. Both weights and the threshold are capped at 100.
2. Automation Shapes in the Case Life Cycle
A step in a Pega case life cycle is either an assignment (a person must do something, so the case waits) or an automation (the platform does something and processing continues). Automation shapes render as their own shape category in Case Designer, and the exam expects you to pick the right one rather than writing an activity.
| Automation shape | What it does | Typical use |
|---|---|---|
| Create case | Instantiates a child or peer case | Spin off a credit check case from a loan case |
| Send email | Sends correspondence to a recipient | Confirm receipt of an application |
| Create PDF | Renders a view or section into a PDF attachment | Produce a signed offer letter |
| Change stage | Moves the case to another stage | Jump to a Remediation stage after a failed audit |
| Change status | Sets .pyStatusWork | Mark a case Pending-Review |
| Run data transform | Executes a data transform | Normalize address fields before a connector call |
| Persist case | Writes a temporary case to the database | Commit a case created by a staged intake form |
| Post to Pulse | Publishes a message to the case's Pulse feed | Notify the team that underwriting completed |
| Attach content | Adds a file, URL, or note to the case | Attach a generated policy schedule |
Choosing Between an Assignment and an Automation
Ask one question: does the case need to stop and wait for a person?
- If yes, use an assignment step such as Collect information or Approve/Reject, which creates a work item on a worklist or work queue.
- If no, use an automation step. The case executes it and moves on in the same processing pass.
A classic exam scenario: "After the applicant submits documents, the system must generate a PDF acknowledgment and email it to the applicant before routing to underwriting." The correct configuration is a Create PDF automation followed by a Send email automation, then an assignment routed to the underwriting work queue — not a single Collect information step with post-processing logic bolted on.
3. Automated Email Correspondence
The Send email automation is how a case emits outbound correspondence without any human keystroke. Configuration has three parts:
- Recipients. Choose the case's originating operator, a work party, a specific operator, or a property reference that resolves to an address. Work parties are the reusable, guardrail-friendly answer when the recipient varies by case.
- Content. Point the step at a correspondence rule or email template so the body is a maintained, localizable rule rather than text typed into the step. Templates support property references that interpolate live case data.
- Attachments. Attach case attachments (including a PDF produced by an upstream Create PDF automation) so the recipient receives the document, not a link they cannot open.
Send Email Automation vs Email Channel
These are different mechanisms and the exam contrasts them:
- A Send email automation is outbound and runs inside a case life cycle at a point you choose.
- An Email channel is inbound. It listens on a monitored mailbox and creates or updates cases from arriving messages, with optional AI-driven triage.
If the requirement says "when the case reaches the Approved stage, notify the customer," that is a Send email automation. If the requirement says "customers should be able to open a case by emailing support@," that is an Email channel.
4. Putting It Together
A well-designed intake stage typically runs: Search duplicate cases → (user resolves or continues) → Run data transform → Create PDF → Send email → assignment. Every one of those steps except the final assignment is unattended, which is exactly the low-code, model-driven pattern the CSA exam rewards.
A claims case type uses duplicate detection with two basic conditions (the candidate case is unresolved and is the same case type) and three weighted conditions: matching policy number (weight 50), matching incident date (weight 25), and matching claimant tax ID (weight 45). The threshold is set to 70. A newly submitted claim is unresolved, is the same case type, matches an existing case on policy number and claimant tax ID, but has a different incident date. What does the platform do?
A requirement states: when a mortgage case enters the Closing stage, the application must generate a PDF of the closing disclosure, email it to the borrower, and then wait for a closing agent to confirm the appointment. Which configuration follows Pega's model-driven best practice?
During a design review, an architect proposes finding duplicate cases by writing a report definition that queries the work table, calling it from an activity in the intake flow, and looping over the results in Java to score similarity. What is the correct assessment?