Free Marketing-Cloud-Account-Engagement-Consultant Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

For a seamless integration between Marketing Cloud Account Engagement and a Salesforce custom object, two foundational requirements must be met. First, the custom object in Salesforce must be linked to a core prospect record (Lead, Contact, or Account) via a lookup or master-detail relationship. This association is critical for Account Engagement to relate the custom object's data to a specific prospect. Second, the Salesforce Connector User, which acts as the integration agent, requires at least 'Read' permission to the custom object and its fields. Without this permission, Account Engagement cannot access or sync the data from Salesforce.

C. A relationship to a Campaign or Opportunity is not a prerequisite for linking the custom object to a prospect for syncing purposes.

D. 'Display in Table' is a user interface configuration setting within Account Engagement, configured after the integration is established, not a foundational requirement for the integration itself.

1. Salesforce Help Documentation, "Considerations for Using Custom Objects":

This document explicitly states the prerequisites. Under the "Prerequisites" section, it lists: "To use custom objects with Account Engagement, they must have a relationship with a contact, account, or lead record." This directly supports option A.

The same section also states: "The connector user must have read permission for the custom object." This directly supports option B.

2. Salesforce Help Documentation, "Integrate Custom Objects":

This step-by-step guide reinforces the requirements. Step 1 is: "In Salesforce, create a custom object and associate it with the account, contact, or lead object." (Supports A).

Step 2 is: "Give the connector user read permission to the new object." (Supports B).

Step 5, "Map fields," includes the action to "Choose which fields to display in the Account Engagement table," confirming that this is a later configuration step, not a prerequisite for integration. (Refutes D).

Marketing Cloud Account Engagement provides native functionality for marketers to both import and export prospect data. Prospects can be imported from a .csv file to create new records or update existing ones. Similarly, prospect data can be exported to a .csv file for purposes such as reporting, analysis, or backup.

The "False" option is incorrect because the ability to manage data flow in and out of the platform is a fundamental feature of Account Engagement. The system is designed to allow marketers to bring in leads from various sources (via import) and to extract data for use in other systems or for analysis (via export).

1. Salesforce Help, Account Engagement Documentation, "Import Prospects": This official document outlines the entire process for importing prospects. It states, "You can import a list of prospects into Account Engagement from a CSV file. The import wizard lets you map the columns in your file to fields in Account Engagement and choose how the import affects existing prospect records."

Source: Salesforce Help, Import Prospects, Section: "Import Prospects with Account Engagement".

2. Salesforce Help, Account Engagement Documentation, "Export Prospects": This document details the procedure for exporting prospect data. It specifies, "You can export prospects in .csv format from any prospect table or from the prospect import page. The export file includes the prospect’s information, and any custom fields."

Source: Salesforce Help, Export Prospects, Section: "Export Prospects".

A prospect's score in Account Engagement is a numerical value that can be adjusted both positively and negatively. Automation rules, completion actions, or Engagement Studio programs can be configured to subtract points from a prospect's score. If a prospect has a low or zero score and performs an action that has a negative scoring value associated with it (e.g., visiting a "careers" page, having an invalid job title), their total score can become less than zero. This functionality is often used to penalize actions that indicate a prospect is a poor fit or to reduce the score of unqualified leads.

The "False" option is incorrect because the Account Engagement scoring system is not floored at zero. The platform's design explicitly allows for score decrements through various automation features, which can result in a total score that is a negative integer.

1. Salesforce Help, Account Engagement Documentation, "Scoring": This document explicitly states how scoring functions. In the "How Scoring Works" section, it clarifies the nature of the score value: "A prospect’s score can be a positive or negative number and is a reflection of the prospect’s interest."

2. Salesforce Help, Account Engagement Documentation, "Considerations for Scoring": This guide provides best practices and details about the scoring mechanism. Under the "Scoring" section, it reiterates the core principle: "A prospect’s score can be a positive or negative number."

