Exact Target: Marketing Cloud Guide | SalesforceTutorial

Exact target is the name many Salesforce teams still use for the platform now documented as Marketing Cloud Engagement. Salesforce acquired Exact Target in 2013, and the old name still appears in login URLs, administrator habits, integration notes, and search queries. In practice, an admin who says exact target usually means Marketing Cloud Engagement features such as Email Studio, Journey Builder, Automation Studio, data extensions, business units, and Marketing Cloud Connect.

This guide explains the name change, where the Salesforce Exact Target login fits, how Marketing Cloud Engagement connects to Sales Cloud and Service Cloud, and what developers must check before using Marketing Cloud APIs. It also compares the older exact target architecture with newer Salesforce marketing products so you can choose the right implementation path.

Exact Target in Salesforce: what the name means in 2026

Exact target is not a separate current Salesforce product that admins buy as a standalone application. It is the legacy product name behind Salesforce Marketing Cloud Engagement. Salesforce announced the agreement to acquire Exact Target on June 4, 2013, and completed the acquisition on July 12, 2013. The product later became part of the Salesforce Marketing Cloud family.

The name still matters because many production orgs were implemented before the rebrand. You can see it in bookmarked URLs, old implementation runbooks, managed package labels, API credentials, support tickets, and training notes. A support request that says “Exact Target is down” may actually refer to Email Studio sends, Journey Builder entry events, Automation Studio query activities, or a Marketing Cloud Connect issue.

In enterprise orgs, I treat exact target as a vocabulary translation problem before treating it as a technical problem. First identify the current product, then identify the tenant, business unit, MID, integration user, and feature area. That prevents teams from applying Sales Cloud assumptions to a Marketing Cloud Engagement issue.

How Exact Target maps to current Salesforce products

Salesforce marketing product names have changed over time. The safest way to document an implementation is to record both the old name users know and the current Salesforce name from Help or Developer documentation.

Marketing Cloud ExactTarget: name mapping for admins

The phrase marketing cloud exacttarget usually appears when an admin is searching for the older product name but needs current Marketing Cloud Engagement documentation. If a runbook, folder, or dashboard still says marketing cloud exacttarget, translate that label to Marketing Cloud Engagement before assigning work. Keep marketing cloud exacttarget as a search alias only when it helps users find legacy notes.

ExactTarget Marketing Cloud: current product names

ExactTarget Marketing Cloud often means a legacy implementation that has been running for years. Before making changes, inspect the business-unit structure, installed packages, send classifications, automations, triggered sends, and Marketing Cloud Connect package version. Old naming can hide active dependencies.

ExactTarget Salesforce: where CRM integration starts

ExactTarget Salesforce integration usually points to Marketing Cloud Connect. This is the managed Salesforce integration path that lets Marketing Cloud Engagement work with Sales Cloud or Service Cloud records. It does not remove the need to manage users, data extensions, and permissions inside Marketing Cloud Engagement.

Salesforce ExactTarget login: where admins sign in

The current Salesforce Help article for Marketing Cloud Engagement login documents the login URL as https://mc.exacttarget.com/cloud/login.html. That is why the phrase salesforce exacttarget login still receives searches even though the current product name is Marketing Cloud Engagement.

Use this checklist when a user cannot sign in:

1. Confirm whether the user is trying to access Marketing Cloud Engagement, Salesforce CRM, Account Engagement, or Marketing Cloud Next.
2. Ask for the MID or business unit name, not only the company name.
3. Check whether the account uses a Marketing Cloud username/password flow, Salesforce single sign-on, or an identity-provider initiated link.
4. Verify that multi-factor authentication and identity policies match the company standard.
5. Confirm the user has the right Marketing Cloud role and the correct business unit access.
6. If Marketing Cloud Connect is involved, confirm that the user also has the required Sales or Service Cloud access.

A common mistake is sending a Marketing Cloud user to the standard Salesforce CRM login page and then troubleshooting profile permissions. Marketing Cloud Engagement has its own user model. Salesforce Help also notes that Marketing Cloud Connect users need both Marketing Cloud Engagement and Sales or Service Cloud access for most connected features.

How the Exact Target architecture differs from Salesforce Core

Exact target came into Salesforce through acquisition, so experienced Salesforce admins should not assume it behaves like a standard Salesforce Core app. Marketing Cloud Engagement has its own tenant concepts, including business units, member IDs, installed packages, data extensions, send classifications, automations, journeys, and subscriber keys.

The difference affects security, deployments, and support:

This distinction also changes how you troubleshoot. A broken journey entry source may come from data extension keys, contact key values, automation timing, suppression logic, or an API token problem. It may have nothing to do with Salesforce record sharing.

How Marketing Cloud Connect links Salesforce CRM and Marketing Cloud Engagement

Marketing Cloud Connect lets teams use Marketing Cloud Engagement features with Sales Cloud or Service Cloud data. It is the standard integration path for many exact target environments that need CRM campaigns, reports, sends, and synchronized data.

