Free AD0-E307 Practice Test

In Adobe Campaign Classic, a workflow is a single, persistent process. When an error occurs in an activity, the default error management behavior pauses the entire workflow instance. This paused, erroneous state is considered an active instance. The Scheduler activity is designed to trigger a workflow's execution, but it will not start a new instance if one is already running. Therefore, as long as the workflow remains in its failed state, the scheduler will not trigger subsequent runs at the next scheduled times. The workflow must be manually stopped and restarted to clear the error and resume the schedule.

A. The scheduler cannot start another run because the existing workflow instance is still active, albeit in a paused/error state.
C. There is no default 24-hour waiting period for error handling; this would require custom configuration.
D. A new run is not started. The original run is the one that is stopped at the activity where the error occurred.

1. Adobe Campaign Classic v7 Documentation, "Error management" section: "By default, a workflow in error is stopped. The task is abandoned and is not re-executed. The next executions of the workflow will not take place as long as the error is not repaired." This directly confirms that no new runs will be started by the scheduler.

2. Adobe Campaign Classic v7 Documentation, "Workflow properties" section, "Execution" subsection: "In case of an error, the workflow is paused and the activity that is being executed when the error occurred turns red. The administrator is notified and can resume the workflow execution once the error has been fixed." This explains the "paused" state of the workflow, which prevents the scheduler from initiating a new instance.

The most direct and standard method for sending a test email to an address not in the recipient database is to use the "Send a proof" functionality. Within the proof sending dialog, there is a specific field (often labeled "To:") that allows the practitioner to manually type in one or more email addresses. This feature is designed precisely for this use case: sending a test render to stakeholders, testers, or personal accounts for review without needing to add them to the main recipient table or a seed list.

A. Pick any email address and use the preview to see what it looks like The preview function only renders the email within the Campaign interface using data from an existing profile; it does not send an actual email to an external inbox.
B. Go through the standard process for adding recipients This is an inefficient and unnecessary step for a simple, ad-hoc test. The proofing mechanism is designed to bypass the need for formal data entry for quick validation.
D. Add the email to a seed list Seed lists are primarily for systematic monitoring of deliverability and rendering across multiple campaigns, not for a single, quick test by a practitioner. Manual entry is more direct.

1. Adobe Experience League - Campaign Classic v7 Documentation, "Sending Proofs": This document explicitly describes the process of sending proofs. In the section "Define proof target," it states, "You can also enter email addresses directly in the appropriate field." This confirms that manual entry is a supported and intended function for testing. (See the subsection: Define proof target).

2. Adobe Experience League - Campaign Standard Documentation, "Prepare and send a proof": The documentation for Campaign Standard also details this capability. When configuring the proof, the user can "Add an email address" manually. The guide notes, "You can also directly enter email addresses for your proof recipients." (See the section: Prepare and send a proof, Step 4).

The most effective method is to use a Data loading (File) activity to import the text file's contents into the workflow's temporary worktable. Following this, an Enrichment activity is used to link the data from the imported file to the existing recipient data in the database. The enrichment will use the email address as the reconciliation key to add the mobilephonetype attribute to the targeted recipients within the workflow, making it available for subsequent segmentation and targeting activities.

A. An Update data activity modifies existing data in the database; it does not import data from an external file into a workflow's context.
B. A Query activity is used to select data that already exists within the Adobe Campaign database; it cannot be used to import an external text file.
D. A Read list activity is designed to import a simple list of identifiers for targeting, not to import and link additional data attributes like mobile phone type.

1. Adobe Experience League - Campaign Classic v7 Documentation, "Data loading (File)": This document states, "The Data loading (File) activity is a data management activity that lets you import data from a file into Adobe Campaign." This supports its use as the initial step to bring the text file data into the workflow.

2. Adobe Experience League - Campaign Classic v7 Documentation, "Enrichment": This source explains, "The Enrichment activity lets you add columns to a workflow's worktable... The additional data can come from other tables in the database... You must define a reconciliation key to link the data from the different tables." This confirms its role in linking the imported file data to the recipient table using the email address.

3. Adobe Experience League - Campaign Classic v7 Documentation, "Update data": The documentation specifies, "The Update data activity is a data management activity that lets you perform a mass update on the fields of a database table." This clarifies that it is not for importing files.

4. Adobe Experience League - Campaign Classic v7 Documentation, "Read list": This document clarifies the activity's purpose: "The Read list activity lets you retrieve a list defined in a file and use it in a workflow... It is used to import a list of identifiers...". This shows it is unsuitable for importing additional data columns for enrichment.

