Adobe Campaign Classic Developer Expert common mistakes
Adobe Campaign Classic Developer Expert · Understand the traps and how to avoid them.
Adding custom fields by editing the built-in nms:recipient schema directly instead of creating an extension schema.
Built-in schemas look editable in the schema editor, and candidates with SQL table experience assume direct modification is normal; in Campaign, built-in schemas are shipped definitions and direct edits are overwritten or blocked.
What to do instead
Create a custom schema with extends="nms:recipient", declare only new fields, and reference it through the extension. Verify the extension appears under the recipient schema and never alter the built-in XML.
Adding a field to a schema and immediately using it in a query, workflow, or delivery without updating the database structure.
Schema XML is metadata; the physical column is not created until the database update wizard or package installation runs. The field appears in the UI, so candidates assume it is usable.
What to do instead
After schema changes, run the database structure update and confirm the column exists in the physical table. When packaging, include the schema and the database update step, then test a query that selects the new field.
Joining two workflow populations on a non-unique key and assuming the join is one-to-one, so rows multiply or the workflow fails on duplicate keys.
The Join activity can default to a cardinality that does not match the data, and early transition counts may look plausible. Candidates focus on the join condition and ignore cardinality and duplicate keys.
What to do instead
Set the join cardinality explicitly, deduplicate or aggregate the population before joining, and inspect transition counts after each activity. Use a Deduplicate activity when uniqueness is required.
Using Change dimension without confirming a valid reconciliation link, or selecting the wrong targeting dimension, so the target becomes empty or records are misattributed.
Change dimension requires a link from the current dimension to the destination; candidates treat it as a simple filter and do not check the link or its cardinality.
What to do instead
Verify that the required link exists between the schemas, confirm its cardinality, and configure the reconciliation settings. Preview counts before and after the activity and test with a small population.
Writing raw SQL in a JavaScript activity using schema attribute names such as @recipientId, or using sqlExec for a query that must return rows.
Campaign's schema-level query syntax uses @attribute, while physical SQL uses actual column names. Candidates mix the two layers, and sqlExec is often used for statements that do not return a result set.
What to do instead
Use queryDef or schema-aware query activities for schema attribute expressions. For raw SQL, use physical table and column names and the correct execution method that handles result sets. Avoid string concatenation; bind values through supported placeholders and validate input types.
Referencing recipient fields such as recipient.firstName in a delivery whose target is a temporary workflow schema.
Personalization resolves against the delivery's targeting dimension. A temporary workflow population does not automatically expose recipient fields, but preview may still show a value from a fallback or test profile.
What to do instead
Map required recipient fields into the delivery target, or reference the correct target context such as targetData. Run analysis and a proof against a real target from the workflow, not only a manually selected test profile.
Configuring typology rules but not associating the typology with the delivery template or the delivery, so pressure and control rules never execute.
Rules exist in the typology but are only applied when the typology is attached to the delivery or its template. Candidates test a single delivery and assume the rule is globally active.
What to do instead
Attach the typology at the delivery template level and confirm it in the delivery properties. Run the delivery analysis and inspect the typology log to verify which rules were evaluated.
Calling the SOAP API with xtk:session Logon but not passing the returned session token on subsequent calls, or never logging out.
Candidates with REST experience expect stateless authentication. Campaign SOAP requires the session token in the SOAP header for each call, and abandoned sessions consume resources.
What to do instead
Store the session token returned by Logon, include it in the SOAP header of every subsequent call, and call Logout in a finally block. Test the full sequence with a non-admin operator account.
Granting folder permissions only and expecting an operator to be able to execute workflows or submit deliveries.
Campaign separates folder-level access from functional named rights and operator group rights. The UI may allow viewing a workflow while execution or delivery submission is still denied.
What to do instead
Assign the appropriate operator group and named rights for workflow execution and delivery preparation or submission. Test the exact action with a non-admin operator in the relevant folder.
Building a web application form and testing it only in preview, without publishing it or validating ctx input on the server side.
Preview shows the current draft, while the public URL serves the published version. ctx parameters are client-controllable, but the form may rely on them for storage or display without server validation.
What to do instead
Publish and approve the web application, then test the public URL. Validate and sanitize all ctx values on the server side, map fields explicitly to the target schema, and confirm storage behavior with a real submission.