The approval chain that outlives the approver
Most ServiceNow access request catalog items resolve their first approval through one field, the requester's manager. It's the default behavior out of the box, and it's an easy box to check when you're building a catalog item under deadline. The problem shows up months later, when that manager takes a job somewhere else and the position sits open for six weeks while the department figures out backfill. Every request that would have routed to that manager now points at a deactivated sys_user record, and the approval task sits in a Requested state with no one watching it.
I've seen this stall a two hundred person access catalog for the better part of a quarter. The requester doesn't know why nothing is happening, so they open an incident. The help desk agent handling that incident has no authority to approve access, so they reassign the approval task to whoever seems close, often the requester's skip level or a random member of the platform team, just to clear the queue. That reassignment becomes the approval on record, and nobody involved actually evaluated whether the access made sense.
The fix is to stop routing approvals to a person's name and start routing them to a role or a group tied to the entitlement itself. If a catalog item grants access to a system, someone in the business who owns that system should sit in the approval chain regardless of who the requester's manager happens to be that week. Build a real escalation path too, a defined number of business days before an unanswered approval bumps to a backup approver, not an open ended wait for a workflow to notice. The CMDB ownership fights that erupt when nobody can say who owns a system show the same pattern, just scoped down to a single catalog item.
Access grants with no expiration never get revisited
Native ServiceNow role and group assignment tables don't expire on their own. Once a catalog item's fulfillment step adds a user to sys_user_has_role or drops them into a group, that assignment holds until someone deliberately removes it. If the request form doesn't ask for a duration or an end date, the system has no reason to ever ask again whether the access still makes sense.
The failure mode I run into most often is the fixed term project. A contractor gets Salesforce and VPN access for a ninety day engagement. The engagement ends on schedule, the contractor moves on, and nobody files an offboarding request because the contractor was never a full employee with an HR termination event to trigger anything. Fourteen months later a security audit turns up an active account with no recent logins tied to a person who no longer has a badge. The system did exactly what it was built to do. The catalog item simply never asked until when the access should last.
Make expiration a required field on the request form, not an optional one buried under a notes text box. Give it a sensible default, ninety days for contractor access, a year for standard employee entitlements, and let the requester extend it with a reason rather than have it default to permanent. Every dormant grant that survives past its purpose is an unused license and a compliance question you don't want an auditor to ask first.
One catalog item trying to serve every requester
Building separate catalog items, one for read only report access and another for full admin rights, takes real design time, and most teams building a catalog under a deadline skip straight to a single item instead. The one item ends up with a role picker listing every profile in the org, and the approver, faced with reviewing a dropdown they don't fully understand, approves whatever the requester selected because pushing back would mean learning a system that isn't theirs to own.
I watched this happen with a NetSuite catalog item that had a single access level variable with four choices and a free text justification field nobody read closely. Ninety percent of requests came in for standard user, but the fulfillment task, written once and never revisited, granted the same saved search and approval limit permissions no matter which option got picked. The catalog item looked precise. The provisioning behind it wasn't.
If splitting into narrower items isn't realistic right now, the minimum fix is making the specific entitlement a required, structured variable instead of free text, and wiring the fulfillment workflow so it grants only what that variable specifies. Every catalog item is an operating contract between the requester, the approver, and whoever has to explain the grant later, and an item that can't say precisely what it handed out breaks that contract before the recertification cycle even starts.
Recertification that catches something instead of confirming everything
A recertification campaign that emails every access holder asking them to confirm they still need access, then treats silence as confirmation, checks a box without doing the underlying work. I've sat through audit debriefs where the recertification evidence was a spreadsheet of two hundred rows and a hundred and ninety eight rows marked approved by default because nobody replied.
A recertification cycle worth running sends the review to the business owner of the catalog item, not the platform team, on a fixed schedule, quarterly for high risk entitlements like financial approval limits, every six months for standard application access. The task should show the owner what the person can actually do with the grant and, where you can pull it, when they last used it. Silence past a defined deadline, five or ten business days, should escalate once and then default to revoke, not to approve.
This only works if someone owns the outcome. Pair recertification with a dedicated security review on the highest risk items and the cycle actually removes access instead of producing paperwork that says a review happened.
A review date for the access nobody thinks is temporary
Expiration dates handle the access you know has a shelf life, a contractor engagement or a temporary elevated permission granted for a migration. They don't handle the access that feels permanent because it's tied to a job function, like accounts payable approval authority or a standing admin role on the CRM.
That access still needs a checkpoint, just not a hard cutoff. Give every grant a next_review_date field alongside expiration_date, default it to a hundred and eighty days out, and have a scheduled job surface anything past due to the item's owner automatically rather than waiting for an annual audit to notice. The goal isn't to revoke the AP approver's access every six months. The goal is to make someone confirm on record that the role, and the person in it, still match.
Grants that drift for years without anyone re-checking them are exactly how automation owners lose the thread, one small unreviewed exception at a time, until nobody can reconstruct why half the access list looks the way it does.
An owner who isn't the platform team
Most catalog items list an owner field, and most of the time it gets filled in with whichever platform administrator built the item, or a generic queue like IT Service Delivery. That's an owner for the workflow, the person who fixes it when a variable breaks, not an owner for the access itself, someone who can say why the entitlement exists and who should reasonably hold it.
A NetSuite approver access item should list the controller or the finance systems lead as its business owner, not the ServiceNow admin who built the request form. That person gets pinged for recertification and is the name an auditor can actually interview about why the access exists. Standing up that ownership structure doesn't require a large team. A small center of excellence with clear accountability per system covers most mid sized catalogs.
Pull your own catalog and check the owner field on every item that grants access to a financial system or an HR system holding production data. If most of those fields list a queue instead of a person's name, that's the first thing to fix, before you touch a single approval workflow.
