Adobe Campaign : workflow technique vs workflow de campagneAdobe Campaign: technical workflow vs campaign workflow
Pierre FrinMai 2026May 20267 min de lecture7 min read
Dans Adobe Campaign Classic, tous les workflows ne se ressemblent pas. La distinction entre workflow technique et workflow de campagne est fondamentale — pourtant elle est souvent floue pour les nouveaux développeurs ou les équipes qui arrivent sur la plateforme. Voici ce qui les différencie vraiment, et pourquoi ça compte.
La distinction fondamentale
Workflow technique
Vit dans Administration → Workflows techniques
Pas rattaché à une campagne
Tourne en continu ou sur planification fixe
Géré par les équipes techniques
Invisible pour les équipes marketing
Impact infrastructurel direct
Workflow de campagne
Vit dans une campagne marketing
Rattaché à une opération ou un programme
Déclenché par une campagne ou un calendrier
Géré par les équipes marketing / CRM
Visible dans le plan marketing
Produit des diffusions
Les workflows techniques — ce qu'ils font vraiment
Les workflows techniques sont le moteur invisible de Campaign. Ils tournent en arrière-plan, souvent 24h/24, et assurent le bon fonctionnement de la plateforme. Sans eux, Campaign ne fonctionne pas.
Les workflows techniques natifs à connaître absolument
Nettoyage de la base (Database cleanup) — purge les logs obsolètes, les tables de travail, les quarantaines expirées. À vérifier en priorité si la base grossit anormalement.
Mise à jour des qualifications (Update for unsubscriptions) — synchronise les désabonnements entre les diffusions et les profils.
Mise à jour du réseau de diffusion (Refresh for deliverability) — met à jour les règles MX et les listes noires.
Facturation (Billing) — remonte les métriques d'usage à Adobe. Ne pas désactiver.
Nettoyage des workflows (Cleanup of workflows) — supprime les instances de workflow terminées pour éviter l'accumulation.
Tracking (Tracking workflow) — traite les logs de tracking reçus du serveur de redirection et les insère dans la base.
⚠️ Attention : ne désactivez jamais un workflow technique natif sans savoir exactement ce qu'il fait. Certains maintiennent la cohérence des données — les désactiver peut provoquer des effets de bord difficiles à diagnostiquer plusieurs jours plus tard.
Les workflows techniques custom
En plus des workflows natifs, les équipes techniques créent leurs propres workflows techniques pour :
Synchroniser des données depuis un système externe (CRM, MDM, ERP) via FDA ou API
Calculer des scores ou enrichir des profils sur une base régulière
Générer des rapports et les envoyer par email à des équipes internes
Purger des tables custom ou archiver des données anciennes
Déclencher des alertes sur des seuils de volumétrie ou d'erreurs
Limites et contraintes des workflows techniques
Pas de ciblage marketing natif. Un workflow technique n'a pas accès aux activités de diffusion standard de Campaign. Il peut en théorie appeler une diffusion via JavaScript, mais ce n'est pas le bon pattern — les typologies et règles de pression ne s'appliquent pas.
Pas de contexte d'opération. Sans rattachement à une campagne, les métriques ne remontent pas dans les rapports marketing. Impossible de suivre les performances dans le plan campaign.
Gouverneur de ressources partagé. Les workflows techniques tournent sur le même serveur d'application que les workflows de campagne. Un workflow technique mal optimisé (grosse requête SQL en boucle, chargement massif sans pagination) peut dégrader les performances globales de l'instance.
Planification limitée. L'activité Planificateur permet de déclencher un workflow à intervalles réguliers, mais les options restent simples. Pour des besoins complexes (planification conditionnelle, retry intelligent), il faut passer par du code JavaScript ou un orchestrateur externe.
Pas d'historique d'exécution à long terme. Les logs de workflow technique sont purgés par le workflow de nettoyage natif. Si vous avez besoin d'un historique d'exécution longue durée, il faut implémenter votre propre table de log custom.
Les workflows de campagne — la logique marketing
Les workflows de campagne sont l'espace de travail des équipes CRM et marketing. Ils construisent des populations cibles, appliquent des règles métier et déclenchent des diffusions. Ils vivent dans le module Campagnes de Campaign et sont rattachés à une opération marketing.
Les activités typiques d'un workflow de campagne
Requête — extrait une population depuis la base selon des critères métier
Exclusion / Intersection / Union — combine ou filtre des populations
Partage — divise une population en sous-groupes (A/B test, sous-segments)
Enrichissement — ajoute des données supplémentaires à la population
Diffusion — l'activité terminale qui génère et envoie les messages
Attente / Planificateur — gère les délais et la temporisation des envois
Workflows de campagne et typologies
C'est au niveau du workflow de campagne que les règles de pression et de typologie s'appliquent — elles filtrent automatiquement les destinataires qui ont déjà reçu trop de messages, qui sont en période d'exclusion ou qui correspondent à des règles métier spécifiques. Ces règles sont définies globalement mais appliquées à l'exécution de chaque workflow de campagne.
Limites et contraintes des workflows de campagne
Pas de planification indépendante longue durée. Un workflow de campagne vit dans le cycle de vie de son opération. Si l'opération se termine ou est archivée, le workflow s'arrête. Pour des processus qui doivent tourner indéfiniment, les opérations récurrentes ou continues sont nécessaires — mais elles ont leurs propres contraintes de gestion.
Pas d'accès direct aux tables système. Les workflows de campagne sont conçus pour opérer sur les données marketing (destinataires, logs, diffusions). Accéder à des tables système ou d'administration depuis un workflow de campagne est possible via JavaScript mais déconseillé — c'est le rôle des workflows techniques.
Timeout sur les longues exécutions. Un workflow de campagne qui tourne trop longtemps (grosse population, enrichissements lourds, boucles) peut atteindre les limites de timeout de l'instance. Il faut découper les traitements lourds en sous-workflows ou passer par des workflows techniques pour la préparation des données.
Concurrence limitée. Si plusieurs workflows de campagne s'exécutent simultanément et requêtent les mêmes tables volumineuses (broadLogRcp, trackingLog), les performances peuvent se dégrader. La planification des envois doit tenir compte de la charge globale sur l'instance.
Dépendance au contexte de la diffusion. Certaines fonctionnalités (personnalisation avancée, blocs de contenu conditionnels) ne sont disponibles que dans le contexte d'une diffusion rattachée à une campagne. Un workflow technique qui tenterait de reproduire ce comportement devrait tout recoder manuellement.
Le tableau de décision
Besoin
Type de workflow
Synchroniser des données depuis un système tiers toutes les nuits
Technique
Envoyer un email promotionnel à un segment client
Campagne
Purger les logs de diffusion de plus de 6 mois
Technique
Relancer les non-ouvreurs d'une campagne J+3
Campagne
Calculer un score d'engagement client chaque semaine
Technique
Construire une population A/B test et envoyer deux variantes
Campagne
Mettre à jour les quarantaines depuis une liste d'exclusion externe
Technique
Déclencher un email de bienvenue à J+1 après inscription
Les deux selon l'architecture
Les erreurs les plus fréquentes
Mettre de la logique métier dans un workflow technique
C'est l'erreur classique des équipes qui démarrent sur Campaign. Un workflow technique qui construit des populations et déclenche des envois — ça fonctionne, mais ça court-circuite les typologies, les règles de pression et le plan marketing. Le suivi devient impossible pour les équipes marketing.
Créer des workflows de campagne pour des tâches récurrentes
À l'inverse, créer un workflow de campagne pour synchroniser des données toutes les nuits c'est placer une logique infrastructure dans le plan marketing. Ça pollue le calendrier des campagnes et complique la supervision technique.
Confondre workflow de campagne et workflow opérationnel
Dans certaines versions et configurations d'ACC, il existe aussi des workflows au niveau des opérations récurrentes et des campagnes continues. Ces workflows sont des workflows de campagne avec une logique de répétition — ils ne sont pas des workflows techniques même s'ils tournent en continu.
💡 Règle simple : si ça produit une diffusion ou construit une population marketing → workflow de campagne. Si ça maintient la plateforme, synchronise des données ou calcule des indicateurs → workflow technique.
Supervision et monitoring
Les deux types de workflows se supervisent différemment :
Workflows techniques — supervisés via Supervision → Workflows techniques. Une alerte rouge sur un workflow natif doit être traitée en priorité.
Workflows de campagne — visibles dans le plan marketing et dans les rapports de campagne. Les équipes marketing ont accès à leur suivi.
Sur les instances V8, l'interface de supervision est identique mais les performances d'exécution peuvent différer selon que les données manipulées sont en FDA Snowflake ou en base locale Campaign.
Conclusion
La distinction workflow technique / workflow de campagne n'est pas qu'une question d'organisation dans l'interface — c'est une question d'architecture et de gouvernance. Bien la respecter garantit que les équipes techniques et marketing travaillent dans leurs périmètres respectifs, que les typologies s'appliquent correctement et que la supervision reste lisible. C'est l'une des premières choses que j'explique quand j'arrive sur une nouvelle instance Campaign.
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 workflow
Lives in Administration → Technical workflows
Not attached to a campaign
Runs continuously or on a fixed schedule
Managed by technical teams
Invisible to marketing teams
Direct infrastructure impact
Campaign workflow
Lives inside a marketing campaign
Attached to an operation or programme
Triggered by a campaign or calendar
Managed by marketing / CRM teams
Visible in the marketing plan
Produces deliveries
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.
⚠️ Warning: never disable a native technical workflow without knowing exactly what it does. Some maintain data consistency — disabling them can cause side effects that are difficult to diagnose several days later.
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
Need
Workflow type
Sync data from a third-party system every night
Technical
Send a promotional email to a customer segment
Campaign
Purge delivery logs older than 6 months
Technical
Re-engage non-openers at D+3
Campaign
Calculate a customer engagement score each week
Technical
Build an A/B test population and send two variants
Campaign
Update quarantines from an external exclusion list
Technical
Trigger a welcome email at D+1 after registration
Either — depends on architecture
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.
💡 Simple rule: if it produces a delivery or builds a marketing population → campaign workflow. If it maintains the platform, syncs data or calculates indicators → technical workflow.
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.
Un projet Adobe Campaign à structurer ?An Adobe Campaign project to structure?
Architecture, gouvernance, montée en compétences — je peux vous accompagner. Réponse sous 24h.Architecture, governance, team upskilling — I can support you. Reply within 24 hours.