CoolFocus Security Settings answers two simple questions:
What can this person see?
What can this person do?
Most of that is managed with user groups. A user group is a shared access profile: everyone in the group can open and change the same things in CoolFocus.
You will want to 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.
One group per person. Each user is assigned to only one user group. You cannot stack two groups on the same login. That keeps permissions clear when rules would otherwise conflict. Details and setup tips are in One user group per person below.
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 for the Premium subscription. See Data Access Rules: Limit Which Records Staff Can See.
Why CoolFocus 5 has more permission settings than CoolFocus 3
CoolFocus 3 controlled access with a handful of broad area checkboxes on one profile, so one checkbox could open a whole module and everything in it. CoolFocus 5 splits that same access into five separate layers, so an administrator can grant exactly what a role needs instead of an all-or-nothing area checkbox. That is why CoolFocus 5 shows more individual settings than CoolFocus 3 did.
Module Access decides whether a group can open a module at all, like Give or Care.
Record Permissions decide whether the group can view, add, edit, or delete records inside that module, like clients or donors.
Module admin decides whether the group can manage that module's own settings and setup lists, like appointment types or funds.
Activity Type Access decides which restricted note, call, task, and attachment types the group can see or use.
Data Access Rules (Premium) narrow which individual records within a type the group can reach, like only their own clients.
See User Groups Created in CoolFocus 5 Do Not Grant Access in CoolFocus 3 if your team still uses CoolFocus 3 alongside CoolFocus 5.
One user group per person
Each CoolFocus login belongs to at most one user group. There is no way to add a second group to an existing user.
Why
User groups control many settings at once: which modules appear in the sidebar, whether someone can add or edit records, module settings (Module admin), restricted activity types, and more. If one person belonged to two groups, those settings could disagree.
For example:
A Staff group allows every module and full access to clients.
A Volunteer group allows only limited areas and denies clients.
If the same person had both groups, CoolFocus would have to decide which rule “wins” for every conflict. That gets complex quickly, is hard to explain to your team, and makes it harder to trust who can see sensitive data.
So CoolFocus keeps a simple rule: one person, one group, one clear policy.
How to design groups
Treat user groups as organization policies — profiles of the access you intend to grant — not as tags you pile onto one account.
Name groups after real roles or trust levels (Finance, Client services, Events, Front-desk volunteer).
Assign each person the single group that matches what they should be able to do.
If someone needs a mix of two roles, create a new user group with only the permissions they need. Do not assign both original groups.
Niche one-off groups are fine when a role is truly unique, but start from the higher-level picture of how your organization justifies access to data.
When a role changes, open the person on Settings → Security → Users and change their user group. That replaces the previous assignment.
Administrators are different: The Administrator setting gives a user full access to everything in CoolFocus, regardless of User Group, assigning a User Group to an Administrator is usually unnecessary. However, if an Administrator will approve charts or ultrasounds, or hold a position like Clinical Reviewer, then assign a User Group so that he/she can be selected for those activities.
See also Users.
Seeing an area vs working on a page
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.
Whole modules, not sections inside a record. User group access applies to entire modules, like Care, Give, or Material Support. There is no setting to hide just one section inside a record's overview, such as Points, Tasks, or Calls on a client record. Anyone who can view that record sees all of its sections.
Access examples
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 — usually by updating their one group, placing them in a different group that already fits, or creating a new one.
Where to find it
Open Settings, then go to Security and choose User Groups.
Example: giving a user Inbox and Scheduler access
Inbox and Scheduler are separate modules, so grant access to each one on the group's Permissions tab. Turning one on does not turn the other on.
Open Settings → Security → User Groups and open the group the person belongs to (or create a new one for this role).
Select Inbox in the module list. Turn on Module Access, grant View on the domain or domains the group should text in (Client, Donor, or Volunteer), and grant Add and Edit so members can send replies, not just read conversations.
Select Scheduler in the module list and turn on Module Access for it too.
Save the group, then assign the user to it from their profile on Settings → Security → Users.
Have the person sign out and sign back in. A change to their group does not apply to a session that is already open.
If Inbox settings pages are still missing after this, check whether the person is marked Administrator on the Users page. Some Inbox settings, like the default message type and the secure message invite, are limited to administrators regardless of what the user group allows.
What user groups control
User group settings 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.
Module Access and the "Module admin" checkbox
On a user group's Permissions tab, pick a module in the list on the left. Two controls appear at the top of the panel, above the Record Permissions grid:
Module Access (Allow / Deny): whether this group can open the module at all. This is what shows or hides the module's icon in the sidebar.
Module admin (checkbox): whether this group can manage that module's settings.
The short version:
Module Access = can open the module.
Module admin = can manage that module's setup.
What Module admin gives the group
With Module admin checked for a module, members of that group can:
Open that module's settings pages, both from the gear icon on the module and from the module's entries in Settings. Those entries are otherwise hidden from non-administrators.
View, add, edit, and delete that module's setup records, the configuration lists behind those settings pages (for example appointment types, activity types, funds, positions, and similar setup lists that belong to that module). This is granted directly by the checkbox, so you do not also have to grant those rows in the Record Permissions grid below.
Manage the settings of areas that sit underneath that module. For example, Serve module admin also covers Volunteer Portal settings, and Material Support module admin covers boutique operators.
In the module list on the left, a green dot means the group can open the module and a blue dot means the group is a module admin for it.
What Module admin does not do
It does not make someone a full CoolFocus Administrator. Global administrator is set per user on the Users page, and it is what grants access to every licensed module and to organization-wide settings.
It does not carry over to any other module. Each module has its own checkbox, and module admin on one module never unlocks another module's settings, including Settings > Security (users, user groups, IP access), which is administered separately.
It does not change access to everyday records in that module. Donors, clients, contributions, visits, events, and the rest still follow the Record Permissions grid for that group. If a module admin cannot see or edit records, grant those permissions in the grid.
Module Access and Module admin move together
Module admin only makes sense for a module the group can open, so the two controls stay in sync:
Checking Module admin automatically switches Module Access to Allow.
Switching Module Access to Deny clears Module admin, and the checkbox stays greyed out while the module is denied.
Remember to save the group after changing either control.
Below Module Access and Module admin, the Permissions tab lists the record types that belong to the module you picked, such as Clients, Donors, or Visits. This is the Record Permissions grid referenced throughout this article. For each record type, turn on the actions this group should have:
View: see the record and its list
Create: add new records of this type
Update: edit existing records
Delete: remove records
Grant only what the group's job actually needs. For example, a front-desk group might get View only on Donors, while a finance group gets View, Create, Update, and Delete. A group with no grant at all on a record type cannot see it anywhere, including its own grids, timelines, reports, and segments.
Activity Type Access
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.
Timeline entries follow their own View permission
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.
Separating medical and non-medical staff
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:
Assign medical staff and non-medical staff to 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 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.
What a permission denial looks like
When staff try an action their user group does not allow, CoolFocus now shows a plain "You do not have permission to perform this action" message instead of a generic error screen. That applies fleet-wide, everywhere a group's Permissions tab blocks View, Create, Update, or Delete on an entity, so a permission gap reads clearly as a permission problem and staff know to ask an administrator for access rather than reporting a bug.
Email and print job history can inherit View from the module
The Emails and Print Jobs history grids (mass mail and batch print history) now recognize View access inherited from the module's main record type, even when a group has no explicit Emails or Print Jobs grant. For example, a group with View on CPC Clients can open the CPC Emails history and see mailings sent to CPC clients, without a separate Emails permission.
A few things to know about this inherited access:
It is scoped to the matching record type. A group that can only View CPC Clients sees CPC email and print history, not history for donors or other modules.
It is View-only. Creating, sending, duplicating, or printing a mass mail or batch print job still requires an explicit Create or Update grant on Emails or Print Jobs for that group, an inherited View on the recipient type is not enough.
Granting an explicit Emails or Print Jobs permission on the group still works the normal way, and gives that group the full, unscoped history instead of the module-limited view.
Resource and appointment type links inherit View from their parent grant
The Resources and Appointment Types settings pages each show a picker for linking one to the other, for example the list of appointment types linked to a resource. That picker now recognizes View access inherited from the matching grant: a group with View on Resources can see the appointment types linked to a resource, and a group with View on Appointment Types can see the resources linked to an appointment type, without a separate permission to grant for the link itself.
Before this fix, a group with View on Resources or Appointment Types but no other Scheduler grants could still get a permission error opening that picker. If your team is on a group like this, no setting needs to change, the picker now works with the permission already granted.
Why this matters
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.
Best practices
Use clear group names that match real job responsibilities. This makes it easier to understand why someone has access later.
Remember one group per person. Design each group as a complete access profile for that role.
When someone needs new access, ask what job they are trying to do, then grant the smallest amount of access that fits that work — usually by adjusting their current group or moving them to a better-fitting group, not by stacking groups.
Grant Module admin sparingly. It is the right tool for a team lead who maintains their own module's setup lists, not a substitute for making someone an administrator.
Module missing from the sidebar?
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.