Adobe Campaign Classic Developer Expert cheat sheet

A schema is identified by namespace:name (nms, xtk, cus); the default SQL table concatenates both, so nms:recipient maps to NmsRecipient unless sqltable overrides it.

A element with a child declares the primary key; non-internal elements create unique or performance indexes.

Link cardinalities are declared with link="1-1", "1-N", "N-1", or "N-N"; revLink names the automatically generated reverse link and externalJoin="true" creates a link without a database foreign key.

declares a database column; unbound="true" stores multivalued values in a separate table, and expr declares a computed field that is evaluated at query time and never stored.

A schema declared with extends="nms:recipient" in the cus namespace adds its fields to the parent schema; added columns must be nullable or carry a default when the table already holds rows.

The enum attribute on a field references an ; the database stores the enumerated value name, while the label is only displayed in the interface.

Schema edits are metadata only until Tools > Advanced > Update database runs and generates the corresponding CREATE/ALTER statements against the physical database.

A transition carries the target population produced by its upstream activity; a downstream activity starts only when every inbound transition is activated.

Targeting activities write temporary work tables whose names carry the wkf prefix; these tables are dropped when the workflow instance finishes.

The Query activity filters the targeting schema and supports $(vars.name) substitution inside conditions for values computed earlier in the workflow.

An Incremental query stores the last value of a chosen date field and selects only records newer than that value on the next run.

AND-join waits for all inbound branches and emits one merged transition; Union merges populations, optionally removing duplicates.

Enrichment adds columns from another schema through a link or an explicit join, and its filtering options can reduce the target.

Signal and External signal synchronize workflows: External signal targets a workflow and signal, while Signal receives the activation.

vars is scoped to one workflow, task.vars to one activity, and instance.vars is shared across all workflows on the server.

Enabling Continue in case of error lets downstream branches run after an activity failure; without it the workflow stops at the failing activity.

JavaScript activities run server-side ECMAScript without a browser DOM; logInfo, logWarning, and logError write entries to the workflow journal.

xtk.queryDef.create(<queryDef .../>) builds a query object and ExecuteQuery() runs it, returning an XML result that is iterated in JavaScript.

The queryDef operation attribute accepts select, get, count, update, insert, or delete; the schema attribute names the targeting schema.

sqlSelect("SELECT ...") returns an array of row objects, while sqlExec("UPDATE ...") runs statements that produce no result set.

QueryDef conditions reference schema fields as @fieldName and can call SQL functions such as GetDate() for the current timestamp.

The $(vars.name) syntax substitutes workflow variables before SQL execution; plain string concatenation is not escaped by the platform.

xtk.session.Write(record) creates or updates a record from JavaScript, using the same schema-based record object model as the interface.

JavaScript libraries are loaded with loadLibrary and expose their functions globally to the activity or page that loads them.

<%= expression %> outputs the evaluated value into the content, while <% code %> executes JavaScript without emitting output.

Delivery content reads target fields directly as recipient.firstName; fields added on the Additional data tab are exposed through the targetData schema.

The directive <%@ include view="name" %> inserts a reusable content block stored in nms:contentBlock into a delivery or page.

Conditional content uses <% if (condition) { %> ... <% } else { %> ... <% } %> and is evaluated separately for each recipient at send time.

Content blocks are typed (HTML, text, URL, image) and are shared across deliveries; editing a block changes every delivery that includes it.

In a multi-language delivery each language code has its own content variant, selected from the recipient's language field at send time.

The mirror page and unsubscription link are inserted with dedicated personalization blocks or system include directives.

Dynamic content is evaluated per recipient at send time; the Preview tab evaluates it against a chosen target record.

The target mapping links a delivery to its targeting schema and defines which fields supply the email address, first name, and similar attributes.

Prepare (analysis) builds the target, applies typology rules, and personalizes content; Send dispatches the message and requires a successful prepare.

Routing is resolved through an external account that selects the execution server and IP affinity; direct mail uses a confirm step instead of send.

Delivery templates supply default content, target mapping, routing, typology, and properties, and are referenced by deliveries and workflow activities.

Seed addresses receive copies of a delivery for rendering and deliverability checks and are not counted as target recipients.

Delivery status moves through edition, prepared, sent, failed, or cancelled; a failed prepare blocks the send command.

Target approval and content approval can be required in the delivery properties; the send waits until the approval is granted.

Wave scheduling splits a target into successive sends, and pressure typology rules can cap the number of messages per recipient per period.

The From and Reply-to headers are visible to the recipient, while the Return-Path address receives bounces for the delivery.

