CoolFocus access answers two simple questions:
What can this person see?
What can this person do?
Most of that is managed with user groups. Put people into groups that match real jobs — finance staff, client services, event staff, volunteer coordinators — instead of setting access one person at a time.
This article covers which areas and pages staff can open, and whether they can view, add, edit, or delete there. If you also need to limit which individual records someone can reach (for example, only their own clients, or only one campus’s donors), that is a separate feature — see Data Access Rules: Limit Which Records Staff Can See.
Area access — A person may need access to an area before they can open the pages inside it. For example, someone may need access to Giving before they can work with donors and contributions. Area access is what shows (or hides) module icons in the sidebar, such as Give, Care, or Scheduler.
Page access — Inside an area, a person may be able to view a page without being able to add, edit, or delete. For sensitive pages, your organization can limit who can make changes.
A finance user may need to view donors, contributions, payments, and payouts.
A client services user may need to work with clients, visits, requests, and referrals.
An event user may need to manage registrations, tickets, sponsorships, and tables.
When someone needs new access, first ask what job they are trying to do. Then adjust the smallest amount of access needed for that work.
Open Settings, then go to Security and choose User Groups.
A user group can control:
Which areas of CoolFocus a person can open (module icons in the sidebar, such as Give, Care, or Scheduler)
Whether they can add, edit, delete, or view information inside those areas
Whether they can use sensitive tools
Whether they can manage settings
Administrators are different: a user marked as Administrator on the Users page can open every module your organization is licensed for, even if their user group does not list every module. User groups mainly control access for non-administrator staff.
When you open a user group, the edit screen has an Activity Type Access tab alongside Permissions (and AI Data Access, if your organization uses that). Use it to control which restricted activity types this group can see and work with on notes, calls, tasks, and attachments.
Only activity types that have been marked restricted appear on this tab — unrestricted types are always visible to everyone and have nothing to configure here. For each restricted type, you can grant:
View — lets the group see activities tagged with this type
Create — lets the group tag new activities with this type
Edit — lets the group update or re-tag existing activities with this type
Create and Edit both require View — if you turn off View for a type, Create and Edit are cleared automatically. A restricted type with no grant at all is hidden from that group by default: they will not see it in pickers or filters, and any activities already tagged with it disappear from their grids and timelines.
Administrators always see and can work with every activity type, restricted or not, regardless of what is granted here.
Some record types do not just live on their own screen — they also show up as a summarized entry on a related record’s timeline (for example, on a client’s or case’s timeline). Seeing that summarized entry is controlled by the View permission for that record type itself, not by whatever permission controls the screen the timeline is on.
This currently applies to the timeline entries for:
Pregnancy Test results
STI Test results
Benefits Received
Needs Met
Requests
Service Received
Appointment reschedule history
BrightCourse learning activity (activities and assignments) — see BrightCourse points and learning data
If a user group lacks View on one of these entity types, that record type’s entries are simply left out of the timeline for members of that group. The rest of the timeline (notes, tasks, calls, attachments, and any entries the group can see) still shows normally. Grant View on the underlying entity type, from the group’s Permissions tab, to the groups who should see that kind of entry summarized on a client, case, or other related record’s timeline.
Many organizations need to make sure staff without medical training cannot see clinical results (pregnancy test, ultrasound, STI, vitals, and similar), while still working with the rest of a client’s case. To do that:
Put medical staff and non-medical staff in separate user groups rather than one shared group.
Set the group’s Visits permission based on what that group should see. The visit workspace’s built-in chart tabs (Pregnancy Test, Ultrasound, STI Test, Vitals) are part of the visit record itself, not a separate chart type, so they follow the group’s overall Visits permission — there is no separate switch just for “hide Ultrasound results.” A group needs View on Visits to see these tabs, the visit’s workspace files, and workspace counts, and Update on Visits to turn on a built-in chart tab for a visit.
A performed pregnancy test or STI test can also appear as a summarized entry on the client’s and case’s timeline, separate from the visit workspace tab. As described above, seeing that timeline entry is controlled by its own View permission for that activity, not by the group’s Visits permission. Grant that permission only to the groups who should see pregnancy test or STI results summarized on client and case timelines.
For chart types that do have their own entity (custom charts, and any cloned or custom versions of a built-in chart), restrict those individually per user group from the group’s Permissions tab, the same way you would restrict any other entity type.
Test the setup with a sample account in each group: confirm the Charts menu/grid, the visit workspace tabs, the case Charts tab, the client and case timeline, the care snapshot / review queue panel, reports, and saved segments all show only what that group should see.
This applies everywhere chart and visit data can appear, not only the main grids — including the API. A user who lacks the needed permission now gets a clear “Access restricted” message in the app instead of a panel that silently appears empty, so a permission gap reads as a permission problem rather than as missing data.
See Forms vs. Charts for more on how built-in versus custom chart access works.
Changing a user group can affect everyone in that group. Review the group members before making a major change. If you restrict an activity type before granting it to the staff who need it (for example, a medical or legal note type), those staff will temporarily lose access to their own notes — grant access to the right groups first, then mark the type restricted.
Use clear group names that match real job responsibilities. This makes it easier to understand why someone has access later.
When someone needs new access, ask what job they are trying to do, then grant the smallest amount of access that fits that work.
If someone cannot see a module icon (for example Give), use the troubleshooting checklist in Troubleshooting: A module icon is missing from the sidebar before changing multiple groups.
Data Access Rules: Limit Which Records Staff Can See — limit which individual records a group can reach