3. Salesforce Help, Account Engagement Documentation, "Automation Rule Actions": This document details the actions available within automation rules. The action "Adjust prospect's score" allows an administrator to specify a positive or negative integer to add to or subtract from the prospect's current score, providing the mechanism for a score to become negative.

Marketing Cloud Account Engagement is designed to prevent data corruption and conflicting changes by implementing an asset locking mechanism. When a user begins editing an asset, such as an Email Template, the system places a lock on it. If another user attempts to edit the exact same template while it is locked, they are not able to edit it simultaneously. Instead, they are presented with a prompt that gives them the option to either take over the editing session (which forces the original user out) or open the asset in a read-only mode.

The statement "True" is incorrect because the system's architecture explicitly prohibits simultaneous editing by multiple users. The platform's conflict resolution—prompting a second user to take over or view in read-only—is a mechanism to manage sequential, not simultaneous, editing sessions.

1. Salesforce Help: Considerations for Editing Assets

Reference: In the section detailing asset editing behavior, the documentation states, "Only one user can edit an asset at a time. If you try to edit an asset that another user is editing, you’re prompted to take over the editing session or open the asset in read-only mode." This directly confirms that simultaneous editing is not possible.

Source: Official Salesforce Vendor Documentation for Marketing Cloud Account Engagement.

In Marketing Cloud Account Engagement, "CRM User" is not a selectable data type when creating a custom prospect field. A field functions as a user field for the purpose of assignment when a standard field type (such as Dropdown, Text, or Hidden) is mapped to a user lookup field in the connected CRM (e.g., the OwnerID field in Salesforce). The system recognizes this mapping and allows the field to be used for assignments, but the underlying field type within Account Engagement's settings is not "CRM User."

The statement is false because it incorrectly identifies a functional role of a field as a distinct, selectable data type. While Account Engagement has the concept and functionality of a "user field," this is achieved through mapping a standard field type to a specific kind of CRM field, not by selecting "CRM User" from the type list during field creation. The available types are Text, Number, Date, Dropdown, etc.

1. Salesforce Help Documentation, "Prospect Field Settings Reference." This document provides the definitive list of available field types for prospect fields in Account Engagement. The list includes Text, Number, Date, Dropdown, Radio Button, Checkbox, Textarea (Large Text), Multi-Select, and Hidden. It does not list "CRM User" as a selectable type.

Source: Salesforce Help, Marketing Cloud Account Engagement, "Prospect Field Settings Reference."

2. Salesforce Help Documentation, "Considerations for Creating Custom Fields." This document explains the process for creating a field that functions as a user field. It states, "To create a user field, map a prospect field to a CRM user lookup field. You can then use the field for prospect assignment." This confirms that a user field is created by mapping a standard field, not by selecting a specific "CRM User" type.

Source: Salesforce Help, Marketing Cloud Account Engagement, "Considerations for Creating Custom Fields," section on User Fields.

The Salesforce Connector for Marketing Cloud Account Engagement is designed to facilitate a seamless flow of data between marketing and sales. It natively syncs specific standard Salesforce objects that are critical for B2B marketing and sales alignment. Among the options provided, Accounts and Opportunities are standard objects that are synchronized. Accounts represent the companies that prospects belong to, while Opportunities track potential sales deals, allowing marketers to calculate ROI and nurture prospects based on their engagement with the sales cycle.

C. Case: Cases are a standard Salesforce object for customer service and support, but they are not synced by default with the Account Engagement connector.

D. Order: Orders represent confirmed transactions and are not a standard object synced by the Account Engagement connector, which focuses on potential revenue via Opportunities.

1. Salesforce Help, Marketing Cloud Account Engagement: Objects Synced with the Salesforce Connector. This document explicitly lists the standard objects that sync. It states, "When you verify your Salesforce connector, you can sync these objects: Prospects, Accounts, Opportunities, Campaigns, Users, and Custom Objects." This directly confirms that Accounts and Opportunities are synced.

