What Is Adobe Campaign Classic? Architecture and Core Concepts

I am starting a series on Adobe Campaign Classic, and the right place to begin is the Adobe Campaign Classic architecture. Most of the confusing behaviour people run into later, from a workflow waiting for no obvious reason to a click that is recorded hours after it happened, makes sense once you know which part of the platform does which job.

Here I write about what Campaign Classic is, the three layers it is built on, the server modules, the main deployment and hosting options, and the core objects you will work with. At the end, I follow one email through the whole system, because that is the explanation that finally made it click for the people I have trained.

What Adobe Campaign Classic is for

Campaign Classic is Adobe’s platform for planning, targeting, personalising and sending marketing messages across channels such as email, SMS, push notifications and direct mail, and for tracking what happens afterwards. It came to Adobe with the acquisition of Neolane, which is why you still see “neolane” in installation paths and “nl” at the start of most command names.

What sets it apart from simpler email tools, though, is that it is built around your data model. You can extend the recipient table, add your own tables, and target on any of it through workflows. That flexibility is the reason large organisations choose it, and also the reason it needs more technical care than a typical email tool.

My honest view: if nobody on the team will own the schemas, the workflows and the technical workflows, Campaign Classic is the wrong choice, however good the licence deal looks. It rewards teams that treat it as a platform with an owner. Teams that expect an email tool they can learn in a week end up paying for features they never use and fighting the ones they do.

The current major version is v7. If you are on v6 or v5, upgrading to v7 is a migration project rather than a simple update, and I cover that in a later post on moving from v6 to v7.

The three layers of the Campaign Classic architecture

Adobe describes the platform as three layers. The general architecture page is worth reading in full, but here is the short version.

Presentation layer

This is how people and systems reach Campaign:

• The client console is a native Windows application. It is the main interface for marketers, developers and administrators. It talks to the server over HTTP or HTTPS using SOAP, so it does not need a direct connection to the database.
• The web interface covers parts of the platform in a browser, such as reports, approvals and some distributed marketing features.
• APIs let other systems call Campaign through SOAP web services.

Application layer

This is a set of server processes, all started from one binary called nlserver with a module name. Each module does a specific job, and they can run on one machine or be spread across several.

Persistence layer

A relational database holds nearly everything: profiles, subscriptions, deliveries, workflows, delivery logs, tracking logs, and your own custom data. Campaign supports several database engines, including PostgreSQL, Oracle and Microsoft SQL Server. Almost every module depends on the database, which is why database health is the first thing to check when the platform misbehaves.

The server modules in the Adobe Campaign Classic architecture

These are the modules you will hear about most often. They are all instances of nlserver.

There are others for specific options, such as sms for SMS status and interactiond for the Interaction module. The production guide’s page on usual commands shows how to list and control them. On an on-premise server, these are the two commands I run first:

# List the nlserver modules running on this machine
nlserver pdump

# Start or stop a single module, for example the workflow engine
nlserver start wfserver@default
nlserver stop wfserver@default

@default is the instance name. One server can host several instances, each with its own database and configuration.

A point that surprises people: the redirection module does not need the database. It writes tracking data locally, and the tracking technical workflow collects it on a schedule. This is deliberate, so a database problem never breaks the links in your emails. It also explains why click counts in reports lag behind real time.

How the Adobe Campaign Classic architecture is deployed and hosted

How the modules are spread across machines is the deployment type. Adobe documents several. The main ones:

• Standalone, where everything, sometimes including the database, runs on one machine. Fine for development or very small volumes.
• Standard, where the application server and workflow engine run on one machine, with separate frontal servers handling redirection and tracking in front of it.
• Enterprise, with multiple application servers, separate delivery servers and a dedicated database, for high volumes and high availability.
• Mid-sourcing, where the marketing instance prepares deliveries and a separate mid-sourcing instance, often hosted by Adobe, sends them and handles tracking.

Separately, there is the question of who runs the infrastructure. In the hosted model Adobe runs everything. In the on-premise model you do. Hybrid, on the other hand, splits it, typically with marketing on your side and delivery and tracking hosted by Adobe through mid-sourcing. The hosting models page describes each.

The hosting model matters day to day. On an on-premise platform, you can read server logs and change serverConf.xml. On a hosted platform, however, you work through the console and Adobe’s support for anything at the server level.

When a client asks me to choose, I lean towards hosted unless they already run databases and Linux servers well and have a real reason, such as data residency, to keep everything in house. On-premise gives you full control, but it also makes you responsible for upgrades, monitoring, the MTA and the database when something breaks overnight. Hybrid is the option I think teams consider too rarely. Marketing data stays with you, while Adobe runs the sending and tracking side, where reputation and uptime matter most. Still, the trade-off is a second instance to understand and the synchronisation between the two.

