The security dashboard can't evaluate the "when" conditions on custom Privacy Rules. This means it may flag rules that are actually secure — a false positive. The steps below help you determine whether a flag is a real risk or can be safely dismissed.
Step 1 — Evaluate the Privacy Rule's condition.
Review the "when" condition on the flagged rule. If it's specific enough that only users who should legitimately have access could satisfy it (e.g., role-based access), the field may be safe to leave as-is and the issue can be dismissed.
Step 2 — Check where the field is used as a constraint.
Use the App Search Tool → search by "Uses constraint field", filtering by the relevant Type name and Field name. Click through results to see where the field is used.
No results returned, or all results point to backend workflows with "Ignore privacy rules" checked, backend custom workflows triggered by other ignore-privacy workflows, or database triggers → you can safely uncheck the "constraint" checkbox for that field.
Results returned → review them alongside the flagged rule and choose one of the four options below.
The four remediation options when the field is used as a constraint:
Disable the "constraint" permission — if the constraint isn't necessary for the app's functionality.
Leave as-is — if the constraint is necessary and the user accepts that the value may remain inferable through constrained searches.
Move the logic to a backend workflow — implement the search in a backend workflow with "Ignore privacy rules" enabled, then uncheck "constraint" on the rule.
Refactor the schema — introduce a separate non-sensitive field (e.g., a boolean) to serve as the constraint, so the sensitive field no longer needs to be constrainable.
⚠️ Slug fields: If the flagged field is used as a page slug, unchecking "constraint" may break page routing. Take extra care.