In Adobe Campaign Classic, when an operator group is assigned as an approver for a delivery, the default configuration requires approval from all members of that group. The approval process is also governed by an expiry deadline. If one of the two designated operators is unavailable, it becomes impossible to gather the required approvals from both. The process will wait until the specified approval deadline is reached. At that point, because the condition for approval has not been met, the delivery will be automatically rejected, and the campaign process will not proceed.

A. The input of just the first approver is required in order for the process to continue onto the next activity This is incorrect because the default behavior requires all designated operators to approve, not just one. This can be configured, but it is not the default.
C. The process will continue without approval if one has been provided before expiry This is incorrect for the same reason as option A. One approval is insufficient when the default setting requires all members of the group to approve.
D. The process waits indefinitely for inputs from both approvers before moving to the next activity This is incorrect because all approval tasks in Adobe Campaign have a configurable expiry deadline. The process does not wait indefinitely.

1. Adobe Campaign Classic v7 Documentation - Configuring approvals:

Reference: In the "Approvals" tab of the delivery properties, when multiple operators or a group are selected, the default behavior is specified.

Quote/Section: "By default, all designated operators must approve the delivery for it to be sent. You can, however, select the Number of approvals required option to specify the number of operators required to start the delivery process."

Source: Adobe Experience League, Campaign Classic v7 Documentation, Processes and data management > Approval processes > Configuring approvals.

2. Adobe Campaign Classic v7 Documentation - About delivery approvals:

Reference: This document outlines the functionality of the approval cycle, including the role of the expiry deadline.

Quote/Section: "You can set a deadline for delivery approval in the Approval deadline field. If the delivery is not approved by this deadline, it is automatically rejected."

Source: Adobe Experience League, Campaign Classic v7 Documentation, Campaign Management > Deliveries > About delivery approvals.

The Union activity in an Adobe Campaign workflow combines the results of inbound activities and removes duplicates. The size of the resulting population (C) can be calculated using the set theory formula: |C| = |A| + |B| - |A ∩ B|. Given the values: |A| = 100 |B| = 200 |C| = 200 The calculation is: 200 = 100 + 200 - |A ∩ B|. Solving for the intersection, |A ∩ B| = 300 - 200 = 100. Since the size of the intersection (100) is equal to the total size of population A (100), it logically follows that every record in population A is also contained within population B.

A. Records in A have been excluded from C. This is incorrect. A Union activity includes all unique records from all inbound sets. The records from A are part of the final population C.
C. All of the records in B are also in A. This is incorrect. If all records in B were also in A, the union of A and B would be A itself, resulting in a population of 100, not 200.
D. A and B are mutually exclusive. This is incorrect. If the populations were mutually exclusive (no common records), the union would be the sum of both, resulting in 300 records (100 + 200).

1. Adobe Campaign Classic v7 Documentation, Targeting activities, Union: "The result of a union contains all the elements from the inbound transitions, without duplicates." This confirms the deduplication behavior which is central to the question's logic.

Source: Adobe Experience League. (n.d.). Union. Adobe Campaign Classic v7 Documentation. Retrieved from https://experienceleague.adobe.com/docs/campaign-classic/using/getting-started-with-workflows/targeting-activities/union.html (Refer to the "Description" section).

2. Adobe Campaign Standard Documentation, Workflows, Union: "The Union activity combines all inbound populations. If a recipient is present in multiple inbound populations, they will only be kept once in the output population." This statement directly supports the principle that the final count of 200 implies a complete overlap of the smaller population (A) within the larger one (B).

Source: Adobe Experience League. (n.d.). Union. Adobe Campaign Standard Documentation. Retrieved from https://experienceleague.adobe.com/docs/campaign-standard/using/managing-processes-and-data/targeting-activities/union.html (Refer to the "Using the Union activity" section).

The discrepancy between the upstream population (initial target) and the final sent count in Adobe Campaign Classic is typically due to exclusions applied during the delivery analysis phase. Pressure typologies are rules designed to prevent over-solicitation by excluding recipients who have been contacted too frequently, thus reducing the final count. Similarly, recipients whose addresses are on the quarantine list due to previous delivery failures (e.g., hard bounces) are automatically excluded from the delivery, further lowering the number of messages sent compared to the initial target audience.

A. The upstream population did NOT include seeds. Seed addresses are added to the target audience for testing and validation; their absence would not decrease the sent count relative to the primary population.
D. The upstream population was too large. While a very large population can impact performance, its size is not a direct filtering criterion that would inherently cause the sent count to be lower.