Core Adobe Campaign Classic concepts you will meet first

Schemas

Everything in Campaign is described by a schema, an XML definition of a table or object. Schemas have a namespace and a name, such as nms:recipient for recipients or nms:delivery for deliveries. Adobe’s own schemas use namespaces such as nms and xtk. Your extensions go in your own namespace, usually cus. I cover schemas in detail in the posts on the data model and custom schemas.

Recipients

nms:recipient is the default profile table. It holds names, email address, mobile number, consent flags and many other fields. Most projects extend it, although some replace it with a custom recipient table.

Folders

The console organises objects into folders in the Explorer tree. Folders control what operators can see and do, because access rights are granted at folder level.

Workflows

Workflows are diagrams of activities: queries, splits, imports, scripts, deliveries. In other words, they are how targeting and data processing are automated. Technical workflows keep the platform itself running.

Deliveries and templates

A delivery is one message to one target on one channel. A delivery template stores reusable settings and content, so each new delivery starts from a known configuration.

Logs

Every message sent creates a delivery log. Similarly, every open and click creates a tracking log. These tables grow fast and drive most reporting, which is why the cleanup workflow and database maintenance matter so much.

The worked example: one newsletter, end to end

Here is a hypothetical but ordinary case: a marketer sends the weekly newsletter, and one subscriber clicks a link. Following it shows how the layers fit together.

1. Building the target. In the client console, the marketer opens the newsletter workflow. The console sends SOAP calls to the web module, which reads and writes the workflow definition in the database.
2. Running the workflow. Then the marketer starts the workflow. The wfserver module picks it up, runs the Query activity as SQL against the database, and stores the selected recipient IDs in a temporary worktable.
3. Preparing the delivery. The workflow’s delivery activity creates a delivery from the newsletter template. During analysis, Campaign applies exclusions for quarantine, the blacklist and typology rules, and personalises the content.
4. Sending. The mta module builds each personalised message and sends it over SMTP. The stat module keeps track of connections and limits per receiving mail server. A delivery log row is written for each message.
5. A bounce. One address no longer exists. The receiving server sends a bounce to the platform’s bounce mailbox. inMail reads it, qualifies it as a hard error, and the address is quarantined. I explain this mechanism in my bounce and quarantine guide.
6. A click. A subscriber clicks a link. Because Campaign rewrote the link, the browser first hits the redirection module (webmdl) on the tracking server. It records the click through trackinglogd and then redirects the browser to the real page.
7. Collecting tracking. The tracking technical workflow, run by wfserver, collects the click from the tracking server and writes it to the tracking log tables in the database. Only then does it appear in the delivery’s reports.

Every module in the table above has played a part, and the database was involved at every step except the click.

What the Adobe Campaign Classic architecture means in practice

A few practical consequences of this design that I wish someone had told me early on:

• Most problems show up in the database first. Slow workflows, failing deliveries and long console response times usually come back to database load or locked tables.
• Workflows are asynchronous. Starting a workflow, for example, puts a request in a queue for wfserver. If the engine is busy, nothing seems to happen for a while.
• Reports lag. Tracking data arrives in batches, so a report straight after a send shows partial numbers.
• The console is not the server. A console that cannot connect may be a network or security zone issue, not a platform failure.
• Technical workflows matter. If the tracking or cleanup workflows stop, reports go stale and tables grow without limit.

FAQ

Is Adobe Campaign Classic the same as Campaign Standard?

No. They are separate products with different architectures and interfaces. Classic is more configurable and can run on-premise. Standard is web-based and hosted only. I compare them in a separate post.

Do I need the Windows console for Adobe Campaign Classic?

For most configuration and development work in Campaign Classic, yes. Some tasks, such as reports and approvals, are available in a browser, but schemas, workflows and deliveries are built in the console.

Can I see which modules are running on a hosted instance?

Not with server commands, because you do not have shell access. The instance monitoring page and the technical workflow statuses in the console give you most of what you need, and Adobe support can check the rest.

What database should I choose for an on-premise install?

Use one that is supported for your build in Adobe’s compatibility matrix and that your team can administer well. The Adobe Campaign Classic architecture puts heavy, constant load on the database, so in-house expertise matters as much as the engine itself.

In the next post, I compare Campaign Classic with Campaign Standard, which is the question most teams ask before they commit to either.

Last updated on 26 October 2026