Adobe Campaign Classic Business Practitioner Expert common mistakes
Adobe Campaign Classic Business Practitioner Expert · Understand the traps and how to avoid them.
Treating a workflow's targeting dimension as a free choice, building a delivery workflow on the wrong dimension (e.g., recipients vs. seeds or a custom schema) and then wondering why personalization fields or delivery mapping fail.
Candidates memorize that workflows have a targeting dimension but never connect it to the delivery mapping and the schema the delivery is bound to, so they pick the dimension that 'sounds right' rather than the one the delivery template requires.
What to do instead
Before building, identify the delivery template's target mapping and the schema it resolves to, then set the workflow's targeting and filtering dimensions to match. Verify by checking that personalization fields from that schema resolve in the delivery preview.
Declaring a schema field as a string or integer when the business rule needs enumeration, date, or a reference/link to another table, then discovering filtering and joins behave incorrectly downstream.
Candidates focus on getting the field to store a value at all and skip the type-and-relationship design step, underestimating how much targeting, segmentation, and reporting depend on correct types and links.
What to do instead
Design the schema on paper first: list each attribute, its data type, whether it is an enumerator, and whether it needs a link (foreign key) to another schema. Implement links with the correct integrity and cardinality, then test a query and a filter on each field.
Adding a new field to a schema and expecting it to appear immediately in the UI or in queries without extending the relevant input form or restarting/refreshing the relevant caches and modules.
Candidates assume schema edits are instantly and universally reflected, but UI forms, list configurations, and some runtime components read from separate definitions that must be extended or refreshed.
What to do instead
After a schema change, extend the relevant input form and list definition to expose the field, then apply the documented cache/module refresh step for the instance before validating in the UI and in a query activity.
Building segmentation logic with overlapping or non-exhaustive criteria and assuming the workflow will 'just' produce the intended audience, without checking counts at each step.
Candidates jump straight to the delivery and treat the query/intersection/union activities as plumbing, so they never validate that the segment sizes add up or that exclusions actually removed the right people.
What to do instead
Add a temporary population-count or log step after each segmentation activity and reconcile the numbers against expected totals. Explicitly test overlap (intersection) and gap (union) cases with small known populations before scaling up.
Misconfiguring delivery execution options such as scheduling, approval, typology rules, or proof settings, then producing a delivery that sends at the wrong time, skips required approval, or ignores pressure/contact rules.
Candidates concentrate on content and audience and treat delivery properties as defaults, missing that scheduling, approvals, and typology are configured per delivery or per template and interact with campaign-level settings.
What to do instead
Walk the delivery properties tab by tab: scheduling and time zone, approval and proof recipients, target mapping, and typology rules. Send proofs and confirm the approval path before scheduling a real send.
Writing personalization that references fields not present in the targeting schema or that breaks when a value is null, and only discovering it at send time or in a partial preview.
Candidates test personalization on a single well-populated record and assume the expression is universally safe, ignoring null handling and schema scope.
What to do instead
Test personalization against a sample that includes null and edge-case records, use default-value fallbacks for optional fields, and confirm every referenced field exists on the delivery's targeting schema before approving.
Designing workflow orchestration with no error handling, no restart strategy, and no idempotency, so a mid-run failure leaves partial data or duplicate sends.
Candidates build the happy path and stop, without considering what happens when a step fails, is retried, or is run twice, which is exactly what production operations require.
What to do instead
Add explicit error transitions, use signaling and wait activities to coordinate branches, design steps to be safely re-runnable (deduplicate or check for existing records), and document restart points. Test by forcing a failure mid-workflow.
Assuming tracking and reporting metrics are available immediately or interpreting delivery indicators without accounting for opens being inferred from pixel loads and clicks being the stronger signal.
Candidates treat reporting as a passive readout and do not consider data collection latency, image blocking, or the difference between delivered, open, and click definitions.
What to do instead
Learn the definition and lag of each indicator, wait for the documented collection window before analyzing, and prefer click-based and conversion-based measures over opens when drawing conclusions. Cross-check report totals against the delivery's own indicators.
Importing data with a mismatched file format, delimiter, encoding, or reconciliation key, producing duplicates or rejected lines that are not investigated.
Candidates configure an import, see it complete, and assume success, without checking the rejection log, reconciliation mode, or whether the import should update or insert.
What to do instead
Run imports in simulation or with a small sample first, explicitly set file format, encoding, and reconciliation key, and always review the rejection and duplicate reports before running the full import.
Granting broad operator rights or ignoring data-privacy and consent requirements when designing targeting and exports, treating security and compliance as an afterthought.
Candidates are focused on functional delivery and assume the administrator handles access and privacy, but the practitioner's design decisions (who can see what, what data leaves the system, whether consent was honored) are where compliance actually lives.
What to do instead
Apply least-privilege operator roles and folder permissions in the design, restrict exports of personal data, and build consent and suppression checks into targeting before any delivery or export. Confirm retention and privacy requirements with the governance owner.