Access permission drift monitor for warehouse and reporting tools
Problem
When a governing body brings a new club or academy into its data estate, someone adds a group in the identity provider, someone else updates the warehouse's row-level security policy, and a third person edits sharing rules in the reporting workspace. These three edits happen on different days, by different people, and nothing checks that they still agree with each other. The usual failure is not a breach anyone notices immediately. It is a data engineer discovering months later that an academy's registration records have been visible to every club in the group, or a newly onboarded club's analyst raising a ticket because their reporting workspace shows nothing at all. The entity tag meant to hold parent and child access together drifts quietly, and the only way anyone finds out is by being told.
Product idea
A monitor that reads the group and role definitions from the identity provider, the row-level security policy definitions from the warehouse, and the sharing rules from the reporting workspace, and compares them against a single list of entities the organisation is supposed to be serving. Where a club or academy exists in one system and not the others, or where its warehouse policy and its identity provider group disagree on membership, it flags the mismatch and alerts the named data owner before a scheduled report reaches the wrong audience. It does not change any permission itself. It states the mismatch, who owns each side of it, and how long it has been open, and leaves the correction to whoever owns that system.
Who it is for
Data engineers and heads of data who maintain the entity tag across systems, CRM and CDP managers who own reporting workspace sharing rules, and heads of IT accountable for access when a regulator asks.
Possible first version
A scheduled job pulls group membership from the identity provider, row-level security policy definitions from the warehouse's own metadata tables, and workspace sharing rules from the reporting tool, compares them against a manually maintained entity list, and produces a status view of matches and mismatches with a named owner per entity. Mismatches older than an agreed threshold escalate by email. Version one covers one warehouse and one reporting tool. It does not cover CRM-native sharing rules beyond the top-level entity property, and it makes no automatic change to any permission.
- Build classification
- Platform module
- Rough effort
- 10-week first phase
- Roles involved
- Head of data, Data engineer, Head of IT, CRM and CDP manager
- Relevant to
- Federation / governing body, League office, Professional club
- Systems in play
- Identity providers and single sign-on, Cloud data warehouses and lakehouses, Business intelligence and visualisation tools, CRM
- Product framing
- Monitor
Questions we get asked
What do we need to have in place before this is useful?
It needs three things already running: an identity provider with a group per entity, a warehouse with row-level security policies keyed to that same entity property, and a reporting tool with workspace-level sharing. If any of those three does not exist yet, this monitor has nothing to compare and is the wrong thing to build first. It assumes the multi-tenant pattern, one entity tag applied consistently across identity, warehouse and reporting, is already the design. If it is not, that is the decision to make before this.
Does this replace the access management we already do inside the warehouse and the reporting tool?
No. Row-level security still lives in the warehouse and sharing rules still live in the reporting tool. This only reads both and tells you where they disagree with the identity provider. Nothing here provisions, revokes or edits a permission. The correction still happens in the system that owns that permission, made by the person who already has rights to change it. What this adds is the comparison nobody was previously running, not a replacement for the systems doing the enforcing.
Our access hasn't broken so far without this. Why add it now?
Because the failure mode is silent by design. A mismatched permission does not throw an error, it just sits there granting or withholding access that nobody checked. The moment this tends to matter is when a new entity joins, an academy or a new club, because that is when the three systems are most likely to fall out of step with each other. If entities are added rarely and by one careful person, the risk is lower and this is less urgent.
What does it deliberately not cover?
It does not manage individual user permissions, only the entity-level pattern of which group maps to which warehouse policy and which reporting workspace. It does not cover CRM-native sharing rules in version one, only the top-level entity property. And it does not fix anything automatically, because auto-correcting a permission without a person confirming which side was wrong is how the wrong side wins by default.
Is this your workflow?
Tell us one sports workflow that still runs on paper, spreadsheets, WhatsApp or an outdated system. We will map it and show you what a simpler product looks like.
Tell us about itMore in Data platform & engineering
- Attendance reconciliation report across ticketing and till systemsA reconciliation report that turns a ticketing export and a till export for the same fixtures into one defensible attendance and spend figure, with the variance between them shown and explained.
- Chat intake assistant that triages ad hoc data requestsA chat assistant that answers a data request instantly when the metric already exists, and turns anything new into a structured, tracked ticket instead of a message lost in a chat thread.
- Consent and deletion request tracker across the vendor stackA workflow tool that turns a consent revocation or deletion request into tracked, assigned tasks across every downstream system, replacing the spreadsheet checklist and email chain nobody can prove was completed.