Pega Customer Service Developer common mistakes
Pega Customer Service Developer · Understand the traps and how to avoid them.
Designing a new case type from scratch with custom flows instead of reusing the Pega Customer Service (CS) framework's built-in case types and stages, then failing scenario questions that ask how to extend an existing service case.
Candidates with generic Pega Certified System Architect background treat CS as a blank application and default to building bespoke case lifecycles, missing that the exam tests framework extension patterns and inheritance from the Customer Service foundation layer.
What to do instead
Study the CS framework class hierarchy and case type inventory (service requests, complaints, inquiries) and practise the 'specialize a built-in case type, add stages/perspectives, avoid overriding framework rules' pattern until you can state which ruleset layer each change belongs to on demand.
Confusing data classes with work classes when asked where to store customer, account, or product data, and proposing to persist reference data inside the case type.
The exam repeatedly probes the Data-Work split and the CS data model (Customer, Account, Contact, Product), and candidates who memorised generic Pega patterns without the CS overlay misplace the Data- base classes.
What to do instead
Build a one-page map of the CS data classes and their keys, then for each scenario in practice decide explicitly: is this a Data- entity referenced by a case, or a work object with a lifecycle? Justify the choice in one sentence each time.
Wiring integrations by calling external systems directly from the case flow instead of through the CS framework's data pages, connectors, and service integration points, and failing questions on how CS surfaces customer context from backend systems.
Candidates know Connect REST and SOAP in isolation but not how CS uses data pages and integration components to populate the interaction portal, so they answer at too low a level of abstraction.
What to do instead
Trace how a CS interaction loads customer and account context: identify the data pages, their sources, and refresh strategy, and practise describing where a new backend call should be introduced so it is reusable across channels.
Treating the interaction portal and the case worker portal as interchangeable, and answering UI questions without distinguishing the customer-service interaction container from the back-office case processing view.
Portal terminology overlaps and candidates skim the CS portal documentation, so they misattribute which portal hosts the interaction, the 360 view, and the service case actions.
What to do instead
List each CS portal with its purpose, its primary users, and the landing pages it exposes, then for ten sample tasks state which portal performs them. Verify against the portal rules in the application rather than memory.
Ignoring the distinction between an interaction and a service case, and describing wrap-up, intent capture, and disposition as if they were ordinary case stages.
The interaction lifecycle (intent, context, wrap-up, disposition) is CS-specific and absent from generic Pega training, so candidates fold it into the work lifecycle and lose marks on interaction-handling questions.
What to do instead
Memorise the interaction lifecycle stages and what each captures, then practise explaining how an interaction can create, link to, or resolve a service case, and where wrap-up codes and disposition data are stored.
Hard-coding business rules such as eligibility, entitlement, or SLA thresholds inside flow shapes or When conditions instead of using the CS decision and policy rule types, then failing questions about maintainability and change management.
Candidates optimise for the scenario working rather than for where the rule belongs, and the exam tests whether you place configurable business logic in the framework's designated rule types.
What to do instead
For each business rule in a scenario, name the rule type, the class it resolves against, and the layer it sits in. Practise refactoring a hard-coded condition into a decision table or declarative rule and state the benefit in exam terms.
Mishandling security by granting access at the access group level only, or forgetting attribute-based access control for sensitive customer data, when the scenario asks how CS restricts visibility of accounts or records.
Candidates conflate role-based access with CS's use of access groups of role, attribute-based access control, and organisation-level segmentation, and answer with a single mechanism.
What to do instead
Separate the layers explicitly: application and access group, role, attribute-based access conditions, and organisation units. For a scenario, state which layer enforces the restriction and why the others are insufficient.
Designing the solution without accounting for multiple channels and the CS channel services, so web self-service, chat, email, and voice are treated as one undifferentiated entry point.
The exam tests channel-aware design and candidates who only build for the interaction portal miss how the same service case is reached and rendered across channels.
What to do instead
Map each channel to its entry mechanism and the shared service case behind it, and practise stating what changes per channel (UI, authentication, context capture) versus what stays in the framework layer.
Skipping the reuse and extension strategy for the CS framework during upgrades, and proposing direct edits to framework rulesets or built-in rules that would be overwritten on update.
Candidates focus on making the feature work in the current build and do not consider ruleset layering and framework versioning, which the exam probes through upgrade and customisation questions.
What to do instead
Learn the ruleset stack order for a CS application and the rule of never modifying framework rules. For each customisation, name the extension point (pattern inheritance, circumstancing, directed inheritance) and the ruleset it should live in.
Answering reporting and analytics questions by describing ad hoc report definitions against work tables, ignoring the CS interaction and service data model and the reporting structures the framework provides.
Candidates default to generic report creation and miss that CS reporting depends on interaction history, disposition data, and the exposed reporting classes, so the proposed report would not capture the required metrics.
What to do instead
Identify the classes and properties that hold interaction and service outcomes, then design a report against those classes and state its source, filters, and grouping. Practise explaining why a work-table report alone would miss interaction-level metrics.