1. Adobe Experience League - Campaign Classic v7 Documentation, "Pressure rules": This document explains how pressure rules work. It states, "Pressure rules are used to avoid over-soliciting a recipient. Depending on the settings, recipients will be excluded from the delivery if they have already been sent a certain number of deliveries..." This directly supports that applying pressure rules reduces the final sent count. (Found in Campaign Classic v7 > Delivery > About typology rules > Pressure rules).

2. Adobe Experience League - Campaign Classic v7 Documentation, "Quarantine management": This source details the quarantine mechanism. It specifies, "An address that is in quarantine will be excluded by default during delivery analysis and will not be targeted by the delivery." This confirms that quarantined recipients are removed from the send, causing the sent count to be lower than the initial population. (Found in Campaign Classic v7 > Delivery > Understanding delivery failures > Quarantine management).

3. Adobe Experience League - Campaign Classic v7 Documentation, "Delivery analysis": This section describes the steps before a delivery is sent. It notes, "During this phase, the target population is calculated, and the message content is prepared for each recipient... The delivery analysis logs show the number of messages to be sent after exclusions." This confirms that exclusions, such as those from typologies and quarantines, occur during analysis. (Found in Campaign Classic v7 > Delivery > Get started with deliveries > Steps for sending a delivery > Delivery analysis).

The most fundamental similarity between a recurring delivery and a continuous delivery is their purpose: both are designed to be sent multiple times automatically. A recurring delivery executes in batches based on a schedule (e.g., weekly newsletter), while a continuous delivery sends individual messages triggered by an event or data entry (e.g., a welcome email). Despite their different execution mechanics, their core shared function is to facilitate repeated, automated communication, distinguishing them from a standard, one-off delivery.

A. Both deliveries append record to the delivery log This is incorrect. Only a continuous delivery appends records to a single, persistent delivery log. A recurring delivery creates a new, separate delivery instance and log for each execution.
C. Both deliveries can be modified in the delivery step This is not the best answer. While both are configured in a workflow's delivery activity ("step"), this is a general characteristic of workflow-based deliveries, including standard ones. It doesn't capture the unique functional similarity between recurring and continuous types.
D. Both deliveries create new delivery logs This is incorrect. Only a recurring delivery creates new delivery logs for each run. A continuous delivery uses a single delivery instance and appends to its existing logs. ---

1. Adobe Experience League Documentation - Campaign Classic - Recurring Delivery:

Section: "Operating principle"

Content: "The aim of a recurring delivery is to execute a delivery based on a template multiple times." This directly supports that the purpose is to send multiple times (Answer B). It also states, "This instance will be duplicated on each execution of the activity," which confirms it creates new instances/logs, invalidating option D and showing a difference from continuous delivery (invalidating A).

Source: Adobe. (n.d.). Recurring delivery. Adobe Experience League. Retrieved from https://experienceleague.adobe.com/docs/campaign-classic/using/automating-with-workflows/delivery-activities/recurring-delivery.html

2. Adobe Experience League Documentation - Campaign Classic - Continuous Delivery:

Section: "Operating principle"

Content: "The aim of a continuous delivery is to send a delivery each time an event is received." This supports the concept of sending multiple times based on triggers (Answer B). It also notes, "Each time a profile goes through this activity, a new line is added to the delivery logs," confirming it appends to a single log, which invalidates option A as a similarity and option D outright.

Source: Adobe. (n.d.). Continuous delivery. Adobe Experience League. Retrieved from https://experienceleague.adobe.com/docs/campaign-classic/using/automating-with-workflows/delivery-activities/continuous-delivery.html

The email preview functionality in Adobe Campaign Classic is a critical pre-send step that allows a user to visualize how the email will appear to a specific recipient. This process directly enables the testing of personalization by populating the email with a selected recipient's data to ensure dynamic content renders correctly. The preview also displays the full email content, which includes embedded links. This allows for the verification of the mirror page link and the legally mandated opt-out link, ensuring they are present, correctly formatted, and functional before the campaign is executed.

C. spam score: Spam score analysis is a separate pre-send check performed via a distinct tool (e.g., SpamAssassin integration), not within the visual preview rendering of the email content.

1. Adobe Campaign Classic v7 Documentation - Previewing messages: "The Preview tab lets you view the rendering of each message for a recipient of the target. This allows you to check the personalization data and the general aspect of your message before sending the proofs or the final delivery." This source confirms that personalization (B) is a primary function of the preview. The preview renders all content, which includes mirror page (A) and opt-out links (D), making them verifiable.

Source: Adobe Experience League, Adobe Campaign Classic v7 Documentation, Section: Prepare and send messages > Previewing messages.