2. Salesforce Help, Marketing Cloud Account Engagement: Salesforce Connector v2 Setup Guide. In the "How Data Syncs with the Salesforce Connector" section, the documentation details the relationships between synced objects, highlighting the connection between Prospects (Leads/Contacts), Accounts, and Opportunities as the core of the B2B data model.

3. Salesforce Help, Marketing Cloud Account Engagement: Considerations for Using the Salesforce Connector. This guide outlines the capabilities and limitations of the connector. It details how prospect records in Account Engagement sync with lead and contact records in Salesforce, and how these are related to Accounts and Opportunities, reinforcing that these are the key synced objects. It makes no mention of Cases or Orders as standard sync objects.

While the standard, out-of-the-box Account Engagement Email Preference Center does not require a login (it uses a unique, tokenized URL to identify the prospect), it is a common and supported implementation to create a custom preference center that does require a login. This is typically achieved by hosting the preference management page within a secure customer portal or a Salesforce Experience Cloud site. In this scenario, a user logs in to their account, and their preference changes are synced back to their Account Engagement prospect record via the Account Engagement API or a form handler. This provides a more secure and integrated user experience.

The statement is not False because the platform's capabilities extend beyond the default features. A key role of a consultant is to understand how to meet specific business requirements, such as a secure, login-gated preference center, through customization and integration. Stating this is False would incorrectly limit the platform's capabilities to only its default, out-of-the-box functionality and ignore the robust API that enables such custom solutions.

1. Salesforce Help Documentation - Create a Custom Preference Center Page: This official document outlines the methods for creating a custom preference center. It states, "You can build a preference center page on your own website and use a Pardot form, form handler, or API to sync prospect preferences." A page built on a company's own website can be placed behind a login authentication system.

Source: Salesforce Help, Account Engagement / Email Marketing / Email Preference Pages / "Create a Custom Preference Center Page".

2. Account Engagement Developer Guide - API Reference: The Account Engagement API provides the necessary endpoints to programmatically manage a prospect's list memberships from an external, authenticated system. The prospect list memberships object allows a developer to read, create, and update a prospect's subscription status for various lists, which is the core mechanism for a custom, login-required preference center.

Source: Salesforce Developers, Account Engagement Developer Guide, API Reference Version 5, Objects / "Prospect List Memberships".

3. Salesforce Architects Design - Marketing Cloud and Experience Cloud Integration Patterns: Architect-level documentation frequently discusses the pattern of using an Experience Cloud site (which is a login-based portal) to manage marketing communication preferences. Data from the authenticated Experience Cloud user is updated on their Contact/Lead record, which then syncs to the corresponding Account Engagement prospect record.

Source: Salesforce Architects, "Customer 360 Guide for Architects", Solution Kits / "Enhance Marketing with Transactional Data from Experience Cloud". This guide describes patterns where authenticated portal users interact with systems that sync back to marketing platforms.

Marketing Cloud Account Engagement (formerly Pardot) imposes daily API call limits that vary by edition to ensure system stability and performance. The limits are tiered based on the subscription level. The Growth edition is allocated 25,000 calls per day, the Plus edition receives 50,000 calls per day, and the Advanced edition is provided with 100,000 calls per day. These limits reset every 24 hours. Exceeding these limits will result in API calls being temporarily blocked until the next 24-hour window begins.

A. Incorrect. All cloud-based platforms, including Account Engagement, have API limits to maintain system health and prevent abuse.

B. Incorrect. The API limits are not uniform across all editions; they are tiered, and the base limit is higher than 10,000.

C. Incorrect. This option incorrectly states the limit for the Plus Edition as 25,000. The correct limit for the Plus Edition is 50,000 calls per day.

1. Salesforce, Account Engagement Developer Guide: API Usage and Limits. This document explicitly lists the daily API call limits for each edition. It states: "Your daily API call limit is determined by your Account Engagement edition. Growth: 25,000; Plus: 50,000; Advanced: 100,000; Premium: 100,000."

