What Is a Recipient Table in Adobe Campaign Classic?

Adobe Campaign Classic’s “recipient table” is the core dataset the platform targets when you build segments, run workflows, and send deliveries. If that table (and its schema) is well designed, targeting is predictable, personalization is easier, and query performance is manageable. If it’s messy or overly customized, what typically happens is slow workflows, brittle joins, and targeting rules that are hard to debug.

In practical Adobe Campaign Classic terms, the recipient table is not just a database table name you happen to store emails in. It’s an entity defined in the Campaign data model, exposed through schemas, and referenced constantly by workflow activities and targeting logic.

Recipient table meaning in Adobe Campaign Classic

In Adobe Campaign Classic, the default “recipient” entity is represented by the built-in recipient schema, typically referenced as `nms:recipient`, which maps to a corresponding database structure and becomes the default target for many marketing operations like segmenting and sending to recipients. That central role comes directly from how Campaign organizes its out-of-the-box data model around standard entities and their relationships, including recipients as a first-class object in the model.

A useful way to think about it:

• The *recipient table* is the operational “who” table for outbound marketing.
• The *recipient schema* is the contract that defines what fields exist, how they relate to other entities, and how the platform reads and writes that data.

When people get confused, it’s usually because they’re mixing up these layers: the schema, the database table, and the targeting context in workflows.

How the recipient table fits into the Campaign Classic data model

Campaign Classic is schema-driven. The schema is where field definitions, links, and database mappings are declared. The platform’s UI, query builder, and many workflow operations depend on those schema definitions being correct and consistent with the underlying database structure. Campaign Classic data model is defined through schemas and their relationships.

Schemas are the “source of truth” for targeting and joins

In practice, your recipients might look straightforward at first (email, first name, last name), but the moment you need to target based on subscriptions, transactions, loyalty status, or consent history, you rely on schema links to traverse data cleanly.

That’s why a “recipient table” conversation is often really a “schema design” conversation. If the schema link between recipients and another table is missing, mis-declared, or points the wrong way, segmentation becomes awkward and you end up with workarounds like staging tables and duplicate logic across workflows.

The schema also controls SQL mapping details

Campaign schemas are not abstract documentation. They include how fields map to SQL columns and how keys and relationships are defined at a technical level. Those details matter when you run heavy segmentations or build custom tables, because a small mismatch (wrong key, wrong cardinality, wrong join path) can cause invalid SQL, full table scans, or results that look “almost right” but are subtly wrong schema structure, keys, and SQL mapping attributes.

One limitation is that Campaign’s visual tools can make a join look harmless, while the generated SQL is expensive. The schema design is where you prevent that.

Where the recipient table shows up in real workflows

Most teams first “feel” the recipient table when building a workflow or delivery targeting. Even if you never touch the database directly, the recipient table is still the primary targeting dimension behind many everyday operations.

Query activity: the recipient table as a targeting dimension

The Workflow Query activity is the most common place the recipient table becomes concrete. You select a targeting dimension (often recipients) and then apply filters and joins based on linked data. The Query activity is designed to build populations by applying conditions and producing an outbound set for downstream steps like enrichment, splitting, or delivery how the Query activity builds and outputs populations.

In practice, this is where schema quality shows up immediately:

• If recipient links to your custom tables are properly defined, you can filter recipients by those attributes cleanly.
• If links are missing or ambiguous, you end up extracting IDs, doing manual reconciliations, or materializing intermediate tables just to make targeting possible.

Personalization is only as reliable as your recipient data model

Even when targeting is correct, personalization depends on the same structure: the delivery process needs to resolve the right recipient record and traverse the right relationships for lookup values.

A common issue is “it works in a workflow preview but fails in delivery” behavior. The root cause is often not the delivery itself, but inconsistent assumptions about which recipient record is being targeted, or joins that behave differently depending on how the population was built. Good schema hygiene reduces those surprises.

Extending the recipient table without creating upgrade pain

Customizing the recipient table is normal in Adobe Campaign Classic. Most implementations need extra fields (membership status, regional codes, customer IDs) or links (orders, contracts, preferences). The goal is to extend it in a way that remains supportable and predictable.

The safe pattern is to extend the data model through the supported schema mechanism rather than altering standard definitions directly. Campaign’s data model is explicitly designed to be configurable and extensible through schemas, with standard entities forming a base you build on (standard model plus extension approach).

What usually happens when extensions are done poorly

When extensions are rushed, teams often run into:

• Fields added without thinking about indexing and query patterns
• Links added in a way that forces “fan-out” joins (one recipient to many rows) during segmentation
• Multiple “recipient-like” tables created because the original recipient entity was hard to change, which then fragments targeting

You can still make those designs work, but you’ll pay for it in workflow complexity and performance tuning later.

Schema-level decisions that affect performance

Because schemas define keys and SQL mappings, extension decisions directly affect database behavior. Even without writing raw SQL yourself, the platform still generates SQL behind your query activities and delivery targeting. Getting keys and links right is the difference between a fast indexed join and a slow query that locks up during peak campaign windows (schema mapping and key definitions used for database operations).

Recipient table pitfalls that show up in segmentation and targeting

Most recipient-table problems are not “broken platform” problems. They’re data model problems that only become visible once you scale volume, add more joins, or start building reusable segment logic.

Join explosions from one-to-many links

If recipients link to tables like purchases, clicks, or subscriptions, segmentation can accidentally multiply rows. Query results may look inflated, or downstream steps may behave unpredictably if you assume one row per recipient.

In practice, the fix is rarely “add DISTINCT everywhere” as a permanent strategy. The better fix is modeling and query discipline:

• Filter child tables first, then join to recipients.
• Aggregate or precompute flags (for example, “hasPurchasedInLast90Days”) when appropriate, so targeting does not require scanning high-volume detail tables every time.

Dynamic conditions: powerful, but easy to make brittle

Campaign workflows often need dynamic filters: a date window, a runtime parameter, a list of values pulled from another activity, or logic that changes by campaign. Building these conditions cleanly is mostly about using the query tooling correctly and keeping logic readable.

A practical pattern is to keep the Query activity doing “selection” and push complicated branching logic into workflow structure (split, multiple queries, or staged populations) so you can test each piece independently. This is especially useful when you’re dealing with variables or dynamic lists, where small mistakes can silently produce empty audiences or unexpectedly large audiences (practical patterns for building dynamic queries and avoiding common logic traps).

What typically happens in mature environments is that teams standardize a few reusable targeting workflows that output clean recipient populations, then feed those populations into multiple deliveries. That reduces duplication and makes the recipient table behave like a stable contract rather than a constantly reinterpreted dataset.

How to validate what your “recipient table” really is

When someone says “recipient table” in a real Adobe Campaign Classic project, it’s worth clarifying three things:

• Which schema is the targeting dimension using? In many cases it’s `nms:recipient`, but custom setups may target a different profile-like schema.
• Which physical table and keys are behind it? Schemas define the SQL mapping and keys that the platform relies on for joins and selection (how schemas declare SQL names and keys).
• Which links are required for the segment logic you care about? If marketing needs “recipients who did X,” the model must support that relationship in a way that does not force expensive queries for every campaign.

If those three are explicit, the recipient table stops being a fuzzy concept and becomes something you can design, optimize, and troubleshoot systematically.

Share With Others