AD0-E314 Practice Questions

In Adobe Campaign Classic, a delivery activity within a workflow is an instance created from a specified delivery template. The template serves as a blueprint, and its properties are copied to the delivery activity at the time of creation. Any modifications made directly to the delivery activity are local to that specific instance and do not alter the original template. Consequently, the next time the same template is used to create a new delivery, it will be based on the original, unchanged blueprint, and will not include any of the previous instance-specific modifications. To ensure changes are propagated to all future deliveries, the source template must be updated.

A. Modifying a delivery instance does not corrupt the source template. The system is designed to keep templates and their instances separate, preventing such errors.

C. The system does not track changes made to a delivery instance and then prompt for HTML confirmation when the source template is used again.

D. There is no default behavior in Adobe Campaign that prompts for a general confirmation of changes when reusing a template after one of its instances has been modified.

1. Adobe Experience League. (n.d.). Delivery templates. Adobe Campaign Classic v7 Documentation.

Section: About delivery templates.

Quote/Concept: "When you create a new delivery... you choose a template from which properties will be copied." This confirms that the delivery is a copy

not a live link. Changes to the copy (the delivery activity) will not affect the original (the template).

2. Adobe Experience League. (n.d.). Delivery. Adobe Campaign Classic v7 Documentation.

Section: Configuration.

Concept: The documentation shows that the delivery activity is configured by selecting a template. This establishes the one-way relationship where the template defines the initial state of the activity

but the activity does not write changes back to the template.

3. Adobe Experience League. (n.d.). Workflow best practices. Adobe Campaign Classic v7 Documentation.

Section: General recommendations.

Concept: The guide recommends using templates for deliveries "to save time and ensure consistency." This principle is violated if changes are made in the delivery activity

as consistency is lost for future executions. The master template must be the single source of truth for consistent properties.

Before a practitioner can add and configure a Delivery activity within an Adobe Campaign workflow, they must first determine the communication channel (e.g., email, SMS, push notification). This decision is the most fundamental prerequisite because the choice of channel dictates which delivery template will be used, how the content will be structured, and what specific delivery properties need to be configured. The entire setup of the Delivery activity is contingent on the selected channel.

B. target: The target audience is defined by upstream activities in the workflow, such as a Query or Segmentation, which then feed into the Delivery activity.

C. template: A delivery template is selected during the configuration of the Delivery activity, and the choice of template is dependent on the pre-determined channel.

D. content: The message content is created or specified within the Delivery activity itself, a step that occurs after the channel and template have been established.

1. Adobe Experience League - Campaign Classic v7 Documentation

"Delivery templates": This document clarifies that delivery templates are fundamentally tied to a specific channel. It states

"For each channel

a default template is available... When you create a new delivery... you must choose a template." This shows that the channel is the organizing principle for templates. (See the section "About delivery templates").

2. Adobe Experience League - Campaign Classic v7 Documentation

"Delivery (workflow activity)": The configuration steps for the Delivery activity involve selecting a delivery template. As established by the source above

templates are channel-specific. Therefore

a decision on the channel must precede the selection of a template and the subsequent configuration of the delivery. (See the section "Configuration").

When the 'Multiple approval' option is enabled for an Approval activity in an Adobe Campaign workflow, the task is sent to all operators in the specified group. The workflow logic is configured to proceed as soon as a single operator approves the task. The first approval received triggers the 'Yes' transition, and the workflow continues down that branch. Any subsequent responses from other operators, including rejections, are then ignored for the purpose of path selection.

A. The No Branch is run.

This is incorrect. The 'No' branch is only activated if all assigned operators reject the task, or if the approval deadline is reached without any approvals.

B. Neither Branch is run.

This is incorrect. The workflow does not halt; an approval was received, which is a defined trigger for a transition, so one of the branches must be executed.

D. Both the Yes and No Branch are run.

This is incorrect. A workflow activity can only activate a single outbound transition upon completion. It is logically impossible for both branches to execute simultaneously.

1. Adobe Campaign Classic v7 Documentation

"Approval" activity:

Section: Action activities > Approval > Properties of the activity

Quote: "If the Multiple approval option is selected

the task is assigned to several operators (operators of a group or a list of operators). The approval of a single operator is enough to activate the 'Yes' transition." This source directly confirms that the first approval validates the 'Yes' branch

irrespective of other operators' actions.

A recurring delivery is designed to create a new, distinct delivery instance each time its parent workflow is executed. Since the scheduler runs weekly, the recurring delivery will create 3 separate records in the delivery table (nms:delivery) over 3 weeks.

Conversely, a continuous delivery creates only a single delivery instance upon its first execution. Subsequent executions by the scheduler do not create new delivery records; they simply add new target populations to the existing delivery. Therefore, the continuous delivery contributes only 1 record to the table.