2. Salesforce Help: Pardot Editions and Pricing. The official pricing and feature comparison page details the features and limits, including API calls per day, for each Account Engagement edition, corroborating the numbers in the developer guide. (Note: Specific pricing pages can change, but the developer guide is the canonical source for technical limits).

The "Email" field is a required, default prospect field in Marketing Cloud Account Engagement, not a custom field type. When an administrator creates a new custom field, they must select from a predefined list of field types such as Text, Number, Date, or Dropdown. The "Email" type is reserved exclusively for the default Email Address field and is not an available option for custom field creation.

The statement "True" is incorrect because it conflates the existence of the default "Email" field with the available types for custom fields. While an "Email" field is fundamental to the system, its special data type cannot be assigned to any new, user-created fields.

1. Salesforce Help, Marketing Cloud Account Engagement Documentation, "Create Custom Prospect Fields." This document outlines the process for creating custom fields and lists the available field types. The list includes Text, Number, Date, Dropdown, Radio Button, Checkbox, Textarea, Multi-Select, and Hidden. The "Email" type is not included in this list of options for custom fields.

2. Salesforce Help, Marketing Cloud Account Engagement Documentation, "Prospect Fields." This resource details the default fields that come standard with Account Engagement. It explicitly states, "The email address field is a default field and is required on all records." This confirms its status as a default, not a custom, field.

Kiosk/Data Entry Mode is a specific setting for Marketing Cloud Account Engagement (Pardot) forms designed for scenarios like trade shows or public terminals. When enabled, it prevents the browser from being cookied upon form submission. This ensures that each submission from the same device is treated as a unique entry, creating a new prospect record (or updating an existing one based on the email address) without associating all submissions with a single prospect cookie. This directly addresses the requirement of signing up multiple individuals on the same computer.

B. ReCAPTCHA: This is a security feature used to prevent spam and automated bot submissions. It does not address the issue of multiple prospects using the same device.

C. "Not you?" Link: This link appears when a form is prefilled with data from a cookied visitor. It allows a different person to clear the form, but it is a manual, reactive step and less efficient for a high-volume trade show scenario than Kiosk Mode.

D. Progressive Profiling: This feature displays new fields to known prospects on subsequent visits to gather more data over time. It relies on a persistent cookie and is unsuitable for registering multiple new prospects on one device.

1. Salesforce Help, Marketing Cloud Account Engagement Documentation, "Form Settings Reference":

Section: Look and Feel, Advanced Tab

Kiosk/Data Entry Mode: "Prevents the visitor’s browser from being cookied when the form is submitted. Use this setting for forms that are used at a trade show or on a public computer." This directly validates the correct answer for the specified use case.

2. Salesforce Help, Marketing Cloud Account Engagement Documentation, "Considerations for Using Forms":

Section: Kiosk/Data Entry Mode

"Select Kiosk/Data Entry Mode on your forms to use at a trade show or on a public computer. This setting prevents prospect submissions from being associated with your user cookie." This further reinforces the purpose of Kiosk Mode.

3. Salesforce Help, Marketing Cloud Account Engagement Documentation, "Progressive Profiling for Forms":

Section: How Progressive Profiling Works

"When a cookied prospect lands on a page with one of your forms, Account Engagement looks at the data that you already have for the prospect..." This confirms that Progressive Profiling depends on a cookie, making it incorrect for the trade show scenario where multiple individuals are involved.

When an Engagement Studio program is paused, all prospect movement within the program ceases. For prospects who are on a 'Wait' step at the time of the pause, the timer is halted. Upon resuming the program, these prospects do not continue from where they left off. Instead, the wait period timer resets, and they must wait for the full duration of that step from the moment the program is resumed. This ensures that the intended cadence and timing between steps are maintained as originally designed, regardless of the pause duration.