2. Adobe Campaign Classic v7 Documentation - Unsubscription: "The unsubscription link is mandatory in the emails and is added by default in the templates." The presence and functionality of this mandatory link (D) are verified during the content preview and proofing stage.

Source: Adobe Experience League, Adobe Campaign Classic v7 Documentation, Section: Get started with channels > Email channel > About unsubscription.

3. Adobe Campaign Classic v7 Documentation - Checking the spam score: "To start the spam score computation, open a delivery and click the Spam & Litmus button... This action is available in the delivery's action bar." This documentation explicitly describes the spam score check (C) as a separate action initiated from the delivery's action bar, distinct from the preview tab.

Source: Adobe Experience League, Adobe Campaign Classic v7 Documentation, Section: Prepare and send messages > Content validation > Checking the spam score.

To identify responders in a campaign, a Practitioner must query the data related to recipient interactions, such as opens and clicks. In Adobe Campaign Classic, this information is stored in the tracking logs. The tracking logs filtering dimension (schema: nms:trackingLogRcp) specifically captures all user actions and reactions to a delivery, making it the correct source for segmenting an audience based on their response behavior.

B. exclusion logs: These logs (nms:exclusionLogRcp) contain records of recipients who were excluded from a delivery for various reasons (e.g., quarantine, denylist) and do not indicate a response.
C. delivery logs: These logs (nms:broadLogRcp) track the status of messages sent to recipients (e.g., sent, delivered, bounced). They confirm delivery but not interaction or response.
D. approval logs: These logs are related to the internal campaign validation and approval processes. They contain no information about external recipient behavior or campaign responses.

1. Adobe Experience League - Campaign Classic v7 Documentation, "Campaign Classic Data Model - trackingLogRcp: Tracking logs": This official documentation explicitly states, "The nms:trackingLogRcp table contains the tracking logs for each recipient. The records in this table are accessed via the Tracking logs link from the Profiles and Targets > Recipients node." It further details that this table stores tracking information like opens and clicks, which define a responder.

Reference: Adobe Experience League, Campaign Classic v7 Documentation, Data model, Built-in tables, nms:trackingLogRcp.

2. Adobe Experience League - Campaign Classic v7 Documentation, "Get started with reporting - Tracking indicators": This section clarifies that key performance indicators for responses, such as "Clicks" and "Opens," are calculated based on the data stored in the tracking logs. This confirms that tracking logs are the source for identifying response activity.

Reference: Adobe Experience League, Campaign Classic v7 Documentation, Get started with reporting, Key steps to create a report, Tracking indicators.

3. Adobe Experience League - Campaign Classic v7 Documentation, "Targeting activities in workflows - Query": When building a query to filter a population, the documentation shows the available filtering dimensions. To filter based on user behavior (e.g., "recipients who have clicked in a delivery"), the "Tracking logs (tracking)" dimension must be selected.

Reference: Adobe Experience League, Campaign Classic v7 Documentation, Use workflows, Targeting activities, Query, Edit the query properties section.

Adobe Campaign is designed to streamline marketing operations. For sending proofs to a predefined group like the "Holiday Marketing Team," the most efficient and correct method is to use the platform's built-in functionality. The "Send a Proof" feature allows the user to directly select a pre-existing recipient list as the target. This ensures that all members of the designated list receive the proof for approval without requiring manual entry of individual email addresses.

A. Select the email addresses from the recipient table: This is a manual, inefficient process that does not leverage the pre-configured list, increasing the risk of human error.
B. You cannot send the proof to the lists: This statement is factually incorrect. Adobe Campaign has explicit functionality to target proofs to recipient lists.
D. Enter the email addressed into the “To:” line: This method is for sending proofs to individual, ad-hoc recipients, not for targeting an entire, managed list of people.

1. Adobe Experience League - Campaign Classic Documentation: In the section on sending proofs, the documentation specifies the methods for defining a proof target. It explicitly states, "You can select recipients from the existing profiles or add them explicitly. You can also create and use a list of recipients." This confirms that selecting a list is a standard procedure.

Source: Adobe Experience League, Campaign Classic v7 Documentation, "Sending proofs", Section: "Defining the proof target".

2. Adobe Experience League - Campaign Classic Documentation: The user interface guide for sending proofs shows that after clicking the "To" link in the proof sending dialog, an option to "Edit..." the recipients is available. This opens a selection window where a "List of recipients" can be chosen as the target.

Source: Adobe Experience League, Campaign Classic v7 Documentation, "Sending proofs", Section: "Defining the proof target", Step 2.