Preview and Troubleshoot
See exactly what a viewer receives, and fix a policy that is not resolving
Security preview answers one question: if this person opened a dashboard right now, what would they see? It resolves a real viewer against your saved policies without sending them anything, so you can check your work before a customer does.
Open it from the project's Security page, choose a connection and a viewer, and run the preview.
Reading the result
A preview either resolves or it is blocked.
Resolved means Semaphor worked out exactly what this viewer gets. The result shows you:
| Section | What it tells you |
|---|---|
| Rules applied | Every filter this viewer's queries will carry, each with its Rule expression |
| Values used by rules | Each parameter's value and where it came from |
| Other security settings | Connection and schema security, when the policy includes them |
Values used by rules is usually the section you want. It names the source of every value, so when a viewer sees the wrong data you can tell at a glance whether the value came from their own assignment, their tenant's, the all-tenants baseline, the policy itself, or the signed token. When a narrower value overrode a broader one, it shows you the value it replaced.
Blocked means Semaphor refused to produce a filter it could not fully work out. Nothing is enforced with a partial policy, and nobody sees unfiltered data. The What needs attention section explains what happened, and How to fix gives you the actions that would resolve it, each linking to the policy or assignment to edit.
"Not active" is not a failure
A preview can resolve successfully and still apply no filters, because this viewer has no assignment for the policy. That is a normal state, not an error, and Semaphor says so rather than showing you an empty result.
It is worth checking deliberately. A brand you have not assigned yet sees unfiltered data from that connection, which is usually not what you want in production. Preview a viewer from an unassigned brand and confirm the outcome matches your intent.
When a viewer legitimately sees nothing
If a parameter is set to Return no rows and nobody supplied a value, the preview resolves and reports that the affected rule denies every row from the tables it matches. The dashboard will load and be empty.
This is the designed outcome, not a fault. It usually means a customer has been given the policy but not yet given their values, so the fix is to add the value to their assignment rather than to change the policy.
Rules from other sources
Two sections appear only when they apply, and both are shown separately so an otherwise empty result is never mistaken for "no row security at all":
- Previous-format row-level rules appear for a connection still using the legacy security mode. Those rules keep their existing behavior.
- Token-provided row-level rules appear when the signed token carries row filters of its own, rather than values for a saved policy.
Checking from a dashboard preview
When you preview a dashboard as one of your customers, Semaphor checks each connection the dashboard queries. If a check comes back blocked, it offers Review security resolution, which opens Security preview with the same customer and connection already selected.
Two things are worth knowing about that check:
- The request id shown belongs to the security check itself, not to an individual card's query. Quote it when you contact support and it will identify this check.
- The check looks at the policy, not at any particular query, so it can tell you that a policy will not resolve but cannot confirm how a broad rule applies to a specific card. To verify that, run a preview that names the tables the query touches.
If several connections are blocked, fix the one reported, reload, and continue until every connection resolves.
Common situations
A required value is missing. Somebody has to supply it and nobody did. Either add the value to the applicable assignment, or, for a token-owned parameter, have your backend include it when it mints the token. If an empty result would be acceptable, switching that parameter to Return no rows avoids the error.
A value was supplied by the wrong source. An assignment is carrying a value for a parameter the policy fixed or the token owns. Decide which is correct: remove the assignment value, or change the parameter's source in the policy. These have different security meanings, so Semaphor asks you rather than picking one.
Two assignments at the same scope disagree. Duplicate records for the same customer are supplying different values. Semaphor will not choose between them. Remove or correct one of them.
A policy was saved in an older format. The policy needs its parameters declared in the current format before it can be used. Open it and re-author the parameter settings. Until then the policy is treated as active but blocked, so nobody receives partial protection.
A viewer sees more than expected. Confirm they actually have an assignment. An unassigned viewer receives no filters from that policy.
Next steps
- Set Up Row-Level Security -- create and assign policies
- How Row-Level Security Works -- sources, precedence, and fail-closed behavior
- Automate with the API -- run the same checks programmatically