The total number of records is the sum from both delivery types: 3 (from recurring) + 1 (from continuous) = 4.

B. 2: This would be the correct count after only the first week's execution (one recurring and one continuous).

C. 6: This would be the result if both deliveries were recurring, creating two new records each week for three weeks.

D. 3: This incorrectly omits the single, persistent record created by the continuous delivery.

1. Adobe Campaign Classic v7 Documentation

"Recurring delivery": "A recurring delivery is based on a delivery template. For each execution of the workflow

a new delivery is created by duplicating this template." This confirms that a new delivery record is created upon each execution. (Found under Campaign Management > Deliveries > About recurring and continuous deliveries).

2. Adobe Campaign Classic v7 Documentation

"Continuous delivery": "Unlike a recurring delivery

a continuous delivery creates only one delivery instance and the logs are added to this same delivery... For each execution of the workflow

only the delivery analysis and sending are re-executed to take into account new recipients." This confirms only one delivery record is ever created. (Found under Campaign Management > Deliveries > About recurring and continuous deliveries).

3. Adobe Campaign Classic v7 Documentation

"Scheduler": "The Scheduler activity lets you trigger the execution of a workflow according to a defined schedule." This establishes the weekly trigger mechanism that causes the deliveries to be executed three times over the three-week period. (Found under Workflows > Activities > Execution flow activities).

The standard and most direct method to add an additional workflow to an existing campaign in Adobe Campaign Classic is through the campaign's user interface. The "Targeting and workflows" tab is specifically designed for this purpose. A Campaign Business Practitioner would navigate to this tab and use the "Add" or "new workflow" icon in the toolbar to create and link a new, separate workflow to the campaign. This practice allows for clear organization and management of multiple distinct processes, such as audience segmentation, data enrichment, or delivery execution, all within the context of a single campaign.

B. While you can add logic to an existing workflow, the requirement is for an additional workflow, which implies a separate process. This option suggests an alternative design, not the method to add a new workflow.

C. Technical workflows are for platform administration and maintenance, not for campaign-specific logic. They are not managed within the campaign's context and this approach is against best practices.

D. This statement is factually incorrect. Adobe Campaign Classic explicitly supports adding multiple workflows to a single campaign to manage complex marketing processes.

1. Adobe Experience League - Campaign Classic v7 Documentation

"Targeting and workflows": This document details the functionality of the campaign's "Targeting and workflows" tab. It states

"The Targeting and workflows tab lets you build your target and create the deliveries for your campaign. ... You can add as many workflows as you need." It also visually indicates the "Add" button used to create a new workflow within the campaign.

2. Adobe Experience League - Campaign Classic v7 Documentation

"About campaign workflows": This section clarifies the nature of campaign workflows. It specifies

"A campaign workflow is used to create and configure the processes involved in a campaign: targeting

deliveries

notifications

testing

etc. It is created and stored in a specific campaign." This confirms that workflows are added directly from the campaign itself.

To validate all variations of conditional content within an email, a Business Practitioner must use proofing methods that allow for systematic testing against different recipient profiles.

1. Defined proof target: Selecting specific profiles that belong to each target segment and adding them to a proof group ensures each content variation is generated and sent for review.

2. Seed addresses: If seed addresses are set up as profiles belonging to the different segments, they can be targeted for proofs to systematically review each content variation.

