Estimated reading time: 8–10 minutes
The Challenge
Have you ever faced the following scenario in your Pega implementations? A banking client recently raised an intriguing question to me:
“As a case worker, I want to create an ad hoc task during case processing—something outside the standard lifecycle—but ensure that this task does not appear to anyone or become executable until a specific point in the future of the case lifecycle, so i.e., when the case reaches a specific stage or step ahead in its lifecycle.”
In other words, during an early stage of a case, a user identifies an exceptional need and wants to schedule it for later execution. Out-of-the-box, Pega offers creation of ad hoc assignments, but those are created for immediate execution and become visible right away to the assigned user or team. But what if you need to delay it until a strategic point in the case lifecycle? So, how do we defer it?
In this article I will explore three different approaches trying to solve such challenge, comparing implementation complexity, technical viability, and adherence to Pega best practices.
Approach 1: Conditional Creation at the Right Moment
Concept – How It Works
This approach uses properties to capture the intent (what needs to be done) and when it should occur within the case lifecycle. When the case reaches the designated “process point”, a conditional process checks if any task needs to be created and executes it accordingly. So, it creates the task dynamically when the case reaches the designated stage.
Implementation Steps:
- Create the data model to store the future task information (type, assignee, instructions) and the stage/step where the task should be executed.
- Add a conditional process, triggered by stage entry, to each relevant stage that checks these properties.
- When the condition is met, create the appropriate task (optionally, create a child case if the task requires isolation).
- Optionally implement a “Wait” step if the main process must pause for task completion
Pros:
- Follows standard Pega design patterns
- Minimal customization required
- Easy to maintain and upgrade
- Flexible and can handle multiple types of delayed tasks
- Can incorporate decision logic about whether to proceed or wait for task completion
Cons:
- Requires careful orchestration of conditions and timing logic
- Needs conditional processes in multiple stages to check for pending tasks
- Demands additional configuration to handle complex scenarios
Implementation Complexity: 
☆☆☆ (Medium-Low)
- Uses standard configuration capabilities
- Requires the right data model design & conditional processes
Technical Viability: (High)
- Fully aligned with Pega best practices
- Resilient across upgrades
- Highly sustainable approach
Approach 2: Extend Ad Hoc Assignment Mechanism
Concept – How It Works
This approach would consist of extending/customizing Pega’s standard ad hoc task creation mechanism to include lifecycle metadata (e.g., stage or step where it should appear / execute). This approach involves creating a custom component that would enhance Pega’s native functionality.
Implementation Steps:
- Taking the standard ad hoc task creation mechanism as foundation, we will extend it to include target stage/step information during creation.
Pros:
- Seamless user experience for creating deferred tasks, potentially more elegant from a user perspective
- Creates a reusable (custom) component
Cons:
- Requires low-level customization and creates a non-standard component
- Maintenance risk, it may need manual observation / work under version upgrades & patches
- Deviates from standard Pega patterns, which might affect maintainability and could be impacted by future Pega platform changes
Implementation Complexity: ☆ (Medium-High)
- Requires custom development
- Needs quite deep platform knowledge
- May involve Java / JavaScript customization
Technical Viability: ☆☆☆ (Medium-Low)
· Functional, but may require manual maintenance during upgrades
· Potential compatibility issues with future releases, it may not work with all Pega versions consistently
Approach 3: Child Case with Controlled Activation
Concept – How It Works
This approach allows users to create a child case via local action. Initially, the first assignment in the new case sits in an inaccessible workbasket. When the conditions are met for task execution (determined by the parent case), the task to be performed is assigned to the appropriate user or team.
Implementation Steps:
- Create a child case with an initial placeholder task
- Assign this task to an unmonitored workbasket
- Configure the parent case to monitor conditions and to communicate with the child case when these execution conditions are met, and signals to advance
- Automatically reassign the task to the correct assignee when ready for execution, and notify via automated alerts when activation occurs (and update the case’s audit history)
- Optional: Implement “point of no return” logic for cases to advance without immediate validation
Pros:
- Uses Pega’s standard parent-child case capabilities, supporting bidirectional communication and advanced orchestration between parent and child cases
- Flexible and powerful for complex scenarios.
- Provides strong isolation between main case flow and ad hoc tasks
- Allows complex condition management
- Can incorporate notification capabilities (alerts, audit)
Cons:
- Adds complexity to case hierarchy and governance during initial setup, and may require more careful management of case relationships
- Potential overhead from maintaining multiple cases
- Additional cases created in the system
Implementation Complexity: ☆☆ (Medium)
· Uses standard case relationships but with sophisticated configuration
· More complex case relationship management
Technical Viability: (High)
- Strong viability as it uses standard case patterns
- May have slightly higher processing overhead
- No issues regarding compatibility with upgrades
My Initial Recommendations Based on Project Context?
-
For Quick Implementation with Minimal Resources: Approach 1 (1. Conditional Creation at the Right Moment) provides the fastest path to implementation while maintaining good Pega practices. It’s ideal for projects with limited development resources or tight timelines.
-
For Enterprise-Scale Solutions with Complex Requirements: Approach 3 (Child Case with Controlled Activation) offers the most robust framework for complex scenarios, especially when cases involve multiple conditional branches, notifications, or complex business rules around when tasks should be executed.
Which approach would you implement (or have you used)? Have you faced a similar challenge in your Pega implementations? Please, I’d love to know from your experience, vote for your preferred approach, or suggest alternative approaches in the comments.
And if you’ve implemented any of these approaches, what were the challenges and lessons learned? Your insights could be invaluable to other community members facing similar requirements.
#Pega #CaseManagement #AdHocTasks #WorkflowAutomation #DigitalTransformation #LowCode #ExpertCircle #BusinessProcessManagement #InnovationInAction #Pegasystems