Update failed. Cannot update approval tasks to and from the Closed Complete s

[Tomi Corigliano]

Hi,

Does anyone know how the following message is generated and how the drag and drop of an approval task on a DPR Release is prevented?

Message: Update failed. Cannot update approval tasks to and from the Closed Complete state.

Drag and drop action: Move Approval Task from 'Closed Complete' to 'Work in Progress'

[MaxMixali]

ServiceNow – DPR Release: Approval Task “Update Failed” Message Explanation

Scenario
When trying to drag and drop an Approval Task on a DPR (DevOps/Deployment Pipeline Release) from one state to another (e.g., Closed Complete → Work in Progress), the platform displays:

"Update failed. Cannot update approval tasks to and from the Closed Complete state."

Root Cause
This message is generated by a Business Rule on the rm_task or dva_release_task table that prevents updates once an approval task reaches a terminal state. The purpose is to preserve workflow integrity and historical accuracy of approvals.

Technical Details
1. Tables involved:
- rm_task or dva_release_task (depending on release configuration)
- Approval tasks often extend task and inherit the state model logic.

2. Enforcement:
- A Before Update Business Rule (OOB example: “Prevent Update from Closed Complete”) triggers when the record’s state changes.
- Example logic:
```js
if (current.state.changes() &&
(previous.state == '3' /* Closed Complete */ || current.state == '3')) {
gs.addErrorMessage('Update failed. Cannot update approval tasks to and from the Closed Complete state.');
current.setAbortAction(true);
}
```
- Any UI, API, or board operation that attempts to update the record state will be blocked.

3. Drag-and-Drop in DPR Workspace:
- The DPR release workspace uses a state change API to update tasks when dragged between board columns.
- The API call triggers the same Business Rule.
- The rejection message is surfaced through the API response and displayed on screen.

How to Locate the Rule
1. Navigate to System Definition → Business Rules.
2. Filter by Table = task, rm_task, or dva_release_task.
3. Search for names containing “Closed Complete,” “Prevent Update,” or “Approval.”
4. Check scripts that include gs.addErrorMessage() and setAbortAction(true).

Recommended Practices
- Do NOT disable the rule; it enforces audit integrity for approvals.
- If reopening tasks is needed, implement a controlled mechanism:
- Create a UI Action “Reopen Approval” visible only to admins or managers.
- In the script, temporarily bypass the restriction for that controlled action.

Example controlled exception:
```js
if (gs.hasRole('admin') && current.state.changesTo('2')) {
// Allow admin to reopen
return;
}
```

Summary
- The message is generated by an OOB Business Rule preventing updates to/from “Closed Complete.”
- Drag-and-drop updates trigger this rule via API.
- The safeguard ensures approvals remain immutable after completion.
- Modify only under strict control to preserve compliance and data integrity.

[MaxMixali]

This is coming from a server-side guard on the DPR Approval Task table. In the DPR Release workspace, when you drag a card between lanes you’re really updating the record’s state. An OOB “Before update” Business Rule / State Model policy on the DPR approval task table blocks any transition to or from Closed Complete and throws the error:

Update failed. Cannot update approval tasks to and from the Closed Complete state.

So:

Why you see the message

• The Kanban/board drag-and-drop tries to set state from Closed Complete → Work in Progress (or vice-versa).

• The approval task state model treats Closed Complete as a terminal state.

• A Business Rule (or State Flow transition rule) detects previous.state == closed_complete or current.state == closed_complete, calls gs.addErrorMessage(...), and setAbortAction(true).

You can locate it by:

• System Definition → Business Rules: filter by the DPR approval task table (search for “approval” + “release”) with Active = true, When = Before, Operation = Update, then open rules that mention “Closed Complete”.

• Or check State Flows / State Models for that table: transitions to/from Closed Complete are disabled.

How to prevent drag & drop (UX) instead of letting server throw an error

Pick one (or combine):

1. Lock the column in UI Builder

   • Open the DPR Release board page in UI Builder.

   • Select the board/lanes component.

   • For the Closed Complete lane/column, disable accept drop / mark as non-droppable (or add a visibility/drag rule so items aren’t draggable when state == closed_complete).

2. Enforce transitions in State Model

   • Use State Flow / State Model for the DPR approval task table.

   • Ensure no transitions are allowed into or out of Closed Complete except via a specific Reopen transition (if your process allows it).

   • The board will honor allowed transitions and block the drop UI-side.

3. ACL hardening (last resort)

   • Add a Write ACL on state that returns false when current.state == closed_complete and the new value ≠ closed_complete.

   • This keeps the rule on the server regardless of the client, but still shows a server error if someone tries.

If you actually need to “reopen” approvals

• Provide a Reopen Declarative Action / UI Action that:

  • Validates business conditions,

  • Sets state to the correct “reopened” state,

  • Rebuilds any approval routing as needed.

• Keep drag-and-drop disabled for Closed Complete; use the action instead.

Bottom line: the error is expected—DPR Approval Tasks treat Closed Complete as terminal. Make the Closed Complete lane non-droppable (UI Builder) and keep the state model restrictions on the server.

[GlideFather]

Hi @Tomi Corigliano,

as far as I know, once the Approval task is closed (similarly to any other records in closed state) it's not allowed to reopen it. That's just the way it is.

You can reopen it by force (script but not always, depends on what rules are applied), but it's not recommended as closing a record can cause some other workflows - closing SCTASK leads to closing RITM and it leads to closing a REQ, thus reopening SCTASK would bring chaos - and notifications etc... 

Can the DPR prevention be related to this? What do you think?