The SOAP router is exposed at /nl/jsp/soaprouter.jsp; Logon on xtk:session returns a session token that later calls must pass as sessiontoken.

QueryDef over SOAP supports select, get, count, update, insert, and delete operations, and returns results as XML documents.

Import and export templates define file format, source or target schema, and field mapping, and are reused by the Import and Export activities.

File transfer and file loading activities move files through external accounts such as SFTP servers before data is loaded into a schema.

Federated Data Access maps tables from an external database as schemas and queries them remotely without importing the rows.

Mid-sourcing routes deliveries to a remote execution instance configured through an external account, separating targeting from sending.

Message Center sends transactional messages triggered by events or API calls through a dedicated execution instance.

CRM connectors such as Salesforce and Microsoft Dynamics synchronize data through external accounts and dedicated workflows.

Named rights such as admin, workflow, webapp, and delivery grant platform capabilities, while folder permissions grant access to data.

Folder permissions propagate to subfolders, and an operator's effective rights are the union of rights from all groups they belong to.

A security zone restricts connections by IP address range and optionally by operator, and is checked when the operator logs on.

Typology rule types are filtering, control, pressure, and capacity; rules are grouped into typologies and applied to deliveries.

A control rule evaluates a condition during analysis and raises a warning or an error; an error blocks the delivery from being sent.

A filtering rule excludes part of the target by applying a query on the delivery's targeting dimension.

A pressure rule caps messages per recipient over a period, and a capacity rule caps the total number of messages for a delivery.

Quarantine holds invalid addresses; quarantined addresses are excluded from targeting until an operator releases them.

Delivery priority determines send order between deliveries, and IP affinities group IP addresses for routing decisions.

A web application is built from pages; a form page binds input fields to the targeting schema and a storage step writes the submitted values.

Preloading loads an existing record into the form, typically using a recipient identifier passed as a URL parameter.

The ctx object exposes request parameters and context variables to server-side JavaScript in web application pages.

Captcha can be enabled on a page so that submissions require a human-readable code and automated posts are rejected.

A web application can activate a workflow through a signal, letting form submission start backend processing.

Multi-language web applications use per-language translations, selected from the visitor's language or a URL parameter.

A web application must be published before it is reachable; its URL is built from the instance address and the web application identifier.

The built-in unsubscription web application updates the recipient's opt-out flag and can be customized like any other web application.

A schema is identified by namespace:name (nms, xtk, cus); the default SQL table concatenates both, so nms:recipient maps to NmsRecipient unless sqltable overrides it.

A element with a child declares the primary key; non-internal elements create unique or performance indexes.

Link cardinalities are declared with link="1-1", "1-N", "N-1", or "N-N"; revLink names the automatically generated reverse link and externalJoin="true" creates a link without a database foreign key.

declares a database column; unbound="true" stores multivalued values in a separate table, and expr declares a computed field that is evaluated at query time and never stored.

A schema declared with extends="nms:recipient" in the cus namespace adds its fields to the parent schema; added columns must be nullable or carry a default when the table already holds rows.

The enum attribute on a field references an ; the database stores the enumerated value name, while the label is only displayed in the interface.

Schema edits are metadata only until Tools > Advanced > Update database runs and generates the corresponding CREATE/ALTER statements against the physical database.

A transition carries the target population produced by its upstream activity; a downstream activity starts only when every inbound transition is activated.

Targeting activities write temporary work tables whose names carry the wkf prefix; these tables are dropped when the workflow instance finishes.

The Query activity filters the targeting schema and supports $(vars.name) substitution inside conditions for values computed earlier in the workflow.

An Incremental query stores the last value of a chosen date field and selects only records newer than that value on the next run.

AND-join waits for all inbound branches and emits one merged transition; Union merges populations, optionally removing duplicates.

Enrichment adds columns from another schema through a link or an explicit join, and its filtering options can reduce the target.

Signal and External signal synchronize workflows: External signal targets a workflow and signal, while Signal receives the activation.

vars is scoped to one workflow, task.vars to one activity, and instance.vars is shared across all workflows on the server.

Enabling Continue in case of error lets downstream branches run after an activity failure; without it the workflow stops at the failing activity.

JavaScript activities run server-side ECMAScript without a browser DOM; logInfo, logWarning, and logError write entries to the workflow journal.

xtk.queryDef.create(<queryDef .../>) builds a query object and ExecuteQuery() runs it, returning an XML result that is iterated in JavaScript.

The queryDef operation attribute accepts select, get, count, update, insert, or delete; the schema attribute names the targeting schema.

sqlSelect("SELECT ...") returns an array of row objects, while sqlExec("UPDATE ...") runs statements that produce no result set.