A. This is incorrect because the wait step timer does not resume from its previous state; it restarts from the beginning.

B. This is incorrect because prospects do not continue to progress through any step, including a wait step, while the program is paused.

D. This is incorrect because the wait timer is completely halted during the pause and does not run in the background.

1. Salesforce Help, Account Engagement Documentation: Considerations for Pausing Engagement Programs.

Section/Content: The documentation explicitly states, "When you pause a program, prospects stop moving through it. When you resume the program, prospects pick up where they left off. For example, a prospect is on a 3-day wait step when you pause the program. When you resume the program 5 days later, the prospect remains on the wait step for 3 more days." This example confirms the wait step restarts for its full duration.

2. Trailhead by Salesforce: Engagement Studio Module, Test and Start an Engagement Program Unit.

Section/Content: Under the topic of managing a running program, the behavior of pausing is described. It uses the identical example as the Salesforce Help documentation, reinforcing that a prospect on a 3-day wait step will wait for 3 more days upon resumption, indicating a full reset of the wait timer.

A Page Action is the most appropriate and efficient tool for this requirement. Page Actions are a specific type of completion action designed to fire when a prospect views a particular page on a website that contains the Account Engagement tracking code. You can configure a Page Action for the careers page URL and set the corresponding action to "Adjust prospect score by -100". This directly links the page view event to the desired scoring change without the need for more complex, continuously running rules.

B. Custom redirect: This is incorrect because custom redirects are used to track link clicks, typically for assets or pages where you cannot place tracking code (e.g., a third-party site or a file). The trigger is a click, not a page view.

C. Completion action: This answer is too general. While a Page Action is a type of completion action, "Completion action" itself is a broad category of actions tied to specific assets like forms or emails. "Page Action" is the specific feature for this page-view-based scenario.

D. Automation rule: While an automation rule could be configured to achieve this, it is not the best recommendation. Automation rules continuously evaluate all prospects against their criteria, making them less efficient for a simple, one-time trigger like a page view. Page Actions are purpose-built for this use case.

1. Salesforce Help, Account Engagement Documentation, "Page Actions": "Page actions are completion actions that are triggered by a prospect’s page views. You can apply page actions to any page that contains your Account Engagement tracking code." This document lists "Adjust score" as one of the available actions. (Salesforce Help, Page Actions, Accessed 2023).

2. Salesforce Help, Account Engagement Documentation, "Choosing the Right Automation Tool": This guide typically advises using the most specific tool for the task. For actions based on a specific page view, a Page Action is more direct and efficient than a broader tool like an Automation Rule. An Automation Rule is better suited for criteria-based actions that need to run repeatedly on a database of prospects. (Salesforce Help, Account Engagement Automation Tools Overview, Accessed 2023).

3. Salesforce Help, Account Engagement Documentation, "Automation Rule Actions": This document confirms that an automation rule can adjust a prospect's score. However, it also describes the nature of automation rules as continuously running processes, which reinforces why a Page Action is the more efficient, event-driven choice for this specific scenario. (Salesforce Help, Automation Rule Actions, Accessed 2023).

The statement accurately describes the core functionality of Progressive Profiling within Marketing Cloud Account Engagement forms. This feature is designed to conditionally display new form fields to a returning prospect based on whether data for other, pre-specified fields already exists in their prospect record. This allows for a gradual collection of information over multiple interactions without repeatedly asking for the same data, thereby reducing form friction and enriching the prospect's profile over time.

The "False" option is incorrect because the scenario described—showing fields only if other fields are already populated—is the precise definition and intended use case for Progressive Profiling in Account Engagement.

1. Salesforce Help Documentation, "Progressive Profiling for Forms": This official document states, "Progressive profiling displays new fields to prospects based on the data that has already been collected... You can set a form field to display only when another field on the same form has a value." This directly confirms that fields are shown based on pre-existing data in other selected fields.

