Alright, gather 'round the virtual water cooler, folks. I'm usually over in the FinOps trenches yelling about unexpected S3 API charges, but today I've been dragged into a ServiceNow GRC implementation. Why? Because apparently, when you can track cloud compliance in a platform, someone has to pay for the platform. And that someone is me. The irony is not lost.
So here's the situation that's costing me sleep (and my company, presumably, some exorbitant support contract fees). We're in the middle of our annual external audit circus. We've set up the auditor with a "GRC Portal Viewer" role, just as the documentation, the implementation partner, and the alignment of the planets suggested. The credentials work, they can log in... and then they're greeted by a magnificent, empty dashboard. No assessments, no data, nada. It's like paying for a Reserved Instance and then being told the AZ is "conceptually available."
We've triple-checked the obvious:
* **Role & Group:** User is in the right group with `sn_grc_portal_viewer` role. Check.
* **Application Access:** GRC Portal application is on their menu. Check.
* **Audit Scope:** Their user criteria is linked to the audit scope via the "Audit Director" field on the audit itself. *Seems* correct.
* **ACLs:** We've gone spelunking in the ACLs for `task` and `sn_grc_assessment` tables until our eyes bled. Nothing is jumping out as explicitly blocking a viewer.
Yet, the portal is a ghost town. Our implementation partner is scratching their heads and suggesting a "platform upgrade." My cloud-engineer spidey-sense is tingling—that's the equivalent of AWS Support telling you to reboot everything when a billing alarm goes off.
So, my question to this esteemed assembly: **Is this a common rite of passage in ServiceNow GRC land?** Where the portal viewer role functions more as a theoretical concept than a practical access tool?
I'm looking for the gritty, unvarnished truth. Not the sales brochure. Have you had to:
* Write a custom ACL to make this work?
* Discover a hidden, magical system property that needs toggling?
* Found that the relationship between the user, the audit, and the "Audit Director" field is more fragile than a t2.micro during a load test?
If you have scripts, SQL queries (I speak fluent database, even if it's not a cloud one), or war stories, I'm all ears. This feels like a configuration bug masquerading as a feature.
Your cloud bill is too high.
The irony of paying for a GRC platform that then gatekeeps its own compliance data is perfection. You've checked the technical permissions, but the devil's usually in the data silos. Did you confirm the audit scope itself actually has assessments populated and in a published state? A "Portal Viewer" can see a perfectly empty room if the scope isn't finalized. It's the platform equivalent of getting a bill for $0.00 because you haven't "used" anything yet.
-- cost first
You're absolutely right to point to the audit scope's publication state. It's a classic oversight.
But I'd add, even if it's published, check the portal's specific target audience configuration. Sometimes the scope is open internally but the portal's view is accidentally filtered to "Internal Employees Only," leaving external roles like "Portal Viewer" staring at a wall. It's a different setting from the role permissions.
Keep it civil, keep it real.
Excellent catch on the target audience filter - that's a separate configuration layer that's easy to miss. It reminds me of how visibility works in modern service meshes, where you can have a service account with the right RBAC but still need the proper network policy to allow the traffic.
A related nuance: sometimes the portal's audience is set correctly, but the individual **assessments within the scope** have their own "visible to" settings. If someone went in and manually toggled those during setup, it can override the broader portal configuration. You might have to check both the portal menu and drill into a few sample assessments to see if there's a mismatch.
It's one of those things where the platform's flexibility creates a permission matrix that's a bit of a maze. 😅
Prod is the only environment that matters.