Adobe Campaign Classic Architect Master common mistakes
Adobe Campaign Classic Architect Master · Understand the traps and how to avoid them.
Designing a solution around a single monolithic workflow that handles ingestion, segmentation, delivery, and post-processing instead of decomposing it into chained workflows with explicit handoffs and restart points.
Candidates who have only maintained small tactical workflows default to one big workflow because it feels easier to trace end to end, and they underestimate how a mid-run failure forces a full restart and how hard a monolith is to parallelize or schedule independently.
What to do instead
Decompose by responsibility (import, enrichment, segmentation, delivery, reporting), pass state through a persistent staging table or a signal activity rather than in-memory variables, and describe each workflow's trigger, idempotency key, and restart semantics in the design answer.
Proposing a new custom schema for data that the standard recipient, delivery, or tracking schemas already model, then discovering reconciliation, deduplication, and reporting gaps later.
Candidates reason from the source system's entity names rather than from Campaign's built-in model, and they do not enumerate which standard tables, queries, and delivery logs already reference the standard schema.
What to do instead
Before adding a schema, map each field to the standard model, justify any extension as a schema extension on the standard schema where cardinality allows, and only create standalone schemas for genuinely new entities with their own lifecycle and keys.
Choosing a link type and key without stating the cardinality, the target key, and the deletion behavior, leaving orphaned or duplicated rows after imports and segmentation.
Candidates treat links as simple joins and skip the 1-1 versus 1-N versus N-N decision, the external/internal key choice, and referential integrity options, which only surface as bugs when data is loaded or deleted.
What to do instead
For every link, state cardinality, owning side, join key, and whether the link is internal (foreign key) or a collection, and define deduplication keys and cascade or set-null behavior explicitly in the data model answer.
Answering a workflow automation question with a scheduled start and no handling for overlapping runs, partial failures, or re-entrancy, so a slow run collides with the next scheduled run.
Candidates focus on the happy-path trigger and forget that schedulers fire regardless of whether the prior instance finished, and they do not consider that activities can be retried or resumed.
What to do instead
Add a concurrency guard (a lock row or status flag checked at start), make each activity idempotent or keyed, define error handling per activity, and specify whether the workflow resumes, restarts, or aborts on failure.
Treating workflow variables and activity output as durable state across workflow restarts, so resumed runs read stale or empty values.
Candidates test only successful full runs, where in-memory variables persist for the run, and never exercise the restart path where variables are reinitialized and prior activity outputs are not replayed.
What to do instead
Persist any state needed after a restart in a database table or the workflow's persistent variables, re-derive transient values on resume, and design activities so that re-execution after a restart produces the same result.
Describing an API integration as a direct synchronous call from a workflow or web app into Campaign without covering authentication, throttling, batching, and failure retry.
Candidates know the endpoint exists but not the operational envelope: session or token lifecycle, per-call overhead, payload limits, and what happens when the remote system is slow or down.
What to do instead
Specify the auth mechanism and credential storage, batch size and rate limits, timeout and retry with backoff, dead-letter handling, and whether the integration should be pull-based via import or push-based via a SOAP/REST call, with the tradeoff justified.
Sizing an instance by license count or recipient volume alone, ignoring peak concurrent workflow load, delivery throughput, and database I/O during send windows.
Candidates equate marketing database size with infrastructure need and have not modeled the concurrency of imports, segmentations, and personalization queries that all hit the database at send time.
What to do instead
Size against peak concurrent workload: number of simultaneous deliveries, personalization query cost, import volume per window, and retention of tracking and delivery logs, and state the assumptions and headroom explicitly.
Proposing broad operator group membership or folder permissions to solve an access problem instead of scoping rights to the minimum needed.
Candidates reason from 'make it work' and grant a powerful group because enumerating granular rights and folder-level permissions is tedious, and they do not connect over-permissioning to audit and segregation-of-duties findings.
What to do instead
Map each role to the specific named rights and folder permissions it needs, separate production send rights from design rights, and describe how the assignment is reviewed and revoked, not just granted.
Promoting a package or schema change from development to production without a documented dependency order, rollback path, or database structure update step.
Candidates treat deployment as copying a package and forget that schema changes require a database structure update, that dependencies between packages must be ordered, and that a failed update may not be cleanly reversible.
What to do instead
Define the deployment sequence (schema and structure update, then data, then workflows and templates), list package dependencies in order, take a pre-deployment backup, and state the rollback procedure and validation checks for each step.
Extending behavior with ad hoc JavaScript in a workflow activity or web app without considering execution context, error propagation, and maintainability, rather than using the supported extension points.
Candidates reach for inline script because it is fast to write and they are unsure which hooks, JSSP pages, or custom activities are the sanctioned extension points, so they produce code that is hard to test and breaks on upgrade.
What to do instead
Choose the extension point deliberately (schema methods, workflow custom activity, JSSP page, or client-side form extension), keep business logic out of inline script where it can live in a reusable library, and document error handling, logging, and upgrade impact.
Diagnosing a delivery or workflow problem by re-running the job before capturing logs, database state, and the failing step, destroying the evidence needed to find the root cause.
Candidates are under pressure to restore service and treat re-run as harmless, not realizing that a re-run overwrites statuses and that intermittent failures are the hardest to reproduce.
What to do instead
Capture the workflow log, delivery log, and relevant table state first, identify the failing activity and error code, form a hypothesis, then re-run only after the evidence is recorded and the fix is in place.