What Is the Difference Between Data Extensions and Lists in Salesforce Marketing Cloud Engagement?
Lists organize email subscribers. Data extensions store structured data, such as customer profiles, orders, preferences, and campaign audiences. Use lists for simple subscriber-based email sends and data extensions when you need separate datasets, relationships, or SQL segmentation.
I haven’t worked on a project that used subscriber lists as its main audience model. The projects I’ve worked on have used data extensions.
How lists and data extensions differ
The main difference is how they organize your data. A list contains subscribers, while a data extension is a table whose fields and structure you define.
| Feature | Lists | Data extensions |
|---|---|---|
| Data structure | Subscriber records with profile and preference attributes | Custom fields and data types for each table |
| Segmentation | Groups based on subscriber attributes or sampling | Filters and SQL queries |
| Related records | Subscriber-focused data | Separate tables for customers, orders, and other records |
| Typical use | Simple email audiences | Campaign audiences, integrations, and automated data processing |
Salesforce recommends using lists for 500,000 subscribers or fewer. Use data extensions for larger audiences or when you expect to grow beyond that size. The 500,000 figure is a recommended threshold, not a hard technical limit.
Lists and data extensions both support email sending. The choice depends on your data requirements.
Groups are subsets of subscribers from a list. For example, a filtered group could contain subscribers from a particular country. Groups do not provide a separate structure for storing orders or transaction history.
Subscriber identity and sendable data extensions
Both models use Subscriber Key to identify email subscribers. A subscriber can belong to several lists without becoming several contacts. Using different keys for the same person can create duplicate contacts.
For a sendable data extension, configure the send relationship so the customer identifier maps to Subscriber Key. For example, CustomerID can relate to Subscribers on Subscriber Key.
An email address field alone does not make a data extension sendable. Also, its primary key identifies a row, which can serve a different purpose from Subscriber Key. An orders table could use OrderID as its primary key and contain several orders for the same customer.
Building audiences with data extensions
Data extensions let you keep source data separate from campaign audiences. For example:
- Store customer profiles and orders in separate data extensions.
- Use a SQL Query Activity to select customers who meet the campaign criteria.
- Save the results into a sendable audience data extension with the fields needed for the message.
For a campaign intended to send once per customer, prepare one audience row per Subscriber Key. Email content can use those fields directly or retrieve additional data with AMPscript lookups.
All Subscribers and publication lists still apply
Email sends from data extensions still use All Subscribers. Subscribers stored only in a data extension are added to All Subscribers when you first send to them.
Use publication lists to manage subscriptions to different communication categories, such as newsletters and product updates. This lets someone unsubscribe from one category while remaining subscribed to others. The data extension defines the audience; the publication list manages the category subscription.
