Hey everyone, diving into a Sprinto snag that's really thrown a wrench in our compliance sprint this week. We're mid-onboarding, trying to get our infosec policy suite fully approved, and we've hit a total workflow dead-end. The policy is just... stuck. It's been sitting in "In Review" for days, and none of the assigned approvers are getting the nudge to actually go in and approve it. The dashboard says everything is pending, but there's no apparent way to un-stick it.
Here's the exact scenario:
* We created a new "Data Encryption Policy" (pretty standard stuff).
* Assigned a three-person approval chain: Head of Engineering, CTO, then finally our Head of Compliance.
* Workflow triggered correctly, moved to "In Review" for the first approver.
* And then... silence. No email notifications arrived for any of them, even after checking spam. Manually sending reminders from within Sprinto seems to do nothing—the action buttons feel inert.
What I've tried so far:
* Verified all user emails are correct and accounts are active.
* Tried reassigning the first step to a different person.
* Looked for any "escalation" or "override" settings but came up short.
* Even attempted to clone the policy and start a new workflow, but hit the same wall.
It feels like the workflow engine is in a suspended state. Has anyone else wrestled with this? I'm particularly curious about:
* Is there a hidden "timeout" setting that might be causing this?
* Could it be permission-related, even if the UI shows the users as valid approvers?
* Is our only nuclear option to contact support and wait, or is there a database-state trick (like marking a draft and republishing) that might kick it back to life?
I love experimenting with these platforms, but this blockage is a real test of patience! The ROI on our compliance tool hinges on these automations actually working, so I'm eager to hear if the community has a fix.
🔥
Try everything, keep what works.
Ah, the classic "In Review" black hole. I've seen this exact scenario play out more times than I care to admit with approval workflows. Everyone swears the notifications are sent, but the logs tell a different story.
You said you verified the accounts are active, but have you checked if the notification service itself is throwing errors for those specific users? Sometimes it's not the account, it's a silent failure in the queue for a single email address that gums up the whole chain. That would explain why manual reminders do nothing - they're just re-adding a request to a broken queue.
Try creating a dummy policy with a single, brand new approver email you control. If that works, the problem is buried in the configuration of one of your original three. If it also fails, then you've got a platform-wide notification failure and you can stop wasting time on user-level fixes.
cg
Good call on testing the notification queue itself. I had a similar silent failure once, but it was tied to a group email address. The system showed it as a valid user, but the approval link in the email would never resolve for anyone on the distro list.
When you say to check the logs for errors, do you mean the audit logs inside Sprinto, or are you thinking of something at the infrastructure level like their SMTP service?
Classic case of notification fatigue. Everyone's so overloaded they've become email ghosts.
Check the audit logs for "workflow action" events. If there's nothing, the queue is dead. But if you see attempts, you're chasing delivery. Try a dummy test with just one internal person who you know gets other Sprinto alerts.
Also, never do a three-person linear chain. That's just building your own approval bottleneck. Parallelize the first two at minimum.
Deploy with love
Parallel chains are definitely the better default, but sometimes sequential approval is required by the policy itself. The compliance framework dictates the order, not Sprinto's configuration.
However, even with a mandated chain, the first two approvals could still be parallel if they're from separate departments. The true bottleneck is usually the final, singular authority, like a CISO. That's where the real logjam happens, not in the initial stages.
null
Oh, that's a great point about the framework dictating the order. I hadn't considered that.
So even if Sprinto *can* do parallel, we might be forced to use sequential to meet an actual compliance rule? That changes how I'd set things up. Do you know if the system logs which requirement is forcing a sequential flow? It'd be helpful to double-check that.