When admins create new profiles (through Data Studio or mapping), those profiles need a clear starting point for whether they should receive emails from your institution.
Setting a default email preference for new profiles at the site level is crucial, so the admin-created records are consistent and predictable.
Users(Guests/Donors/Community members) can still update their own communication preferences if given the option. This setting is just to set a default preference for admin-created records.
How it works
1) Set your site default (Site Admin)
Go to Site Settings.
Open the Custom Features section.
Find Default email preference for new profiles.
Choose one of the following:
Allowed by Admin: New admin-created profiles are treated as email-eligible by default.
Denied by Admin: New admin-created profiles are treated as not eligible for emails by default.
Allowed for transaction: New admin-created profiles use the transactional-safe default (this is also the fallback if the setting isn’t configured).
Save your changes
Denied by admin and Allowed for transaction works the same way. Transaction emails like event registration, gift confirmation, etc., are always sent irrespective of the preference. Allowed for transaction is typically set by the system automatically for profiles created with automated workflows. If you had to choose between the two, choose Denied by admin.
2) What happens when an admin creates a new profile
This default is applied when a profile is created through admin-driven flows, like:
Data Studio (for example, “Add New Record”)
Mapping / mapper-driven profile creation (including “create from external database” flows)
How the default is applied:
If a profile is created without an explicit email preference, the profile gets your site's default automatically.
If the creation flow explicitly sets the email preference to Allowed by Admin or Denied by Admin, that explicit choice is kept.
What this does not do
It does not update existing profiles that already exist in your database.
It does not change end-user signup or preference behavior (for example, when an alum signs up or updates their own communication preferences).
FAQs
Does this change the email preference for profiles that already exist?
No. This only applies when a new profile is created by an admin-driven flow.
If I change the site default later, will old profiles update automatically?
No. A new default only affects profiles created after the change.
What if we don’t configure this setting?
The system uses Allowed for transaction as the fallback default. Nothing changes from previous behaviour.
Does this affect users who sign up or manage their own preferences?
No. This setting is for admin-created profiles from Data Studio and the Mapping workflows only and does not affect end-user behavior.
What if the profile doesn’t have an email address yet?
The preference can still be set on the profile, but the profile won’t receive emails until a valid email address exists.