3. Substitution with a fixed profile: This allows sending a proof to a single email address (e.g., the practitioner's) while personalizing it with data from a specific, chosen profile. By repeating this process for a profile from each segment, all variations can be tested.

C. Proof with Substitution of address with a random profile: This method is for spot-checking personalization with a random profile from the target audience. It does not guarantee that all content variations will be generated for review.

1. Adobe Experience League - Campaign Classic v7 Documentation

"Sending proofs": This document outlines the various methods for sending proofs.

Section: "Define the proof target": It states

"You can also select recipients directly and use them as the proof target." This validates option A.

Section: "Define the proof target": It also explains the use of seed addresses for proofs: "You can designate some of the recipients in the target as seed addresses." This validates option B.

Section: "Substitution of addresses": This section details the substitution feature: "The content of the proof is personalized with data from a profile chosen at random or specified." Choosing a specified profile validates option D as a method to systematically test a profile from each segment. The same section describes the random option

confirming it is not a systematic approach

thus invalidating option C for this specific use case.

To send a proof to a seed list in Adobe Campaign, the practitioner must first initiate the proofing process for a specific delivery. In the "Send a proof" dialog box that appears, the user must select "Seed addresses" as the target recipient. This action directs the proof delivery exclusively to the seed addresses that have been previously defined and associated with that specific delivery campaign, allowing for final checks on personalization, rendering, and deliverability before the main send.

A. Proofs are sent via a manual user action to a selected target; they are not sent automatically to seed lists before every delivery.

C. Sending proofs to seed lists is a fundamental and critical feature in Adobe Campaign for quality assurance and validation purposes.

D. The "To:" text box is for sending proofs to specific, manually entered email addresses, not for selecting a pre-defined seed list group.

1. Adobe Experience League

Campaign Classic v7 Documentation

"Sending proofs." This document outlines the procedure for sending a proof. In the section describing the proof sending window

it explicitly lists "Seed addresses" as a selectable option for the proof's recipient. It states

"Select this option to send the proof to the seed addresses." This directly validates that selecting the appropriate target in the menu is the correct method.

Source: https://experienceleague.adobe.com/docs/campaign-classic/using/sending-messages/sending-proofs/sending-proofs.html?lang=en

2. Adobe Experience League

Campaign Classic v7 Documentation

"About seed addresses." This resource explains the purpose and configuration of seed addresses. It clarifies that seed addresses are added to deliveries to "check the validity of messages before they are sent to the final target

" which inherently involves receiving proofs. This confirms that proofs can and should be sent to seed lists

invalidating option C.

Source: https://experienceleague.adobe.com/docs/campaign-classic/using/audiences/about-seed-addresses/about-seed-addresses.html?lang=en

The standard procedure for sending a proof to a pre-defined group in Adobe Campaign is to use the "Send a Proof" functionality. This opens a dialog where the user can define the proof's target audience. The most direct and efficient method for a named group like "Holiday Marketing Team" is to select the option to target "Recipients of a list" and then choose the specific list from the system. This leverages the pre-configured list entity directly, ensuring all intended members receive the proof without manual data entry or complex querying.

A. Select the email addresses from the recipient table: This implies a manual selection of individual recipients or building a complex query, which is inefficient and not the primary method for targeting an existing list.

B. You cannot send the proof to the lists: This is factually incorrect. Adobe Campaign has a built-in feature specifically for sending proofs to predefined recipient lists.

D. Enter the email addressed into the “To:” line: This field is for sending proofs to ad-hoc, external email addresses that may not exist in the database, not for targeting an existing, managed list.

1. Adobe Campaign Classic v7 Documentation

"Sending a proof": In the section "Define proof recipients

" the documentation explicitly states

"You can also select a list of recipients as the proof target." It details the steps to choose "Recipients of a list" and then select the desired list. (See: Adobe Experience League > Adobe Campaign Classic v7 > Campaign execution > Delivery management > About proofs > Sending a proof).

2. Adobe Campaign Standard Documentation

"Send a proof": The documentation outlines the process for defining the proof audience. It describes how to select a specific audience for the proof

which includes predefined lists. The user would select the audience type as 'List' and then choose the "Holiday Marketing Team" list. (See: Adobe Experience League > Adobe Campaign Standard > Channels > Email channel > Get started with proofs > Send a proof

Section: "Define the proof audience").

In Adobe Campaign Classic, a single delivery activity is designed to target one specific population defined by the inbound transition in a workflow. To send the same communication (e.g., an email with the same content) to multiple, distinct audience segments, the standard and required practice is to configure a separate delivery activity for each segment within the campaign's workflow. This approach allows for precise targeting, personalization, and separate tracking of delivery and response metrics for each distinct audience segment, even if the creative content is identical across the deliveries.

A. The campaign must contain a split: A split activity is used to divide a single population into subsets (e.g., for A/B testing or creating a control group), not for targeting multiple pre-existing, distinct segments.

B. The campaign must have multiple workflows: A single, well-structured workflow is fully capable of managing targeting and deliveries for multiple segments. Creating multiple workflows for this purpose is unnecessary and inefficient.

C. The campaign must contain seeds: Seed addresses are used for proofing and internal testing of a delivery before it is sent to the actual target audience. They are not a mechanism for audience segmentation.

1. Adobe Experience League - Campaign Classic v7 Documentation

"Use case: creating deliveries on two different targets": This official use case explicitly demonstrates a workflow designed to target two different segments. The documentation states

"This use case presents a workflow that lets you create and configure two deliveries for two different targets..." The accompanying workflow diagram clearly shows two separate query activities defining the segments

each leading to its own distinct delivery activity. This confirms that multiple deliveries are the required structure. (See the section: Workflows > Use cases > Targeting use cases).

2. Adobe Experience League - Campaign Classic v7 Documentation

"Delivery (activity)": The documentation for the Delivery activity describes its function as sending a message to a single target population. It notes

"The delivery activity allows you to configure and prepare a delivery for a target defined in the workflow." This implies a one-to-one relationship between a delivery activity and its target population

necessitating multiple activities for multiple populations. (See the section: Workflows > Workflow activities > Action activities).