Use Marketing Cloud Connect when you need CRM-aware marketing operations, such as sending to Salesforce campaign members, using Sales Cloud data in segmentation, or returning tracking information to CRM users. Use a separate API integration when the source system is not Salesforce CRM, when the data volume needs a bulk pattern, or when middleware must transform the payload before Marketing Cloud receives it.

Implementation checklist for Marketing Cloud Connect

1. Confirm supported editions, licenses, and business-unit strategy before installing or changing the package.
2. Create named integration users rather than tying the connection to a personal admin account.
3. Map the subscriber key strategy to CRM identifiers. For most Salesforce CRM integrations, the Contact ID or Lead ID is easier to govern than an email address.
4. Decide which CRM objects should synchronize. Do not sync every field because it exists.
5. Review field-level security and object permissions for the Salesforce integration user.
6. Test sends, tracking, unsubscribe behavior, and report visibility in a sandbox or non-production business unit where possible.
7. Document failure handling for sync delays, duplicate records, merged leads, and deleted CRM records.

For related architecture patterns, see our Salesforce Marketing Cloud overview, Salesforce Data Cloud architecture, and Salesforce API integration guide.

Data extensions, subscribers, and consent design

Marketing Cloud Engagement data design starts with the subscriber key. Do not treat email address as a permanent identity unless the business has accepted that limitation. Email addresses change, people can share inboxes, and one person may have multiple addresses. In CRM-connected exact target implementations, Contact ID, Lead ID, or a governed customer identifier is usually easier to reconcile.

Salesforce Help describes a data extension as a table used to store data for queries, targeting, and sends. In production, design each data extension with these questions answered:

• Purpose: Is this table a sendable audience, a staging table, a log table, or a reference table?
• Primary key: Which field or field combination prevents accidental duplicates?
• Send relationship: Which field maps to Subscriber Key, Customer Key, Subscriber ID, or Email Address?
• Retention: How long should the table or rows remain?
• Consent: Which source owns opt-in, opt-out, publication list, and suppression logic?
• Data classification: Does the table contain personal data that requires restricted access or deletion handling?

Example SQL Query Activity pattern

Automation Studio supports query activities for building segments from data extension data. The example below writes qualified contacts from a profile data extension into a sendable target data extension. The field names are examples; use your own data extension names and keys.

SELECT
    c.SubscriberKey,
    c.EmailAddress,
    c.Locale,
    GETDATE() AS LastQualifiedDate
FROM Customer_Profile c
WHERE c.EmailAddress IS NOT NULL
  AND c.ConsentEmail = 1
  AND c.CountryCode IN ('US', 'CA')

Keep SQL activities small enough to support the automation schedule. If the audience requires heavy joins, multiple sources, or cross-cloud identity rules, consider using Data Cloud segmentation or upstream data preparation instead of putting every transformation into Automation Studio.

Developer notes for Marketing Cloud Engagement APIs

Marketing Cloud Engagement has REST and SOAP APIs for account configuration, campaigns, journeys, triggered messaging, data extensions, and related operations. The authentication pattern differs from Salesforce Core REST API. For server-to-server integrations, Salesforce Developer documentation describes installed packages and OAuth token requests using the package credentials and the authentication base URI.

The token response includes an access token and base URLs that your app should use for subsequent API calls. Store the access token like a credential. Do not expose the client secret or token to LWC, mobile apps, browser JavaScript, or public repositories.

Server-to-server token request example

curl --request POST "{{AUTH_BASE_URI}}/v2/token" \
  --header "Content-Type: application/json" \
  --data '{
    "grant_type": "client_credentials",
    "client_id": "{{CLIENT_ID}}",
    "client_secret": "{{CLIENT_SECRET}}",
    "account_id": "{{BUSINESS_UNIT_MID}}"
  }'

Use the account_id only when the installed package and business-unit design require that context. In multi-business-unit implementations, tokens can represent a specific MID, so document which integration writes to which unit. This prevents a staging integration from inserting rows into a production audience.

API design checklist

• Use installed packages: Create a package for the integration and grant only the scopes required for the job.
• Separate environments: Keep production credentials, test credentials, and developer credentials separate.
• Respect rate and job limits: Batch large imports and use bulk or asynchronous patterns where Salesforce documentation recommends them.
• Log correlation IDs: Store request IDs, payload keys, and Marketing Cloud response status so support can trace failures.
• Make retries safe: Use external keys and idempotent upsert patterns where the API supports them.
• Protect secrets: Store credentials in a server-side secret store. In Salesforce Core callouts, use Named Credentials or an approved enterprise secret pattern.

If the integration begins in Sales Cloud, review callout limits, transaction boundaries, and retry design. Do not perform high-volume Marketing Cloud writes synchronously from triggers. Use middleware, Platform Events, Queueable Apex with callout controls, or scheduled batch processing depending on the volume and latency requirement.

