Data access rules let administrators limit which records a group of users can see or change — not just which areas or pages they can open (Premium subscription only). This is how you make sure, for example, that case workers only see their own clients, or that one campus only sees its own donors.
This is an administrator feature. If you just want to find records for yourself, use filters and segments instead — see Finding Records with Filters.
To control which areas and pages staff can open (sidebar modules, view vs edit), use User Groups: What Staff Can Open and Change. Data access rules sit on top of that and narrow which rows those people can reach.
Your organization must subscribe to the CoolFocus Premium package to access this feature. Only administrators can view, create, edit, or delete data access rules. Non-admin users cannot reach this area, even through direct links or the API.
They use the same kind of conditions, but they do very different jobs:
• A segment is a view you choose in order to narrow a list for yourself. It never hides anything you are allowed to see.
• A data access rule is applied automatically by the system to everyone in a user group. It actually limits what those users can see or do — they cannot turn it off.
• Which records — the entity type it applies to (for example Clients, or Donors)
• Which users — the user group the rule governs
• What they can do — view, edit, delete, or merge. A rule can allow just viewing while blocking edits, for example
• The conditions — the same field and related-record conditions used in filters, combined with match-all or match-any
• Priority — when more than one rule could apply, priority decides the order
Conditions can include placeholders that fill in automatically for whoever is signed in, so one rule covers a whole group:
• {{CURRENT_USER_ID}} — the signed-in user (for example, “records this user owns”)
• {{CURRENT_USER_CONTACT_ID}} — the contact record linked to the signed-in user
• {{TODAY}} — today’s date, with {{TODAY-30}} / {{TODAY+30}} for relative dates
Example: a rule on Cases for the Staff group, with the condition Created By is {{CURRENT_USER_ID}} and view only, so each staff member sees only the cases they created.
Use the preview / test option to check which rules apply to a given user for a given record type before you rely on them. It is easy to lock people out of records they need, so preview first, then roll out.
• Administrators bypass data access rules — they can see everything, by design
• Rules are enforced everywhere records are listed, so a restricted user gets a consistent view across the system
• Start narrow and loosen, rather than the reverse — it is safer to grant more access than to discover something leaked
• User Groups: What Staff Can Open and Change — controls areas and pages; data access rules control individual records
• Finding Records with Filters
• Saving & Sharing Segments
