CoolFocus access 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.
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 combined 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: a user marked Administrator on the Users page can open every licensed module even when group checkboxes would not cover everything. For everyone else, the single assigned group is the source of truth.
See also Users.
• 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 — usually by updating their one group, or by placing them in a different group that already fits.
Open Settings, then go to Security and choose User Groups.
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.
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.
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.
• 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 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.
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 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.
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.
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.
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.
• 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.
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.
• Users
• User Groups Created in CoolFocus 5 Do Not Grant Access in CoolFocus 3
• Data Access Rules: Limit Which Records Staff Can See, limit which individual records a group can reach
• Inviting Your Team
• Troubleshooting: A module icon is missing from the sidebar
• Forms vs. Charts
