Skip to main content

Advancement Marketing Cloud

Data extensions

The lists used for sending emails are called data extensions. Advancement is not part of the enterprise SalesForce instance for the University, so this is the only method for generating lists in Marketing Cloud to send emails.

At this time, Advancement IT will handle the creation of any data extensions. 

Marketing Cloud Subscribers (Data Extensions)

Whenever possible, use the existing data extensions (DE) in Marketing Cloud (MC).

If a single table can be filtered on data within that DE, then use a simple filter to create a new DE. If the DE will be used:

  • Once: Keep in mind the retention policy cannot be set on these DEs. Therefore, include the date of the email send in the name of the DE so it can be deleted later. 
  • Multiple times: 
    • Frequently: Set up the filter, filter activity, and automation to refresh the filter.
    • Infrequently: Create a standard filtered DE and make sure to manually refresh before using the DE.

If data is needed from two or more DEs, use a SQL query activity. This is especially important when combining two tables where a one-to-many relationship exists. Even if a relationship is established in MC, the filter does not always behave as desired and does not bring in a complete list of data. A SQL query ensures all of the needed records are included. If this is a DE that will be used:

  • Once: Consider manually uploading a list from RE instead.
  • Multiple times:
    • Frequently: Consider creating an automation to keep the DE updated.
    • Infrequently: Remember to run the query to refresh the DE before use. If the frequency is very low, consider manually uploading a list from RE instead.

For list manually uploaded from RE or other sources, the minimum fields required are:

  • Constituent ID
  • Preferred Email
  • Nickname (if the email will be personalized)

Even though a DE can be sendable with only constituent IDs (which are the subscriber keys), it is safer to include the email in case the constituent is not already established as a subscriber.

Be sure to set the retention policy for manually uploaded DEs. Allow users to delete the DE and set the DE to delete all records and data extensions after 60 days. This will help prevent a glut of DEs. If a list of who received the email is needed, this can be grabbed from the Tracking tab.

If a person does not have a constituent ID, then use their email as the ID.

Naming Convention: [Year] [3-letter month] [Descriptive Name]

Example: 2020 Nov Power of Scholarships Invitation

Advancement has set up some basic data extensions that can be used on their own or as the base for a filtered or query-created data extension.

The main data extensions include data for:

  • Basic constituent information, including name, nickname and preferred class (if applicable)
  • Alumni Community affiliation
  • Assigned development officer
  • Solicit codes
  • Email opt-outs from Raiser's Edge
  • Gift history (FY20 and later)
  • Giving societies
  • Events and event participation
  • Education

Frequently refreshed lists of constituents include:

  • Alumni Communities
  • Groups, such as current parents, fac/staff and students
  • Reunion years
  • Giving societies
  • Education

Check the data definitions document for more information.


Determining which data extensions to use for an email

Use whichever data extension is provided with the email request, be it an existing one or one that needs to be created from a Raiser's Edge query or a CSV file.

In addition to the main data extension(s), include the people who have requested the email and/or were on the draft review process. Many of these individuals have their own data extension located under Staff > Individual or Staff > Not ADV.

Include the Campus Comm Team on every email.**

For the suppression list, choose the one that is appropriate for the type of email being sent. These lists are found under Do Not Send Lists. The "general" data extension is sufficient for most emails.

Marketing Cloud Do Not Send

Each email should have a suppression list to remove people who have opted out. Please use the appropriate list based on the suppression list guidance.

  • Do Not Send List - Alumni Community
    Use for all alumni community-specific emails. This does not include the all alumni emails because those messages are not about a specific community.
  • Do Not Send List - Annual Giving
    Use for any emails from Annual Giving or anyone else where the main focus of the email is an annual gift solicitation. (Most of these emails are now being sent via EAB.)
  • Do Not Send List - Events
    Use for emails where an event(s) is the main focus - invitations, reminders, confirmations, and follow-ups.
  • Do Not Send List - Family News Digest
    Use for Family News Digest and current parent emails.
  • Do Not Send List - Flyer Family Network
    No longer used.
  • Do Not Send List - General
    Use for any email that does not fall under one of the other scenarios listed.
  • Do Not Send List - One Day One Dayton
    Use for emails where the main focus is giving day.
  • Do Not Send List - One Day One Dayton PLUS GIFTS
    Intended for use on the day of giving day to remove people who have already made a gift. Note, this one will need to be manually refreshed before using.
  • Do Not Send List - Planned Giving
    Use for emails from Planned Giving or anyone else where planned giving is the main focus of the email. (Most of these are sent via Crescendo.)
  • Do Not Send List - Reunion Updates
    Use for emails where Reunion Weekend is the focus.
  • Do Not Send List - UD eNewsletter
    This is for Cerkl and not used in Marketing Cloud.
  • Do Not Send List - UD Magazine
    Use for emails announcing new issues of UD Magazine or for surveys sent on behalf of the UD Magazine team.

Data extensions for emails with custom/dynamic content

Some emails will have dynamic content included in the body, such as alumni community-specific links or lists of giving society memberships for each constituent. To make things easier in these cases, make sure the necessary data is in the data extension being used to send the email.

Another option is to use custom code (called AMPScript) to pull data dynamically from other data extensions. Please contact Advancement IT at if custom code is needed for an email.

**If an email has custom fields, the Campus Comm Team and any other person or group will need to have the custom fields in order for the email to send. Either add these people to the data extension being used for the email (if they are not already on the list) or create a separate data extension that includes all of the required fields.

Alumni community data extensions already include the necessary field for looking up dynamic content. This is an example of using AMPScript and the appropriate script is already included in the alumni community email templates. Campus Comm Team and the appropriate alumni relations staff are already included in these data extensions, too, so there is no need to add them.


University Advancement IT

Daniel J. Curran Place
300 College Park
Dayton, Ohio 45469 - 7051