Source: Salesforce Help, Marketing Cloud Account Engagement Documentation, Section: "Progressive Profiling for Forms".

2. Salesforce Trailhead, "Pardot Lead Generation for Pardot Lightning App" module, "Create a Form" unit: This official training material explains the feature: "Progressive profiling lets you gather information from prospects over time without overwhelming them with a long form. You can configure fields to appear conditionally, based on other fields that the prospect has already completed."

Source: Salesforce Trailhead, Module: "Pardot Lead Generation for Pardot Lightning App", Unit: "Create a Form", Sub-section: "Add Progressive Profiling to a Form".

The Click-Through Rate (CTR) is the most recommended metric for measuring email campaign success. It represents the percentage of recipients who actively engaged with the email's content by clicking on a link. This action demonstrates a higher level of interest and intent compared to merely opening the email. CTR is a direct indicator of how compelling the email's message and call-to-action were, making it a more reliable measure of performance, especially as privacy features like Apple's Mail Privacy Protection make open rates less accurate.

B. Email Complain Rate: This is a negative metric that measures audience dissatisfaction or list health issues, not campaign success.

C. HTML Open Rate: This metric is becoming less reliable due to email client privacy features and indicates a lower level of engagement than a click.

D. Spam complaints: Similar to the complain rate, this is a strong indicator of campaign failure and potential deliverability problems.

1. Salesforce Trailhead, Email Marketing with Pardot, Unit: Review Email Reports and Metrics: "The click-through rate is often considered the most important email metric because it tells you how many people engaged with your content and wanted to learn more." This source explicitly prioritizes CTR as the key indicator of content engagement and success.

2. Salesforce Help, Account Engagement, Document: List Email Report Metrics: This document defines the Click-Through Rate as "The percentage of prospects who clicked a link in your email out of the number of emails delivered." It is presented as a primary metric for understanding prospect interaction with the email content.

3. Salesforce Help, Account Engagement, Document: Considerations for Email Open Tracking: This document explains how Mail Privacy Protection (MPP) can inflate open rates. It states, "Because of these changes, email opens are a less reliable indicator of engagement." This officially supports the reasoning for prioritizing CTR over open rates.

The ability to send operational (non-marketing) emails to opted-out prospects in Marketing Cloud Account Engagement is a special feature that is not enabled by default. It cannot be activated by a consultant or an account administrator directly within the settings. The correct procedure requires the client to submit a formal request to the appropriate Salesforce team (historically the Client Advocate Team, now generally handled through Salesforce Support). This process ensures that Salesforce can verify the intended use is for legitimate, non-promotional communications, thereby maintaining compliance and deliverability standards.

A. This is incorrect because major anti-spam laws, like CAN-SPAM, distinguish between commercial and transactional/relationship messages. Sending purely operational emails is generally permissible.

B. This is incorrect because neither a consultant nor a client administrator has the direct ability to enable this feature. It must be provisioned by Salesforce support after a review.

D. This is incorrect because the fundamental premise is flawed. The consultant cannot enable the setting, so requesting written confirmation for an action they cannot perform is not the appropriate course of action.

1. Salesforce Help Documentation, "Considerations for Sending Operational Emails": This document outlines the nature of operational emails and the process for enablement. It states, "To send operational emails, a Pardot admin must contact Salesforce Support to have the feature enabled." This directly supports the conclusion that the client must contact a Salesforce team, not the consultant, to enable the feature.

2. Salesforce Help Documentation, "Send Operational Emails": This guide details the steps for using the feature after it has been enabled. The prerequisite section notes, "To get started with operational emails, contact your Salesforce account executive." This confirms that enablement is a controlled process managed by Salesforce personnel, invalidating options B and D.

3. U.S. Federal Trade Commission, "CAN-SPAM Act: A Compliance Guide for Business": The guide defines a "transactional or relationship message" which facilitates an agreed-upon transaction or updates a customer in an existing business relationship. It clarifies that such messages are not considered "commercial electronic mail messages" and are exempt from most provisions of the Act, including honoring opt-out requests for marketing. This refutes the claim in option A.

