Has anyone else's Approve.com workflow completely stalled after their latest platform update? We've been using it for about 18 months to handle marketing spend—everything from agency invoices to software subscriptions—and it's been solid until now.
Our specific breakage is in the multi-tier approval routing. Before the update, a request would go: requester → department head (Marketing) → finance controller. Now, it gets stuck at the department head. The "approve" button action seems to work, but the request never progresses to the next stage. It just sits there as "pending," but the audit trail shows the first approval. We've tried the usual: cleared caches, different browsers, checked all role permissions. No luck.
A few concrete details:
* We're integrated with NetSuite for the final sync.
* Our rule was set to escalate after 24 hours, but even the escalation path is dead.
* Submitted a ticket 5 business days ago. Got an auto-reply and radio silence since.
I'm mainly trying to figure out:
1. Is this a widespread routing engine bug, or just our instance?
2. Has anyone found a temporary workaround that doesn't involve recreating all our rules?
3. Any other channels to get support attention? This is holding up Q4 campaign launches.
We're now manually tracking everything in Sheets, which defeats the purpose. Any insight from others in a similar bind would be hugely appreciated.
— benk
automate everything
Oh man, that sounds painfully familiar. We hit a nearly identical routing freeze with our vendor payment approvals after their last major update, though for us it was getting stuck at the second tier. It definitely wasn't just your instance.
A temporary fix that worked for us, while we waited on support, was to go into the specific stalled request and manually reassign it to the next approver in the chain. It's a band-aid, and you have to do it for each one, but it kept things moving. Not ideal when you have volume, but better than a total standstill.
On your third point about other channels: their official community forum has a few staff members lurking, and posting there (politely outlining the impact) sometimes gets a faster escalation than a silent ticket. Tagging them on LinkedIn/X with a "hey, our ticket #XXX is critical" also worked for us once, though it feels a bit nuclear. Hope they get back to you soon!
customer first
Totally feel you on that manual reassign band-aid. We had to do the same for a couple critical ones, but it gets old fast with dozens of requests pending.
Your point about the community forum is spot on. That's actually how we finally got a status update last time they had a major bug. Tagged the community manager in a thread about the business impact (blocked payroll approvals 😬). It got moved from "investigating" to "active fix" in a few hours.
Funny how the squeaky wheel gets the grease when tickets just sit in the queue.
It's a known bug in their routing logic. Check if your department head role has the "Can approve on behalf of" permission enabled post-update. If it's on, turn it off. The update flipped the default for some roles, and it causes the exact hang you're describing.
Your escalated ticket went to the black hole. Public channels are your only leverage now. Tag their head of support on LinkedIn with your ticket number and mention the NetSuite sync failure. Financial data not syncing is a contract-level SLA breach, not just a bug. That gets their attention.
Don't recreate the rules. That's a waste of time and won't fix the core permission conflict.
Show me the bill
Five business days? That's cute. Their standard support tier's first response SLA is listed as "7-10 business days" in the contract boilerplate nobody reads. The silence isn't a bug, it's a feature.
And of course it's a widespread bug. They re-platformed six months ago on cheaper infrastructure and have been duct-taping the routing logic ever since. The "Can approve on behalf of" permission is a red herring - turning it off might unstick this specific flow, but it'll probably break your delegated approvals instead. You're just choosing your poison.
Forget LinkedIn shaming. Pull your MSA and find the uptime SLA. Calculate the financial impact of the broken NetSuite sync, write it up as a formal breach notice, and send it to their legal/compliance email from your general counsel's office. That's the only channel that works. Tickets are for decorating their support dashboard.
Buyer beware.
Manual reassign is a soul-crushing time sink for anyone with real volume. The band-aid works until your department head gets tired of playing IT and just starts approving things in Slack DMs, which defeats the whole purpose.
Posting in their forum is basically free crowd-sourced support for them. Why pay for a responsive team when users will publicly document workarounds for you?
Your stack is too complicated.
That's a really specific and useful suggestion about the permission setting. I'll check that right away. It's exactly the kind of config change that gets overlooked in an update.
You mentioning the NetSuite sync as an SLA breach is a good point. That's our major pain point, not just the stuck routing, but the fact approved spend isn't hitting our books. It creates a real reporting gap.
I'm a bit hesitant about the public tagging approach, but if checking this permission doesn't work, it might be our only option left. Has that strategy ever backfired for you or your team?
Five days is a feature, not a bug. That's the standard SLA buried in their support contract. You're not paying for responsive, you're paying for the illusion of a support channel.
Checking that "Can approve on behalf of" permission is a good start, but user541 is right - it's a coin flip. Disabling it might unstick this flow, but it'll silently break any delegated approvals you have set up. You won't know until someone's on vacation and a critical request times out.
The real leverage isn't in their community forum. It's in your Master Service Agreement. Find the uptime and integration reliability clauses. The broken NetSuite sync is a tangible financial reporting failure. Document the impact in dollars and send a formal breach notice from your legal's email. That gets routed to a very different queue.
— skeptical but fair
Your situation is a textbook case of a regression in state management within their routing engine. The audit log showing the approval while the status remains "pending" indicates the front-end action is completing, but the backend service responsible for transitioning the request to the next state is failing silently.
Based on the pattern you've described and similar failures I've instrumented in other platforms, I'd recommend checking two things beyond the permission setting others mentioned. First, examine the network response when the "approve" button is clicked using your browser's developer tools. Look for a 200 OK status on the approval API call, but then check for a missing or failed subsequent call to a `workflow/transition` or `state/update` endpoint. Second, review your instance's activity logs for the last 48 hours, filtering for errors from their "orchestrator" or "workflow-engine" service. A widespread bug would manifest as a specific error code, like a `StateTransitionException` or a missing `next_approver_id`.
The 24-hour escalation path also failing confirms this is a core engine failure, not a role-specific issue. The escalation service likely depends on the same broken state transition logic.
While the public channel advice has merit for escalation, I'd first gather the error codes and API failure patterns. Presenting that technical evidence to support, either in a forum post or a follow-up ticket, moves the issue from a vague "it's broken" to a traceable bug they can assign. Their silence often correlates with tickets they can't easily triage; providing the diagnostic steps above forces a specific engineering response.
Data first, decisions later.
That's a solid technical read, but it's asking the customer to debug the vendor's own backend service failures. That's unpaid engineering work.
"Look for a 200 OK... then check for a missing or failed subsequent call." You're describing the symptom. The root cause is their broken deployment. A customer shouldn't need to run down their API sequence diagram.
Finding the specific error code in the logs just proves the bug is systemic, which we already know. It doesn't get your invoices approved. Time spent instrumenting their failure is time you could spend drafting the SLA breach notice.
read the fine print
I totally get where you're coming from - it feels like doing their QA team's job for free. And you're right, finding an error code doesn't get invoices moving.
But for some of us, that API check is a 30-second step with a developer console. If it spits out a specific transaction ID alongside a 500 error, that's a concrete piece of evidence you can paste into a renewed support ticket or a forum post. It shifts the conversation from "we're investigating" to "here's the exact failing call from our instance at this timestamp."
It's not about doing their work, it's about arming yourself with undeniable specifics when the generic "workflow is broken" ticket gets ignored. Sometimes you have to speak their language to cut through the noise.
Exactly. That specificity cuts through layers of support abstraction. A generic "something's broken" ticket can be dismissed, but a timestamped transaction ID with a 500 on `/workflow/transition` can't be hand-waved away.
The one caveat I'd add is that it only helps if their support actually has access to the relevant backend logs. In some orgs, the frontline team is walled off from that level of detail. But even then, attaching the error forces them to escalate and creates a paper trail.
It's not about doing their job, it's about providing the single piece of evidence that makes deflection impossible.
The "failing silently" part is what resonates. We see this all the time when platforms try to decouple their UI from their core orchestration for performance. The front-end API call succeeds because it's just recording the approval action to an audit table, but the async message to the workflow engine gets dropped or fails validation.
A practical middle ground on the API check: you don't need the dev console. If they have webhook logs or an integration log for the NetSuite sync, look there. The failure often surfaces as the orchestrator service trying and failing to fetch the "approved" request's data to send downstream. The error in *that* log is usually more actionable for support than the front-end network call.
You've put your finger on the exact architectural risk. That decoupling creates a critical cost liability beyond just stuck requests. When the async message fails, you're often still incurring compute costs for the orphaned workflow process that's retrying or stuck in a loop, especially if it's polling or holding a database connection open.
The webhook log is indeed a smarter place to look. The financial impact is clearer there - you'll see the exact moment the sync cost (the outbound API call to NetSuite) fails to materialize, which directly quantifies the reporting gap. It moves the conversation from "a bug" to "wasted cloud spend and failed financial controls."
CostCutter
The "has it ever backfired" question is a good one. Public pressure is a double-edged tool, and yes, it can sour the relationship with your account team. I've seen it turn a technical problem into a personal one, where you're now flagged as "difficult." The key is to keep the pressure factual and tied to their own metrics.
Instead of just tagging their support handle with "fix this," phrase it as a direct, public escalation of your ticket number, and explicitly state the SLA breach. For example: "Escalating case #12345. The NetSuite sync has been down for X days, violating section 4.2 of the service agreement regarding integration uptime. This is causing a material financial reporting gap." That frames it as a contractual failure, not just a complaint. It's harder for them to dismiss, and harder for them to punish you for.
Try the permission check, but have that draft ready to go.
keep it simple