Extending a Pega Strategic Application with custom requirements is a common challenge — done wrong, it creates upgrade debt that compounds over time. This article presents a real-world pattern from a financial services engagement: building a regulatory accreditation model as a fully separate application integrated to Pega AIM via OOTB Skills, keeping the core application clean and upgradable while satisfying a complex regulator requirement.
Every custom rule you bolt into a Strategic Application is a rule you’ll have to re-test at the next upgrade.
On Pega Cloud, upgrades are frequent and increasingly automated. Extension hygiene, i.e. how cleanly your customizations sit relative to the OOTB core, is what determines whether each upgrade is a routine event or a disruptive project.
So what do you do when a significant regulatory requirement arrives that simply doesn’t fit the OOTB model?
The requirement
On a recent financial services engagement, the regulator required a structured accreditation model for operators working inside the alert investigation management system. The customer was running Pega AIM, which handles assignment routing and case management for financial crime investigations, but AIM has no native accreditation capability.
The accreditation model requirement was specific:
- Operators must complete a defined threshold of cases successfully before progressing to the next skill level
- Any failed case review resets the counter for that operator
- Alongside automatic counters, manual approval steps are required before a skill level is formally granted
- Skill level directly determines which cases an operator can be assigned to
If you decide to build counters, workflow, and approval logic directly inside AIM, then you will face a problem: every piece of that logic becomes a customization that lives inside a Strategic Application — tested against the current version, fragile at the next upgrade.
The pattern: separate application, OOTB integration point
Instead, we built accreditation as an entirely separate Pega application, responsible for all accreditation business logic. AIM’s role was reduced to a single, clean responsibility: sending one-way events to the accreditation application when cases are completed or reviews are failed.
The accreditation application owns everything else:
- Maintaining per-operator counters, incremented on successful case completion, reset on failed review
- Managing the approval workflow when an operator reaches a counter threshold
- Writing the resulting skill level back to the operator record via Pega Skills
AIM reads those skill levels through its standard OOTB assignment routing configuration — the same mechanism it would use for any skill-based routing. It has no awareness of accreditation logic, counters, or approvals.
The architecture is intentionally one-directional: AIM sends events, accreditation model responds by updating skills, AIM reads skills. No circular dependencies, no shared logic.
How Blueprint accelerated the build
We used Pega Blueprint to design the accreditation application before a line of configuration was written. Blueprint generated the data model for operator counters and the case lifecycle for the approval workflow — imported directly into the working application. The manual build work reduced to three things: plugging the event APIs from AIM, creating the skill definitions, and automating the skill level transition logic.
This is Blueprint’s real value in practice: with significant productivity boost it can help you offset the relative overhead of maintaining this logic in a separate application.
What this kept clean
- Zero changes to AIM’s core flows or routing rules
- Accreditation logic fully isolated: independently configurable, independently testable, independently upgradable
- Routing behavior in AIM adapts automatically as skill levels change — no custom routing rules to maintain
- The accreditation application can evolve with regulatory requirements without touching the Strategic Application
The broader principle
When a new capability doesn’t fit your Strategic Application, don’t force it in. Build it as a separate, separable module — whether that’s a built-on component included in your application’s inheritance stack or a fully independent application integrated through OOTB platform mechanisms like Skills, Data Pages, or APIs.
The integration point matters as much as the separation. Pega Skills worked here because they are natively supported by any Pega application. We leaned on them as an extension point, rather than threading new logic through AIM’s internals.
Either way, the principle holds: keep the OOTB core clean, and every future upgrade stays routine: build current, stay current!