For a prospect to re-enter a repeating Engagement Studio program, they must be removed from the recipient list after their first run and then added back. The most effective method is to use a static list. A form completion action adds the prospect to the static recipient list, starting their journey. A step within the program, placed just before the end, removes the prospect from that same list. This makes them eligible to be added again by the completion action when they resubmit the form, thus allowing them to repeat the program as intended.

B: This option is incomplete. While an automation rule can add prospects to a list, this method omits the crucial step of removing the prospect from the list, which is required for re-entry.

C: A dynamic list based on form completion is unsuitable for this repeating scenario. The prospect would permanently match the list's criteria after the first submission and would never be removed, thus preventing them from re-entering the program.

D: Using a trigger for the same action that adds a prospect to the recipient list is redundant. This approach also fails to include the necessary step of removing the prospect from the list to enable re-entry.

1. Salesforce Help, Account Engagement Documentation, "Considerations for Repeating Engagement Programs": This document explicitly states the requirement for re-entry: "To reenter a program, a prospect must be removed from the program’s recipient list and then added back to it." This supports the logic in answer A and directly contradicts the viability of answer C.

2. Salesforce Help, Account Engagement Documentation, "Engagement Program Action Steps": This page details the available "Action" steps within Engagement Studio, including "Remove from List," which is the mechanism used in the correct answer (A) to make a prospect eligible for re-entry.

3. Salesforce Help, Account Engagement Documentation, "Completion Actions": This resource confirms that "Add to List" is a standard completion action available on forms, which serves as the entry mechanism in the correct answer (A).

4. Salesforce Help, Account Engagement Documentation, "Dynamic Lists": This document explains that dynamic lists automatically manage membership based on criteria. For a "form was completed" criterion, a prospect would not be automatically removed, making the list unsuitable for this repeating program use case as described in option C.

The Marketing Cloud Account Engagement prospect import wizard provides several data management actions. During Step 4 of the import process, "Assign Prospects," an administrator can assign all prospects in the import file to a specific, existing user. This is a common function for lead distribution. Furthermore, the import process is designed to update the database with the most current information. If a prospect in the import file matches a record that currently resides in the Recycle Bin (based on email address or CRM ID), the import will automatically restore that prospect, making them an active record again.

B. New custom fields must be created in Account Engagement settings before an import; they cannot be created during the import process itself.

C. The import function is used to add or update prospect records. It cannot be used to delete prospects, which is a separate action that moves them to the Recycle Bin.

1. Salesforce Help, Marketing Cloud Account Engagement Documentation, "Import Prospects." This document outlines the five steps of the import wizard.

For Answer A: Step 4, "Assign Prospects," explicitly states: "From the Source field, choose to assign prospects to a specific user, a group, a queue, or an active user assignment rule."

For Answer B: Step 3, "Map Fields," describes mapping CSV columns to existing Account Engagement fields. It does not provide an option to create new fields. The creation of custom fields is documented as a separate administrative task under "Create Custom Prospect Fields."

2. Salesforce Help, Marketing Cloud Account Engagement Documentation, "Considerations for Importing Prospects."

For Answer D: Under the "General" section, the documentation states: "If a prospect in your import file matches a prospect in the recycle bin, the prospect is undeleted."

For Answer C: This document details actions for adding and updating records (e.g., "Importing and Data Updates," "Overwriting Field Values"). It contains no mention of a delete action as part of the import process. The process for deletion is covered separately in "Delete a Prospect."

The Marketing Cloud Account Engagement Connector is specifically designed to facilitate a bidirectional data sync between Marketing Cloud Account Engagement (formerly Pardot) and Salesforce CRM. Its primary function is to align sales and marketing data, such as leads, contacts, accounts, opportunities, and campaigns. It does not provide a native, direct connection to third-party SMS platforms like Twilio.

