Adobe Campaign Standard Developer Expert cheat sheet
Adobe Campaign Standard Developer Expert · Keep the key ideas within reach.
Data model and schema design
Fields added to the Profile resource are stored in a separate extension table joined one-to-one to the profile table, so every extension adds a join cost to queries on that resource.
Custom resources and their fields use the cus namespace; internal names must be unique, start with a letter, and contain no spaces or special characters.
Publish after every data model change: unpublished fields are invisible to the query editor, personalization pickers, import mappings, and APIs.
Supported field types include string, long, integer, double, boolean, date, datetime, memo, and enumeration, plus link and collection for relations.
An enumeration stores the internal value name, not the display label; adding values is safe, renaming an internal name orphans existing records.
One-to-many is modeled as a collection on the parent; many-to-many requires an intermediate resource that holds one link to each side.
Target mapping fixes the target dimension of a delivery or workflow; the mapping's schema determines which fields personalization and typology rules can reference.
Adobe Campaign Standard exposes no custom SQL index creation; filter on standard indexed attributes such as profile identifier, email, and dates, and route index requests to Adobe support.
Removing a field from the schema does not delete the stored column data automatically; deprecate the label and stop using the field instead of repurposing it.
Workflow development and orchestration
The Query activity selects a targeting dimension and filters, and its outbound transition is a work table that downstream activities inherit unless reconciled to another dimension.
Query re-queries the database on its own targeting dimension, while Filter only applies conditions to the incoming transition population, which makes Filter the cheaper choice after a Query.
Deduplication requires a unique key and a sort order that decides which record survives; rejected records exit on the complement transition for separate handling.
AND-join releases a single transition only when both inbound branches arrive, and it needs a common key to reconcile them; Union stacks populations sharing the same dimension.
Segmentation splits one population with several successive filters in a single activity, avoiding a chain of separate queries.
Wait pauses a branch until a duration or date; an External signal resumes it, and workflows beginning with External signal can be started through the Workflow trigger API.
The Scheduler defines recurrence, and the workflow-level time zone overrides the operator's default, which matters for date-based personalization and send windows.
Restart re-runs from the failed activity using retained interim data; editing activities after a failure invalidates the saved state and forces a full restart.
Keep interim populations preserves work tables between executions for debugging and must be disabled in production to limit database growth.
Delivery configuration and personalization
A delivery template supplies target mapping, routing, from and reply-to addresses, typology, and default content; later template edits do not apply to deliveries already created.
Analysis builds the audience and applies typologies, quarantines, and duplicates; the send dispatches. Run analysis alone to review exclusions before scheduling.
A typology is an ordered set of rules evaluated at analysis: pressure and fatigue cap per-recipient frequency, capacity caps volume per execution, control checks content, filtering removes by query.
Pressure defers over-quota messages to later days, while fatigue excludes them outright; choose between them based on whether the message stays relevant later.
Exclusion causes are recorded per address and visible in the delivery audit and exclusion logs, which is the first place to check when counts drop.
Personalization outputs values with <%= profile.firstName %> and branches with <% if (condition) { %> content <% } %>; a missing field renders empty, so supply fallbacks.
Dynamic content variants are evaluated per recipient and the first matching condition wins; order the variants from most to least specific.
Proofs are sent to test profiles, which can be injected into the delivery target to preview personalization and check rendering and links before the real send.
Routing external accounts carry sender and IP configuration per channel, and URLs built with personalization must be encoded so tracking and click-through still resolve.
JavaScript, APIs, and platform scripting
The JavaScript code activity runs server-side once per workflow execution, unlike personalization tags, which are evaluated per recipient at send time.
Read data with xtk.queryDef.create(<queryDef .../>) followed by ExecuteQuery, and write data with xtk.session.Write using an XML document describing the record.
logInfo and logWarning write diagnostic messages to the workflow execution log, which is where code output is inspected after a run.
Workflow-level variables declared in workflow properties are reachable from code activities and from delivery personalization through the workflow variables object.
The REST API family covers Profiles and Services, Transactional Messaging, Workflow triggering, and API-enabled custom resources, and all calls authenticate with Adobe IMS OAuth server-to-server credentials.
The Transactional Messaging API sends one event-triggered message per call using a declared event and a transactional message template, returning an identifier used to trace the request.
A custom resource is exposed over REST only when the API option is enabled in its definition and the data model has been published.
The Workflow trigger API activates a workflow that starts with an External signal activity and passes a JSON payload the workflow can read downstream.
For volume, batch operations through imports or bulk endpoints beat per-record REST calls, because each call carries request overhead and rate limits.
Integrations, imports, and exports
The Load file activity imports delimited or fixed-width files from an external account and requires format, encoding, header handling, column mapping, a dedup key, and an update mode.
Load modes are insert only, update only, and insert-or-update; the choice depends on whether the key already exists, and the dedup key should be an indexed attribute.
The Extract file activity defines columns, sorting, format, and compression from an inbound transition, after which Transfer file pushes the result to SFTP or S3.
External accounts hold connection details and credentials for SFTP, S3, HTTP, and Adobe solutions, so activities reference the account rather than embedding credentials.
Compression such as gzip or zip is supported on both import and export, and large recurring exports should be compressed and split into multiple files.
Enable the reject file output on imports so invalid or duplicate lines are written with their reasons for review while valid lines continue processing.
Build file names from date or timestamp variables so recurring transfers never overwrite earlier files, and monitor the source folder for files processed once only.
For recurring loads, join staging data to profiles with Update data or Reconciliation instead of cramming lookups into the import column mapping.
Event-driven integrations include Adobe Experience Cloud Triggers and journey orchestration calling the transactional API, while audience sharing with Adobe Experience Platform uses a destination.
Administration, security, and access management
Users are created in Adobe Admin Console and reach Campaign through product profiles; in-product security groups add rights on resources, folders, and actions such as sending deliveries.
Rights are additive across groups, and there is no deny rule, so access is removed only by withdrawing the group that grants it.
Organizational units scope users, folders, and deliveries to part of the organization, so operators only see and act on objects that belong to their unit.
Folder permissions are granted per group on the folder tree, and the root folder marked for all units is visible to every operator.
The Control Panel is the hosted administration surface: it manages IP allowlists for instance and SFTP access, SSH keys, subdomains and DNS, and GPG keys.
Adobe Campaign Standard grants no operating system or direct database access; all administration happens through the interface, APIs, and the Control Panel.
Authentication runs through Adobe Identity Management with enterprise SSO and MFA options, so password policy is governed at identity level rather than inside Campaign.
The audit trail records logins, exports, and configuration changes chronologically and supports access reviews and compliance investigations.
Privacy access and delete requests are executed through the privacy core service, with deletion choosing between irreversible removal and update-without-data retention.
Technical workflows and API calls run under system operators rather than human accounts, which complicates attributing actions during audits.
Performance tuning, troubleshooting, and monitoring
Each activity stores its outbound population in a temporary work table prefixed wkf; the cleanup technical workflow purges them, and tables left by stopped workflows bloat the database.
The workflow journal shows per-activity duration and error messages; enable SQL query logging when the journal alone does not reveal the slow statement.
Common query cost drivers are unbounded date ranges, leading-wildcard LIKE filters, filters on non-indexed attributes, and joins into large extension tables.
Collapse Query-then-Filter chains into a single Query and switch recurring workflows to Incremental query so each run touches only new or modified records.
Place Deduplication and Segmentation before Enrichment and Delivery, since reducing row counts early makes every later activity cheaper.
Delivery diagnostics start with broad logs, exclusion causes, and rejection reasons; a sudden spike in exclusions usually traces to quarantine, typology, or capacity rules.
A running workflow cannot be edited; stop it, then restart, and the restart resumes from the last successful activity using retained interim populations.
The Alert activity plus workflow notification emails catch failures in recurring jobs, so monitoring effort goes to failed executions rather than individual sends.