Adobe Campaign: technical workflow vs campaign workflow

In Adobe Campaign Classic, not all workflows are the same. The distinction between technical workflow and campaign workflow is fundamental, yet it's often blurry for developers new to the platform or teams just getting started. Here's what really sets them apart, and why it matters.

The fundamental distinction

Technical workflows : what they really do

Technical workflows are Campaign's invisible engine. They run in the background, often around the clock, ensuring the platform functions correctly. Without them, Campaign doesn't work.

Native technical workflows you must know

• Database cleanup : purges obsolete logs, work tables, expired quarantines. Check first if the database is growing abnormally.
• Update for unsubscriptions : synchronises unsubscribes between deliveries and profiles.
• Refresh for deliverability : updates MX rules and blocklists.
• Billing : reports usage metrics to Adobe. Do not disable.
• Cleanup of workflows : removes completed workflow instances to prevent accumulation.
• Tracking workflow : processes tracking logs received from the redirect server and inserts them into the database.

Custom technical workflows

Beyond native workflows, technical teams create their own technical workflows to:

• Synchronise data from external systems (CRM, MDM, ERP) via FDA or API
• Calculate scores or enrich profiles on a regular basis
• Generate reports and send them by email to internal teams
• Purge custom tables or archive old data
• Trigger alerts on volume or error thresholds

Technical workflow limits and constraints

• No native marketing targeting. A technical workflow does not have access to Campaign's standard delivery activities. It can theoretically call a delivery via JavaScript, but this is not the right pattern, typologies and pressure rules do not apply.
• No operation context. Without attachment to a campaign, metrics do not feed into marketing reports. Impossible to track performance in the campaign plan.
• Shared resource governor. Technical workflows run on the same application server as campaign workflows. A poorly optimised technical workflow (large SQL query in a loop, bulk loading without pagination) can degrade overall instance performance.
• Limited scheduling. The Scheduler activity allows triggering a workflow at regular intervals, but options remain simple. For complex needs (conditional scheduling, intelligent retry), JavaScript code or an external orchestrator is required.
• No long-term execution history. Technical workflow logs are purged by the native cleanup workflow. If you need a long-running execution history, you must implement your own custom log table.

Campaign workflows : the marketing logic

Campaign workflows are the workspace for CRM and marketing teams. They build target populations, apply business rules and trigger deliveries. They live in Campaign's Campaigns module and are attached to a marketing operation.

Typical campaign workflow activities

• Query, extracts a population from the database based on business criteria
• Exclusion / Intersection / Union, combines or filters populations
• Split, divides a population into sub-groups (A/B test, sub-segments)
• Enrichment, adds additional data to the population
• Delivery, the terminal activity that generates and sends messages
• Wait / Scheduler, manages delays and send timing

Campaign workflows and typologies

It's at the campaign workflow level that pressure and typology rules apply, they automatically filter recipients who have already received too many messages, are in an exclusion period, or match specific business rules. These rules are defined globally but applied at each campaign workflow execution.

Campaign workflow limits and constraints

• No independent long-term scheduling. A campaign workflow lives within its operation's lifecycle. If the operation ends or is archived, the workflow stops. For processes that must run indefinitely, recurring or continuous operations are needed, but they have their own management constraints.
• No direct access to system tables. Campaign workflows are designed to operate on marketing data (recipients, logs, deliveries). Accessing system or administration tables from a campaign workflow is possible via JavaScript but discouraged, that's the role of technical workflows.
• Timeout on long executions. A campaign workflow running too long (large population, heavy enrichments, loops) can hit instance timeout limits. Heavy processing must be split into sub-workflows or handled via technical workflows for data preparation.
• Limited concurrency. If multiple campaign workflows run simultaneously and query the same high-volume tables (broadLogRcp, trackingLog), performance can degrade. Send scheduling must account for overall instance load.
• Delivery context dependency. Some features (advanced personalisation, conditional content blocks) are only available in the context of a delivery attached to a campaign. A technical workflow attempting to reproduce this behaviour would have to recode everything manually.

Decision table

Most common mistakes

Putting business logic in a technical workflow

This is the classic mistake from teams starting out on Campaign. A technical workflow that builds populations and triggers sends, it works, but it bypasses typologies, pressure rules and the marketing plan. Tracking becomes impossible for marketing teams.

Creating campaign workflows for recurring tasks

Conversely, creating a campaign workflow to sync data every night means placing infrastructure logic in the marketing plan. It pollutes the campaign calendar and complicates technical supervision.

Confusing campaign workflows and operational workflows

In some ACC versions and configurations, there are also workflows at the level of recurring operations and continuous campaigns. These are campaign workflows with repetition logic, they are not technical workflows even if they run continuously.

Supervision and monitoring

Both workflow types are monitored differently:

• Technical workflows, monitored via Supervision → Technical workflows. A red alert on a native workflow must be addressed as a priority.
• Campaign workflows, visible in the marketing plan and campaign reports. Marketing teams have access to their tracking.

On V8 instances, the supervision interface is identical but execution performance may differ depending on whether the data being processed is in FDA Snowflake or Campaign's local database.

Conclusion

The technical / campaign workflow distinction isn't just an interface organisation question, it's an architecture and governance question. Respecting it ensures technical and marketing teams work within their respective scopes, typologies apply correctly and supervision remains readable. It's one of the first things I explain when arriving on a new Campaign instance.