While it is possible to integrate Twilio with the Salesforce ecosystem, this is typically achieved by connecting Twilio to Salesforce CRM (often via an AppExchange application). Once SMS activity data is logged within Salesforce records (e.g., as Task or custom object records on a Lead or Contact), that data can then be synchronized to Account Engagement through the standard Salesforce-Account Engagement Connector. However, the connector itself is not the tool that establishes the initial connection to Twilio.

The "True" option is incorrect because it misrepresents the purpose and functionality of the Marketing Cloud Account Engagement Connector. The connector's defined endpoints are Account Engagement and Salesforce, not external third-party services like Twilio.

1. Salesforce Help Documentation: Salesforce Connector for Account Engagement. This document outlines the purpose of the connector, stating, "The Salesforce connector for Account Engagement syncs records between Account Engagement and Salesforce." It details the objects that are synced (Leads, Contacts, Accounts, Opportunities, etc.) and makes no mention of direct third-party platform connectivity.

Source: Salesforce Help, "Salesforce Connector for Account Engagement," Section: "How Data Syncs with the Salesforce Connector."

2. Salesforce Help Documentation: Account Engagement Connectors. This section of the documentation lists the available native connectors for Account Engagement. These include connectors for webinar services (like Webex, GoToWebinar), event platforms, and advertising platforms (like Google Ads). Twilio is not listed as a native, out-of-the-box connector.

Source: Salesforce Help, "Extend Account Engagement with Connected Apps," Section: "Marketing App Extensions."

3. Salesforce AppExchange Documentation: The official marketplace for Salesforce applications lists solutions for integrating Twilio with Salesforce CRM, not directly with Account Engagement. For example, the "Twilio for Salesforce" app states it "brings Twilio's communication APIs to the Salesforce Platform." This confirms the standard integration pattern is Salesforce-centric, with Account Engagement then leveraging the data synced from Salesforce.

Source: Salesforce AppExchange, Listing for "Twilio for Salesforce," Description section.

The requirement is to send emails from the owner of the customer's account. Marketing Cloud Account Engagement provides a specific sender option called "Account Owner." When this setting is selected for an email send, the system dynamically populates the sender's name and email address with the information from the user who owns the Salesforce Account record associated with the recipient prospect. This directly and efficiently fulfills the stated business requirement without needing custom configurations. This feature is designed to personalize communication and align it with account management structures in the CRM.

A. Set the sender of the email as a specific user. This option is static and would send all emails from a single, predefined user, failing to meet the dynamic requirement based on account ownership.

B. Set the sender of the email as a custom CRM user. This is not a standard, out-of-the-box sender setting. While achievable with workarounds, it is not the direct or intended solution for this common use case.

D. Set the sender of the email as the assigned owner. This option uses the owner of the prospect record (Lead or Contact owner), which can be different from the Account Owner, thus not meeting the specific requirement.

1. Salesforce Help, Marketing Cloud Account Engagement Documentation, "Considerations for Sending Emails." This document outlines the available sender options for emails. Under the "Sender" section, it explicitly lists "Account Owner" as an option, described as: "The user assigned as the account owner for a prospect who is associated with an account." This directly supports the correct answer.

2. Salesforce Help, Marketing Cloud Account Engagement Documentation, "Sending Emails with a Variable Sender." This guide details the process for setting up dynamic senders. It specifies the different variable sender types, clearly distinguishing between "Assigned User" and "Account Owner," reinforcing that "Account Owner" is the correct choice for this scenario.

3. Salesforce Help, Marketing Cloud Account Engagement Documentation, "Variable Tags in Account Engagement." This resource explains the different user-related variable tags. It shows distinct tags for the assigned user (%%assigneduser...%%) and the account owner (%%accountowner...%%), which technically underpins the functional difference between the "Assigned User" and "Account Owner" sender options.