Journey Builder and Automation Studio in old Exact Target orgs

Journey Builder and Automation Studio are often the two areas where older exact target implementations need cleanup. Journey Builder manages single-send, transactional, and multi-step customer journeys. Automation Studio handles scheduled imports, SQL query activities, file transfers, extracts, and related workflow tasks.

In a production audit, look for these risks:

• Journeys still running with old entry source data extensions that no one owns.
• Automation Studio activities that overwrite the same audience table used by an active journey.
• SQL queries that use email address as the only identity key.
• Paused or draft journey versions that contain business-approved content but were never documented.
• Triggered sends or transactional messages without a clear monitoring owner.
• Suppression lists managed outside the normal consent process.

A clean handover document should list the journey name, version, entry source, target audience, send classification, suppression logic, exit criteria, owner, monitoring schedule, and rollback step. That documentation matters more than the old Exact Target label.

ExactTarget Marketing Cloud vs Marketing Cloud Next

Salesforce now documents Marketing Cloud Engagement alongside newer Marketing Cloud Next capabilities. Marketing Cloud Next brings more Salesforce platform alignment to marketing work, and Salesforce release notes describe Growth Edition capabilities such as emails, landing pages, forms, Salesforce CMS backing, and SMS availability as an add-on in supported contexts.

That does not mean every exacttarget marketing cloud implementation should be replaced. Existing Marketing Cloud Engagement customers may have years of journeys, data extensions, APIs, preference centers, AMPscript, SQL, and operational processes. Moving those workloads requires a migration plan, not only a license decision.

Best practices for maintaining an Exact Target Salesforce implementation

Use these practices when maintaining an exacttarget salesforce environment that supports active campaigns:

1. Create a current terminology map. Record old labels such as exact target, SFMC, Email Studio, and ExactTarget Marketing Cloud beside current Salesforce product names.
2. Govern business units. Give each business unit a clear owner, MID, purpose, sender profile, and data boundary.
3. Document subscriber key rules. Write down the source of truth for subscriber key values and the process for merges, deletes, and email changes.
4. Limit admin access. Do not give broad Marketing Cloud roles to users who only need content or reporting access.
5. Review installed packages quarterly. Remove unused credentials and rotate secrets according to company policy.
6. Version journeys deliberately. Keep a change log when a journey version changes entry criteria, wait logic, send content, or exit rules.
7. Monitor automations. Assign owners for failures, skipped imports, query errors, and file-transfer delays.
8. Separate consent from targeting. Targeting decides who qualifies for a campaign. Consent decides who may receive it. Keep those rules explicit.
9. Plan API retries. Integration errors should not create duplicate subscribers, duplicate send events, or inconsistent opt-out records.
10. Use official release notes. Marketing Cloud capabilities vary by edition, region, and release, so check Salesforce Help and release notes before promising a feature.

For adjacent topics, review Salesforce Flow automation patterns for Core automation boundaries and Pardot and Marketing Cloud Account Engagement if the business is comparing B2B lead nurturing tools with Marketing Cloud Engagement.

Common errors with Exact Target projects

Treating Marketing Cloud Engagement like a Salesforce object model

Salesforce Core objects have record-level security, field-level security, triggers, validation rules, and API versions. Marketing Cloud Engagement data extensions do not inherit those mechanics automatically. Design access, validation, and retention separately.

Using email address as the permanent subscriber key

Email addresses work as a send address, but they are weak identifiers for long-term customer history. Use a governed customer key, Contact ID, Lead ID, or similar stable identifier when your CRM and consent processes support it.

Skipping the Salesforce ExactTarget login model during onboarding

Users often search for salesforce exacttarget login because old bookmarks and current Marketing Cloud URLs still include the exacttarget domain. Give admins a short login runbook that covers the Marketing Cloud login page, SSO behavior, MFA, and business-unit access.

Moving journeys without dependency checks

A journey can depend on data extensions, entry sources, content blocks, send classifications, suppression lists, API events, and automations. Exporting or rebuilding only the visible canvas misses the operational dependencies.

Exposing API secrets to client-side code

Marketing Cloud installed package credentials belong on the server side. A Lightning Web Component, public website, or mobile app must not hold the client secret. Use server-side middleware or approved Salesforce secret management.

Official Salesforce documentation to verify before publishing changes

• Salesforce announcement of the Exact Target acquisition agreement
• Salesforce announcement of the completed Exact Target acquisition
• Salesforce Help: Marketing Cloud Engagement login
• Salesforce Help: Marketing Cloud Connect
• Salesforce Developer Docs: Marketing Cloud API integrations
• Salesforce Developer Docs: server-to-server access tokens
• Salesforce Developer Docs: Marketing Cloud Engagement REST API reference
• Salesforce Help: Marketing Cloud Next

Frequently Asked Questions