Below the Waterline: Security Considerations for Salesforce Activities in Nonprofit Orgs
When nonprofits think about protecting sensitive data in Salesforce, they usually picture Contacts, Cases, or Program Enrollment/Engagement records. Those matter. But some of the most sensitive information in your org may be sitting somewhere less obvious: your Activities.
Every logged call, text message, and captured email becomes an Activity record, and those records often hold the details that matter most. That includes what a client disclosed on a phone call, what a donor shared about a family illness, and what a program participant texted at midnight. As more organizations connect dialers, SMS platforms, and email tools to Salesforce, these records accumulate quickly and usually without anyone reviewing who can see them.
How Activity Visibility Works
Salesforce Activities (Tasks and Events) don't follow the same sharing rules as most records. Most objects offer a range of organization-wide settings and profile or permission-set level finer controls, from Public Read/Write to Private, and even with the ability to add conditional visibility with Sharing Rules. Activities offer only two global settings, and neither works the way people tend to assume.
Controlled by Parent is the most common setting, as well as the default. In short, this means that if a user can see the associated parent records (such as Contact, Account, or Opportunity) that an activity is attached to, they can generally see the activity too. If they can edit that parent record, they can generally edit the activity.
Private sounds like it should keep activities visible only to the person who logged them, but that's not quite what it does. Private limits who can edit or delete an activity to its owner and the people above them in the role hierarchy. Anyone who can view the related record can still view and report on the activity itself.
In other words, neither setting hides the content of an activity from someone who can see the record it's attached to. That's the key idea to hold onto. If sensitive conversations are being logged to a record that many people can see, changing the activity setting alone won't protect them.
That design makes sense for sales teams. It can be a problem for nonprofits. Imagine a single Contact who is both a volunteer and a program participant. Your volunteer team needs to see that Contact. Should they also see the case manager's call notes? Under either setting, they may be able to, unless someone deliberately designed against it. That might mean logging sensitive interactions to a separate, restricted record, or using tools like Restriction Rules to narrow which activities certain users can see.
Controlling Visibility by Controlling Parent Records
But wait, you may say, what if you know that for Controlled by Parent to give a user access to the Activity, they must have access to ALL the related parents? This can be a way to prevent data leakage, but before we straw-man this approach, let's understand it.
Activity records have two key parent lookups: WhoID and WhatID. These looks are what we call "polymorphic" and they are the reason all this is so difficult. Polymorphic fields in Salesforce are fields that can look up to more than one object from the same field. They can't be created, and they only exist in very limited circumstances, such as on activity records. WhoID can be either a Contact or a Lead, so that's pretty simple. WhatID, which appears most frequently in the user interface as "Related to," is a lot tricker. It can look up to just about any object in your org (there are limits, but it's outside of the scope of this conversation).
When using Controlled by Parent to manage an activity record with both WhoID and WhatID populated, a user must have access to BOTH of these records in order to access the Activity. This can be leveraged to keep sensitive material private. Let's take the same example of a single Contact that is both a volunteer and a program participant. If the volunteer manager logs a call which looks up to the Contact, then the case manager will be able to see it, but if the case manager logs a call that they link both to the Contact and the Contact's Program Engagement/Enrollment, then our volunteer manager who does NOT have access to those program records cannot see the call's activity record.
In this way, access can be safely managed, but is extremely difficult to enforce without extensive training and regular audits.
Where Integrations Make It More Complicated
Integrations are enormously valuable. They save staff time and create a complete record of engagement. But they introduce three major risks that are easy to miss.
#1 - They write wherever they're told to. A dialer or SMS tool doesn't understand your program boundaries. It logs activity against whatever record it matches, usually by phone number or email address. If a household shares a phone number or an email address, a message from one person can land on another person's record. Most critically, integrations rarely have the ability to ensure the WhatID is also populated. This can expose sensitive note or text messages quite easily.
#2 - They often run as a single "integration user." Many tools create activities under one shared user account. Depending on how that user is configured, this can either hide activities from the staff who need them or expose them more broadly than intended.
#3 - The content may not live in Salesforce at all. Some email tools store messages outside standard Salesforce records, with their own separate sharing settings. Many dialer and SMS apps keep call recordings and full transcripts on their own servers and write back only a summary or link. That means your Salesforce security model may not be the only one that matters, and you may have more than one system to secure.
Why Nonprofits Face Higher Stakes
For a sales organization, an overexposed call log is an embarrassment. For a nonprofit, it can put people at risk.
Survivor safety: Organizations serving survivors of domestic violence face real danger if a text thread or call note is logged to a shared household record or visible to the wrong staff or volunteers.
Regulated information: Health, behavioral health, and substance-use programs may carry obligations under HIPAA or 42 CFR Part 2. Education programs may carry FERPA obligations. Activity notes are often where that protected information actually gets written down.
Immigration and legal status: Details shared in confidence can create serious harm if exposed.
Volunteers and portals: Many nonprofits give volunteers, board members, or partners access through licenses or Experience Cloud portals. Every expansion of access is worth checking against where activity data can travel.
Donor trust: Donors share personal details with gift officers expecting discretion. That trust is part of the mission.
Questions to Ask Before (and After) Selecting an Integration
You don't need to be a Salesforce expert to start this conversation with your team or your implementation partner. These questions are a good place to begin:
What records will this integration log activities against, and how does it decide which record matches?
Do we have the option to store this information in a custom object instead of activities?
Which user will own those activities, and what can that user see?
Who in our org can currently see activities on a shared Contact or Account, and is that appropriate for every program?
Where do the full recordings, transcripts, or email bodies actually live, and who can access them there?
How long do we keep this data, and do we have a process for deleting it when we should?
Charting a Safer Course
Activity integrations can be worth having. The goal isn't to avoid them. It's to connect them deliberately, with a clear picture of who can see what. A short review before go-live, and a periodic check afterward, can prevent the kind of exposure that's hard to undo.
If you're planning a new integration or aren't sure how your current activity data is protected, BrightHelm Partners can help you assess your setup and design a sharing model that fits how your programs actually work.
