Donor Management System (DMS): Requesting a DMS Data Extension (Email List)

To request a Data Extension sourced from the Donor Management System (DMS), submit a Query Request via a web form within DMS. You will need to work with a fundraising or alumni relations staff member within your unit. They are your strategic partner in defining your population. Your partner will then submit the Query Request.

Data Extension requests are completed by the University of Minnesota Foundation (UMF) IS Query Team on a default 7-day turn-around, and information about the requested Data Extension will be shared with your partner. With such robust selection criteria in DMS, fundraising and alumni relations staff will be the most helpful in making sure the request criteria is clear.

Roles

DMS expert role

  • Consult with you on the population to be targeted and marketing strategy (Fundraising and alumni relations teams)
  • Submit a Query Request via DMS with all the pertinent information and that clearly identifies the following:
    1. Who should get the email (selection criteria)
    2. The Salesforce Marketing Cloud Business Unit that use the requested Data Extension
    3. The default email unsubscribe level
    4. Additional exclusions
    5. Contact History Description - This will be used as the "description" on the Data Extension.

Salesforce Marketing Cloud expert role:

  • An email marketing expert who has knowledge of Salesforce Marketing Cloud, and how to appropriately incorporate DMS-sourced Data Extensions into your send workflow.

Email Request Example

The following is an example of the Query Details portion of a Query Request that includes Salesforce Marketing Cloud information. It contains information from a previously-submitted request.
Example of the Query Details in a Query Request

  • The Data Extension is the file that gets loaded to Salesforce Marketing Cloud. This includes DMS ID, email address from DMS, and name parts (first, last, middle, label name, prefix, suffix)
  • Data Extension naming convention
    • Digits 1-9: DMS Query Request #
      • E.g. 201902181
    • Digits 11-(12): Sequence (you may receive more than one extension per request)
      • E.g. 1
    • Digits 14-15: Calendar Year when built
      • E.g. 19
    • Digits 16-18: Day of calendar year when built
      • E.g. 206
    • Digits 20-27: Time stamp in HH24:MI:SS:FF format
      • E.g. 09292850
  • An email will be sent to the Query Requester with information on count, name, and description of the Data Extension once UMF technical staff complete the push to Salesforce Marketing Cloud.

 

Important Information About DMS-sourced Data Extensions

  • They are one-time use. Never reuse a DMS Data Extension beyond 10 days of initial build because of CAN-SPAM requirements.
  • Keep Data Extension name intact. The complete name or at least Digits 1-18 should always be left intact. This is a "breadcrumb" to get back to what was requested to produce the list.
  • Data Extension Description - This is the nicely worded name of the data extension that explains what it is for. This description comes from DMS Query Request, "Contact History Description". You can see this description on the Data Extensions list by clicking the spreadsheet/gear icon on the upper right and choosing Description.
  • Personalization Strings should always refer to the exact field name from the DMS Data Extension. Salesforce Marketing Cloud default personalization doesn't work well with DMS-sourced data extensions. Default Personalization Strings refer to the All Subscribers List (rather than to the DMS-sourced Data Extension). You should always refer to the DMS Data Extension for first name, last name, and other personalization data.
    Example of a Personalization String that refers to a DMS Data Extension: %%NAME_FIRST%%.
    Never use drop-down First Name. It won't error, but it won't be correct.
    For more information about the DMS Data Extension fields used in Personalization Strings, see DMS Data Extension Basics.
  • Never change the Subscriber Key. The Subscriber Key is unique to each person's email address within DMS. It is not their email address.
  • Default folder of a requested Data Extension is the root of the Business Unit. Alternative folders could be used for automated email builds but cannot be supported for ad hoc requests.
  • Delete only never-used DMS Data Extensions. Used DMS Data Extensions might need to be referenced after send.
  • Always test emails.
    Verify personalization strings, correct footer, and all links in the email. The DMS footer unsubscribe link goes to a DMS webpage that requires an extra step to unsubscribe so there's no fear of actually unsubscribing a person.
    Note: The non-DMS Commercial footer unsubscribe link points directly to the Marketing Cloud Subscription Center and a user will be unsubscribed immediately.
  • Most (nearly 90%) of emails sent with DMS Data Extensions require an unsubscribe link in the footer.
    These are normally external communications for donors and alumni, so more than likely need an unsubscribe link to comply with CAN-SPAM requirements.
  • Only DMS-sourced Data Extensions can be used as a Exclusion/Suppression list.
    All Exclusion Lists and Suppression Lists must be another DMS Data Extension since they use Subscriber Key to remove recipients. If you want to exclude some people from a send, ask for them to be suppressed when the DMS Query Request is submitted.

 

Last modified

TDX ID

3134