QueryDef conditions reference schema fields as @fieldName and can call SQL functions such as GetDate() for the current timestamp.

The $(vars.name) syntax substitutes workflow variables before SQL execution; plain string concatenation is not escaped by the platform.

xtk.session.Write(record) creates or updates a record from JavaScript, using the same schema-based record object model as the interface.

JavaScript libraries are loaded with loadLibrary and expose their functions globally to the activity or page that loads them.

<%= expression %> outputs the evaluated value into the content, while <% code %> executes JavaScript without emitting output.

Delivery content reads target fields directly as recipient.firstName; fields added on the Additional data tab are exposed through the targetData schema.

The directive <%@ include view="name" %> inserts a reusable content block stored in nms:contentBlock into a delivery or page.

Conditional content uses <% if (condition) { %> ... <% } else { %> ... <% } %> and is evaluated separately for each recipient at send time.

Content blocks are typed (HTML, text, URL, image) and are shared across deliveries; editing a block changes every delivery that includes it.

In a multi-language delivery each language code has its own content variant, selected from the recipient's language field at send time.

The mirror page and unsubscription link are inserted with dedicated personalization blocks or system include directives.

Dynamic content is evaluated per recipient at send time; the Preview tab evaluates it against a chosen target record.

The target mapping links a delivery to its targeting schema and defines which fields supply the email address, first name, and similar attributes.

Prepare (analysis) builds the target, applies typology rules, and personalizes content; Send dispatches the message and requires a successful prepare.

Routing is resolved through an external account that selects the execution server and IP affinity; direct mail uses a confirm step instead of send.

Delivery templates supply default content, target mapping, routing, typology, and properties, and are referenced by deliveries and workflow activities.

Seed addresses receive copies of a delivery for rendering and deliverability checks and are not counted as target recipients.

Delivery status moves through edition, prepared, sent, failed, or cancelled; a failed prepare blocks the send command.

Target approval and content approval can be required in the delivery properties; the send waits until the approval is granted.

Wave scheduling splits a target into successive sends, and pressure typology rules can cap the number of messages per recipient per period.

The From and Reply-to headers are visible to the recipient, while the Return-Path address receives bounces for the delivery.

The SOAP router is exposed at /nl/jsp/soaprouter.jsp; Logon on xtk:session returns a session token that later calls must pass as sessiontoken.

QueryDef over SOAP supports select, get, count, update, insert, and delete operations, and returns results as XML documents.

Import and export templates define file format, source or target schema, and field mapping, and are reused by the Import and Export activities.

File transfer and file loading activities move files through external accounts such as SFTP servers before data is loaded into a schema.

Federated Data Access maps tables from an external database as schemas and queries them remotely without importing the rows.

Mid-sourcing routes deliveries to a remote execution instance configured through an external account, separating targeting from sending.

Message Center sends transactional messages triggered by events or API calls through a dedicated execution instance.

CRM connectors such as Salesforce and Microsoft Dynamics synchronize data through external accounts and dedicated workflows.

Named rights such as admin, workflow, webapp, and delivery grant platform capabilities, while folder permissions grant access to data.

Folder permissions propagate to subfolders, and an operator's effective rights are the union of rights from all groups they belong to.

A security zone restricts connections by IP address range and optionally by operator, and is checked when the operator logs on.

Typology rule types are filtering, control, pressure, and capacity; rules are grouped into typologies and applied to deliveries.

A control rule evaluates a condition during analysis and raises a warning or an error; an error blocks the delivery from being sent.

A filtering rule excludes part of the target by applying a query on the delivery's targeting dimension.

A pressure rule caps messages per recipient over a period, and a capacity rule caps the total number of messages for a delivery.

Quarantine holds invalid addresses; quarantined addresses are excluded from targeting until an operator releases them.

Delivery priority determines send order between deliveries, and IP affinities group IP addresses for routing decisions.

A web application is built from pages; a form page binds input fields to the targeting schema and a storage step writes the submitted values.

Preloading loads an existing record into the form, typically using a recipient identifier passed as a URL parameter.

The ctx object exposes request parameters and context variables to server-side JavaScript in web application pages.

Captcha can be enabled on a page so that submissions require a human-readable code and automated posts are rejected.

A web application can activate a workflow through a signal, letting form submission start backend processing.

Multi-language web applications use per-language translations, selected from the visitor's language or a URL parameter.

A web application must be published before it is reachable; its URL is built from the instance address and the web application identifier.

The built-in unsubscription web application updates the recipient's opt-out flag and can be customized like any other web application.