ServiceNow Approval Workflow Best Practices: 3 Default Behaviors to Fix Before Go-Live

Hey everyone, it’s Nowmon here.
Today I want to write about some issues with ServiceNow’s approval feature — arguably one of the most important capabilities the platform has to offer.

What Is the Approval Feature?

The approval feature in ServiceNow is a core capability that can fairly be called one of the platform’s most critical functions.

Since ServiceNow is a product designed to streamline internal business workflows, approvals are an indispensable part of any workflow implementation.

Approvals also play a key role in ensuring corporate governance — providing an audit trail that confirms sign-off from the appropriate authority.

That said, ServiceNow’s approval feature has several issues that, in my view, pose real problems for enterprise use.

Issues with ServiceNow’s Approval Feature

There are three key issues with ServiceNow’s approval feature:

① Users with the Approver Role Can Delete Approval Records

I created an approver user, assigned the approver_user role, and navigated to a record with a pending approval request.

As you can see in the screenshot below, a Delete UI action is displayed — and clicking it actually deletes the approval record.

From an audit standpoint, approval records should never be deletable. Beyond compliance concerns, this also forces developers to account for unnecessary edge cases — like what should happen if an approval record gets accidentally deleted mid-flow.

You could work around this operationally by instructing users not to delete records and requiring re-submission if it happens, but in my opinion, deletion of approval records simply should not be possible at the product level.

② Approvers Can Set Statuses Beyond “Approved” and “Rejected”

Out of the box, ServiceNow provides two UI actions for approvals: Approve and Reject.

When approvals are handled through the portal or mobile app, these two actions are generally sufficient. However, the Next Experience UI is a different story.

For some reason, the Status field is freely editable by the approver, allowing them to select values like “Not Required” or “Cancelled” — statuses that serve no purpose in a standard approval workflow.

If one of these unintended statuses gets selected, you’re forced into yet another round of unnecessary design decisions about how the flow should behave.

Statuses like “Cancelled” or “Not Required” are really intended for system-driven scenarios — such as when a request is withdrawn, or when one approval out of multiple approvers is sufficient and the remaining requests should be automatically resolved.

③ Approval Status Can Be Changed Even After an Approval Action Is Taken

The screenshot below shows an approval record after the Approve button has been clicked — the record is in an approved state.

Yet, as you can see, the Status field is still active and the Update button is still visible. (And yes, the Delete button is there too…)

There are no Business Rules in place to prevent this, either — so it’s entirely possible to approve a record and then switch it to Rejected after the fact.

And yes, deletion is still possible at this point too.

Whether post-approval status changes are acceptable from an audit perspective is a conversation in itself — but the bigger question is whether this kind of behavior is acceptable for a platform that has workflow at its core.

I’d be curious to know how other ServiceNow customers and partners are handling this in practice.

While these issues can be addressed relatively easily through ACL configurations or table-level customizations, I personally view them as product-level defects rather than just gaps to work around.

Given the potential impact during upgrades and the effort required to maintain custom fixes, I genuinely hope ServiceNow addresses these as a platform-level fix.