How to export your data from Account Engagement before the contract ends
Prospect and activity records can be pulled from Account Engagement (formerly Pardot) through its asynchronous Export API, which produces CSV files. Program logic, scoring rules, grading rules and email templates are not exported as data, so they must be documented or rebuilt separately before the contract ends. Start with an inventory: list the prospect fields you rely on, the activity types you report on, and the programs, lists and scoring criteria that drive your nurture. That inventory tells you what the CSV files must contain and what you will rebuild by hand. Before you plan any extraction, confirm with Salesforce whether your Account Engagement edition includes API access and which connected app and OAuth setup your administrator must use. Ask your Salesforce account team to confirm the API call limits and the export file format for your org, because these settings determine how long a full pull takes and how many requests you can make. Do not assume that an edition with a CRM connector also includes the API access you need.
Salesforce CRM records stay in Salesforce. Accounts, contacts, opportunities, campaigns and campaign member statuses live in the CRM and must be exported there with the Salesforce data export tools or your org's reporting, not through Account Engagement. Match the two sets of records on a stable key, typically the Salesforce record ID that Account Engagement stores on each prospect, and keep that mapping in your migration file. Without it, activity history cannot be tied back to the right opportunities when you load Mautic. Plan the export as a dated, verified copy. Run a test extract on a small list, open the CSV files, check row counts against the Account Engagement interface, and store the files in an encrypted location that your compliance team approves. Record who ran each export, when, and which fields were included, because consent and suppression status must travel with each prospect. Confirm the retention terms in your contract so the export is complete before access ends.
Which Account Engagement data exports through the documented paths
This table maps each Account Engagement data type to the documented export path, the file format and the points you must confirm in Salesforce's current API documentation before planning the migration. Use it to see which records can move as CSV files through the asynchronous Export API and which must be rebuilt or re-collected in Mautic. Limits are deliberately left for you to verify, because they change between releases.
| Data type | Export path | Format and limits | What to confirm |
|---|---|---|---|
| Prospects | Export API job for prospect records | CSV output from an asynchronous job; row limits not stated here | Field list per job, row limits and whether your edition exposes the endpoint |
| Prospect activity | Export API job for prospect activity records | CSV output; date range filters and job limits to verify | Which activity types are included and how far back history reaches |
| Lists and list membership | Lists are exported as data sets, membership may need a separate job | CSV output; check whether membership is a separate export | Whether list membership comes back with prospects or needs its own pull |
| Custom fields | Field definitions read through the API, values carried in prospect exports | Values appear as CSV columns; field names may need mapping | Field API names so Mautic column mapping lines up correctly |
| Email and form activity | Covered only where the Export API documents the object | CSV output where available; coverage varies | Whether email sends, opens, clicks and form submissions are all exportable in your edition |
| Visitor activity | Tracking data may be exposed separately or not at all | Format and availability depend on the API object | Whether anonymous visitor history is retrievable, and retention periods in your org |
| Import into Mautic | Mautic contact import from CSV through the user interface | Automatic column to field mapping; large files via the import console command | Column headers match Mautic fields; deduplication rules and consent fields set before import |
What does not export as data, and the workaround for each
The Export API returns prospect and activity records as CSV files, but much of how an Account Engagement account works lives in configuration rather than in rows. Each card below names one category that typically does not come out as data, with a documented or manual workaround, and a point to confirm with Salesforce before you plan around it.
Engagement Studio program structure
Engagement Studio programs, their steps, branches and timing rules are configuration objects, so a prospect export shows only where each person sits in a program, not the program itself. Capture every program as a written flow specification listing triggers, wait steps, branch criteria and exit conditions, and take dated screenshots of the canvas as a reference. Ask Salesforce whether any program definition export is available for your edition before assuming none exists.
Scoring and grading rules
Scoring and grading rules are stored as account configuration. The export carries the resulting score and grade values on each prospect, but not the points, thresholds or criteria that produced them. Write each rule as a table of criterion, points, decay and grade threshold, then check a sample of exported prospects against that table so you can reproduce the numbers in Mautic's own scoring.
Email templates and page layouts
Email templates, landing pages and form layouts are built in the editor and are not prospect records, so they do not appear in a CSV. Check whether the editor offers an HTML export for each asset, save the rendered HTML with its merge fields and referenced images, and record which assets are live. Mautic will need these as rebuilt templates, so keep the source files under your own version control.
Sending domains and tracking configuration
Custom tracking domains, sending domain authentication and tracking code placement are account settings that the export does not capture. Record each domain, its DNS records and where the tracking script runs on your websites. These settings must be recreated in your new sending stack, and DNS changes can take time to propagate, so plan the cutover with that in mind and confirm the current setup with your Salesforce administrator.
Salesforce opportunities and campaign membership
Opportunities, campaign membership and Salesforce-side reports sit in Salesforce CRM, not in the Account Engagement export. Export these objects from Salesforce separately, and map the identifiers that link each prospect to its CRM record so the link survives the move. Confirm with your Salesforce administrator which fields are synced by the connector and which exist only on one side, because that determines what you can rebuild in Mautic.
The export sequence, from inventory to verified archive
This sequence moves Account Engagement data from an inventory of what exists to a verified, checksummed archive that can be reloaded or reconciled later. Marketing operations leads the work with the Salesforce administrator, and each step closes with a check so gaps surface before any source data is changed or retired.
Inventory every object and program in use
Marketing operations lists every Account Engagement object you rely on: prospects, custom fields, lists, tags, forms, landing pages, email templates, campaigns, Engagement Studio programs, and the activity types that feed reporting. For each item, note its owner, its record count in the interface, and whether Salesforce CRM holds the same data. This inventory becomes the checklist for every later step. It is done when each item has a row, a count, and a system of record, and the Salesforce admin has reviewed the list for CRM-side fields that Account Engagement only mirrors.
Confirm API access and connected app setup
Ask the Salesforce administrator to confirm which Account Engagement edition your account runs and whether that edition includes API access. Then confirm the connected app, its OAuth settings, the integration user, and the business unit identifier that API calls must use. Confirm the exact requirements in your own org, since editions and permissions change over time. The step is complete when a single authenticated read request returns records for a known prospect, and the account identifier in the response matches the one shown in the interface.
Run a test export on a small set
Choose a narrow test set, such as one list or a short date window that includes known activity, and submit it through the asynchronous Export API. Poll the job until it reports completion, then download the CSV output. Do not edit the files. Compare the row count with the count the interface shows for the same filter, open the file, and check that the headers match the field names from your inventory. The test passes only when counts reconcile and a sample of prospects and activity rows matches what staff see in the interface.
Run the full asynchronous export and download
Submit one export job per object or filter set from the inventory, using the parameters validated in the test. Because the Export API is asynchronous, poll each job until it is complete before downloading its CSV files. Save files under names that include the object, the filter, and the job identifier. Do not start a second job for the same scope until the first one has finished, so that each file traces back to exactly one job. The step is complete when every inventory row maps to at least one completed job and one downloaded file.
Record job parameters and checksums
Create a manifest with one entry per file. Each entry records the job identifier, object type, filters, date range, submission and completion times, the integration user, the file name, its size, and a SHA-256 checksum. Store the manifest beside the files. Then recalculate checksums on a copy of the archive and compare them with the manifest. The step is done when every recalculated checksum matches, and any mismatch has been traced to a re-run job with its own manifest entry.
Verify contents and store the archive
Open each CSV and confirm the headers, encoding, and delimiter match what the inventory expects. Reconcile row counts against the manifest and the interface, then sample records across the full date range to check identifiers, email fields, timestamps, and activity links to CRM records. Store the archive in an access-controlled location with encryption at rest and a retention period set by your data governance policy. The archive is verified when a second reviewer signs the reconciliation sheet and a restore test can read the files.
Who runs the export and what each team needs to provide
The Salesforce administrator owns the connection that lets an export run at all. Account Engagement works inside a Salesforce org, so the access starts with the connected app, the OAuth consent and the user accounts behind them. Confirm edition-level API availability with Salesforce before any work is scheduled, because the export cannot begin without it.
- Connected app and OAuth consent: Create or review the connected app, decide who approves the OAuth consent, and record the callback address and scopes the team agreed to.
- Edition and API access: Ask Salesforce in writing whether your Account Engagement edition and org include the API access the Export API needs. Do not assume it from the product name or the contract tier.
- User permissions: Name a dedicated integration user, grant only the profile and permission sets needed to read Account Engagement records, and document who can revoke access.
- Test org availability: Ask whether a sandbox or test org is available for trial runs before production credentials are used.
Before the Account Engagement administrator starts, check that the connected app, its consent record and the integration user are written down and approved.
The Account Engagement administrator knows what exists in the account and what the business relies on. This role defines the object inventory, documents the programs and rules that will need rebuilding, and decides which records are in scope. Without this inventory, the export may return files that look complete but leave out fields, activity or logic the team depends on.
- Object inventory: List prospects, custom fields, lists, tags, campaigns, activity types, forms and landing pages that the export must cover.
- Program documentation: Record each Engagement Studio program with its entry criteria, emails and branching, because these must be rebuilt as Mautic campaigns.
- Scoring and grading rules: Export the current scoring and grading logic so results can be compared after the move.
- Data scope decisions: Decide whether historical activity, suppressed prospects and opted-out contacts are in scope, and confirm how consent status is recorded.
- Field ownership: Mark which fields are maintained in Salesforce CRM and which exist only in Account Engagement, so nothing is exported twice or lost.
Ask the Salesforce administrator which objects the integration user can read, and finalize the inventory only after that answer is confirmed.
Marketing operations or the data team receives the files, stores them, sets retention and prepares them for import. Mautic imports contacts from CSV through its user interface with automatic column to field mapping. For large files, the project recommends a background import using the mautic:import console command run by cron, which processes rows in batches of 100 by default. Plan the file preparation around that path.
- File storage: Provide an encrypted location inside your own network for CSV files, with named access and a log of who downloads them.
- Retention rules: Set how long raw exports are kept and who approves deletion, aligned with your privacy and records policies.
- Import preparation: Normalize column headers, choose a unique identifier such as email address, and map each field to a Mautic contact field before any import begins.
- Consent and suppression: Confirm that opt-in status and unsubscribes travel with each contact, since sending to contacts without the right status creates legal and deliverability risk.
- Test import: Run a small file through the user interface first, then schedule the full import with the platform team, who own the cron configuration.
Confirm the storage location, retention period and consent fields with your privacy owner before the first file leaves Salesforce. The Mautic import documentation describes the import options in detail.
How OAuth connected apps control what the export can read
Before any export runs, the connected app and the user who authorizes it decide what data the job can see. Account Engagement calls go out with an OAuth access token issued for a Salesforce connected app, and the token carries the permissions and record visibility of the user who approved it. An export started under a user who can see every prospect will return every prospect. A user limited to certain campaigns, business units or record access will return a smaller, partial set, and the file will look complete even when it is not. Before you run anything, sign in as the exporting user and confirm they can see the prospects and activity you expect to move.
Use a named, individual account for the export rather than a shared administrator login or a generic integration user that many people can access. A named account gives you an audit trail of who requested the data and when, and it lets you reduce the permissions to the minimum the export needs. Ask your Salesforce administrator to confirm which connected app is used, which OAuth scopes it requests, whether the user's profile or permission sets grant access to the Account Engagement objects you need, and whether IP restrictions or session policies apply to that user. Treat these as the checks that matter most, and confirm the exact setup steps in the connected app and Account Engagement sections of Salesforce's documentation rather than relying on this page, since Salesforce changes its administration screens and authorization options over time.
Document the connected app configuration before you use it: its name, the callback and consumer settings, the scopes, the authorizing user, the date of the export and where the files were stored. Once the export is complete and verified, revoke the connected app or the user's access token so that the credential cannot be reused for later reads of prospect data. Keep the documentation with your migration record, because a later auditor or privacy reviewer will ask which credential touched personal data and when it was removed. If the export takes several passes, plan each pass under the same controlled setup and revoke at the end of the last one.
What to plan before renewal or termination
Exporting from Account Engagement is rarely a single download. The items below are decisions to settle before the contract end date, because each one sets the time, scope and sign-off needed for the export and the move. This page does not summarize your agreement, so read its data return and deletion terms before you plan dates.
Export window against contract end
Work backward from the contract end date to set the export window. Confirm how long data remains available after termination and whether any retention period applies before deletion. Because the Export API runs asynchronously and produces CSV files, leave time to request, download and validate each object, including prospects and activity, before access ends. Treat this as a dated plan, not an assumption.
Written terms for return and deletion
Ask the vendor to confirm in writing what it will return, in what format, and what it will delete afterward, including backups and derived copies. Read your own agreement for these terms, since this page does not summarize them. Keep the written answer with the export evidence so you can show later what was retained and what was removed.
Salesforce edition and connected app work
Confirm which Salesforce edition and Account Engagement edition you run, and whether your API access and connected app setup support the export. Authentication for API calls runs through OAuth with a connected app, so someone with Salesforce admin rights must create or review it before the export starts. Record the owner, the user it runs under and when its access is revoked.
Account Engagement items to rebuild
Make an inventory of what does not come across as data: Engagement Studio programs, automation rules, scoring and grading models, email templates, landing pages and forms. Export the prospect and activity records, but plan to rebuild the logic in the target, such as Mautic campaigns. Mark each item as export, rebuild or retire so nothing is lost by default.
Internal owner for sign-off
Name one accountable owner who approves the export scope, accepts the file set, and signs off the deletion request. Marketing operations, Salesforce administration and security or legal should each have a named contact. Without a single owner, validation stalls and deletion requests go out before the data is verified.
How to verify that a complete export is usable
Reconcile every export file against counts from both systems before anything is imported. Record the prospect count shown in Account Engagement for the export scope, then compare it with the row count in each CSV, excluding the header line. Repeat the check against the matching Salesforce records (Leads and Contacts, depending on how your org links prospects), because a prospect that exists in Account Engagement without a Salesforce link will look different in the two systems. Where counts differ, confirm whether the gap comes from filters, deleted records, suppressed contacts or a truncated download before you accept the file. Confirm the exact export parameters with your Account Engagement administrator, since the Export API is asynchronous and you should check that each job completed rather than assuming it did.
Next, inspect the content of the files, not only their size. Confirm that email is present and populated for every record you intend to migrate, that the Salesforce ID column is complete for prospects linked to CRM records, and that custom fields carry the values your team expects. Check character encoding and delimiters, because accented names and multi-line notes often break in spreadsheet tools. Then run a trial import into a non-production Mautic instance, using a sample of a few hundred rows that includes edge cases such as duplicate emails and blank fields. Mautic maps CSV columns to fields automatically in the user interface, so review every mapping and correct column headers in the source file before the full run. For large files, use the background import route instead: the mautic:import console command, run by cron, processes rows in batches of 100 by default, which is more reliable than a browser upload and leaves a log you can review. Check the Mautic import documentation for the options that match your Mautic version.
Finally, keep a signed verification record for each export batch. It should list the source job identifiers, the file names and checksums, the reconciled counts from both systems, the sample import results, the fields you chose not to migrate and the approver's name and date. Have the business owner of the data and your security or compliance lead sign it, because this record is the evidence that the migration preserved what you were obliged to keep. Retain it with the export files under your own retention rules, and confirm those rules with your legal and records teams.
What buyers ask before exporting Account Engagement data
How much effort does exporting Account Engagement data take?
Effort depends mostly on how much data sits in the account and how much of it has to be reshaped before Mautic can use it. The main drivers are the number of prospects, the volume of activity history you want to keep, the number of programs (Engagement Studio) that must be rebuilt, and how many custom fields need a matching field in the target system. Each extra custom field adds mapping and validation work. Ask your Salesforce administrator to inventory fields, lists and programs before anyone runs an export, because that inventory sets the real size of the job.
How long does the export take?
Duration is driven by the same factors as effort: record volume, the date ranges you choose, how many exports you run, and how long your team takes to check the output. Account Engagement's Export API works asynchronously and returns CSV files, so the wait is partly outside your control, and large exports need more checking. No duration is fixed here because none has been established for your account. Ask for a timeline in writing that names the export windows, the validation steps and the points where your administrators must approve work.
Can our team export the data without outside help?
Yes, a team with an administrator who knows both Salesforce and Account Engagement can run the export internally, provided the access and edition questions are settled first. The work involves authenticating through a connected app, calling the Export API, saving CSV output, and checking that record counts and key fields match what the account contains. Teams without this experience often underestimate the field mapping and the handling of opt-outs and consent history. External help is most useful for planning, scripting repeatable runs and documenting the result.
What do Salesforce and Account Engagement administrators need to provide?
The export needs two kinds of access. A Salesforce administrator must confirm that the Account Engagement connector is linked to the right org, and must create or approve the connected app used for OAuth. An Account Engagement administrator must confirm that the user has API access in the edition in use and must review what the export includes, such as prospects, activities and custom fields. Both should agree who holds the credentials, where the CSV files are stored, and who signs off that the data is complete before any system is switched off.
Which items will we need to rebuild rather than export?
Export moves records, not logic. Typically, the following must be rebuilt in Mautic:
- Engagement Studio programs, which become Mautic campaigns with their own triggers and actions
- Scoring and grading rules, which need to be recreated from the documented criteria
- Email templates, landing pages and forms, which must be rebuilt or re-imported separately
- Automation tied to Salesforce sync settings, which the Mautic Salesforce plugin handles differently
Confirm each category with your team so no active program is missed.
Do we need to confirm our edition or API access before starting?
Yes. Confirm before any planning begins whether your Account Engagement edition includes API access and whether the user who will run the export has the required permissions. Salesforce's B2B marketing automation product page describes Account Engagement as its B2B marketing automation product integrated with Salesforce CRM, but it does not replace a check of your own contract. Ask your Salesforce account contact to confirm the API entitlement in writing, and verify the connected app setup in a sandbox or test org first where possible.
What does a fixed-scope engagement with DeployOpen cover?
A fixed-scope engagement agrees the scope, deliverables and timeline in writing before work starts. For an export project, that typically covers an inventory of objects and programs, the export runs and file handling, validation of record counts and key fields, a field mapping document for the Mautic import, and handover notes. DeployOpen plans and implements self-hosted platforms in your own infrastructure and prepares evidence for compliance reviews, but it does not issue audit reports or certifications. DeployOpen does not publish a price list, and a quote follows from the written scope.
Is the exported data safe to keep outside Salesforce?
The CSV files contain personal data about prospects, so treat them as regulated records from the moment they leave the platform. Store them on encrypted systems with restricted access, record who exported them and when, and set a retention period that matches your privacy obligations. Do not send exports by unsecured email. Your privacy and legal teams should confirm the lawful basis for any copy you keep and how opt-out and consent data are carried across, since this varies by jurisdiction and contract.
How DeployOpen works on this
DeployOpen is a Chainscore Labs company that plans, implements, integrates, documents and supports self-hosted open-source platforms in the client's own infrastructure. For an Account Engagement data exit, we start by inventorying what sits in Salesforce and what sits in Account Engagement, then agree the export and import scope in writing before any work begins.
How we scope
- Inventory prospects, custom fields, activity types, lists and campaign history across both Salesforce and Account Engagement.
- Confirm with your team which Account Engagement edition and API access level your organization holds before export work starts.
- Agree in writing which records, date ranges and fields move, and which stay in Salesforce as the system of record.
How we build
- Set up the asynchronous Export API calls with a connected app and OAuth credentials scoped to the minimum required access.
- Validate the CSV output against record counts and sample rows, then map columns to Mautic contact fields before any import.
- Test the import into a staging Mautic instance, including duplicate handling and opt-out and consent field mapping.
How we hand over
- Deliver a written field mapping, reconciliation report and runbook covering each export job and its output files.
- Document where each data category now lives, how retention is handled and which copies remain in the source systems.
- Walk your administrators through the import process so the team can repeat or audit the exit independently.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing for the resulting Mautic environment are available as a retainer.
- Ask for a written quote based on your scope, record volumes and integration needs, since DeployOpen does not publish a price list.
