Hi, how to Resume flow from activity without doing a Commit.
I tried passing Param.calledfromservicelevel==“true”
But it is giving a error “Assignment corrupted”, But the assignment is fine.
Assignment Corrupted usually error occurs when the assignment page (Assign- page) when not in a consistent state when ResumeFlow is invoked i.e. if you’ve modified assignment-related properties but haven’t persisted them correctly, or if the assignment context is stale.
However, before performing assignment level activities via Activities, in most scenarios, manually resuming a flow from an activity (especially without a proper commit) is a sign that we’re working around the platform rather than using its built-in capabilities
below are few pega recommended alternatives-
- Use flow exception handling shapes: If the goal is to handle exceptions or retries during assignment processing, leverage OOTB case management features like Alternate Stages or perform pxChangeStage / pxRestartStage for stage transitions or restarts.
- Prefer Constellation DX APIs over custom activities: Assuming this is a Constellation-based app, the assignment- and case-level DX APIs are designed exactly for this kind of operation. you can perform / finish assignment using PATCH /assignments/{id}/actions/{viewName}. Or, Update Case / Change Stage APIs also handle appropriate flow persistence, resumption and assignment state management OOTB.
Also, could you please help us understand the business requirement/ usecase here?
as if this is a one time exception or a continuous and what exception/ condition has caused it etc. to better advise on if this is a retry scenario or stage jump or data correction mid-assignment.
Before performing resume flow, I have committed. And the data is committing.
After that I am doing a obj-open-by-handle of that assignment and doing a resume flow with Param.calledfromservicelevel==“true”. still I am seeing the error.
Is there a was to resume the flow without committing.
ResumeFlow requires a tightly managed transaction state between three entities- WorkObject, Assignment and pxFlow metadata.
When you perform an Obj-Open-By-Handle on the Assignment page without properly locking, opening, and synchronizing the parent Work Object onto the clipboard, the Flow Engine detects a state mismatch. Setting Param.calledfromservicelevel = “true” bypasses SLA-specific queue handling, but it does not skip deferred database commits or lock state validation required by the underlying engine API (Work-.ResumeFlow or pxResumeFlow).
In Pega, manually opening assignments and calling low-level API activities like ResumeFlow directly from custom activities is not a recommended practice.
Instead, you can try
Approach# 1: Execute via DX API
PATCH /assignments/{assignmentID} or
POST /assignments/{assignmentID}?actionID={actionID}
The DX API framework natively handles opening and acquiring proper locks on both the Case (pyWorkPage) and the Assignment (Assign-). Executing pre/post-data transforms and validations attached to the Flow Action. Processing the flow progression and executing transaction commits cleanly (pxCommitTransaction) under proper security/ABAC context.
Approach# 2: Change Stage
If the process needs to resume automatically within Pega or your goal is to jump out of a stuck assignment or bypass a flow completely rather than completing a specific action, you can invoke the pxChangeStage Activity on the WorkObject and provide the necessary Stage name. This cleanly cancels current assignments, cleans up clipboard references, and transitions the case to the target stage/step without corrupting assignment state.
Param.calledfromservicelevel==“true” - this Flag is used to indicate if this is called from an SLA
Is there a specific reason to commit before the ResumeFlow? why don’t you do a ResumeFlow and commit?
Before the Resume flow there is some updates on a case. That data is not being fetched by Resume flow, it is getting the old data.
It is happening in the pxAddchild, which is running in a queue processor.