The 8 Flow Types in Marketing Cloud Next Explained for Beginners

In Marketing Cloud Next, campaigns reuse Salesforce CRM Flows as the main automation and orchestration engine. This is a significant shift from Marketing Cloud Engagement, where Journey Builder was the primary tool for building customer journeys and campaign logic. Instead of introducing another separate journey engine, Marketing Cloud Next builds on the existing Salesforce Flow platform, which makes Flow a natural replacement for many of the journeys we previously built in MCE.

The 8 Flow types in Marketing Cloud Next differ mainly by what starts the automation: a segment, an engagement event, a Data Cloud change, a CRM record change, a schedule, a platform event, another automation, or a user screen. That trigger choice matters because it controls when people enter, what data is available, how errors behave, and whether the flow is suitable for campaign automation or operational back-office logic. In practice, many build issues come from choosing a technically valid Flow type that does not match the marketing use case.

Why Flow type selection matters in Marketing Cloud Next

Marketing Cloud Next uses Salesforce Flow patterns for campaign automation, so the trigger is not just a setup option. It defines the entry source, execution timing, available context records, and downstream limits.

A campaign flow that starts from a segment behaves very differently from one that starts from a CRM record update. A segment-triggered flow is audience-driven. A record-triggered flow is object-driven. A schedule-triggered flow is time-driven. Those differences affect testing, suppression logic, personalization, retries, and reporting.

The important beginner shift is to stop thinking only in terms of “journeys” and start thinking in terms of trigger architecture. Marketing Cloud Next campaign automation is built around campaign flow concepts that define how marketing automations start and run, which makes the trigger decision one of the first design choices that should be documented.

The 8 Marketing Cloud Next Flow types at a glance

The easiest way to understand the eight Marketing Cloud Next Flow types is to separate them into marketing-specific triggers and Salesforce platform triggers.

Flow type	What starts it	Best fit	Main watchout
Segment-Triggered Flow	A person enters a Data Cloud segment	Audience-based campaigns	Segment refresh timing and identity rules
Engagement Event-Triggered Flow	A marketing engagement event occurs	Click-based or behavior-based follow-up	Tracking availability and event timing
Data Cloud-Triggered Flow	A Data Cloud event or data change qualifies	Data-driven activation	Data model and event volume
Record-Triggered Flow	A Salesforce record is created or updated	CRM lifecycle automation	Recursion, bulk processing, object context
Schedule-Triggered Flow	A schedule runs at a defined time	Batch checks and recurring processes	Not immediate or event-based
Platform Event-Triggered Flow	A platform event is published	Integration-driven automation	Requires event design and payload control
Autolaunched Flow	Another process calls it	Reusable logic and subflows	Does nothing unless invoked
Screen Flow	A user launches an interactive flow	Guided internal workflows	Requires human interaction

1. Segment-Triggered Flow

A Segment-Triggered Flow starts when someone qualifies for a segment, usually from Data Cloud audience logic. This is the most familiar Marketing Cloud Next Flow type for marketers because it maps closely to traditional audience entry in journey tools.

In practice, this flow type is best for lifecycle campaigns such as onboarding, win-back, cross-sell, renewal reminders, and loyalty campaigns. The segment defines who should enter, while the flow defines what should happen after entry.

A common implementation pattern looks like this:

• Build a segment for the target audience.
• Connect that segment to the campaign flow.
• Add decision logic for suppression, consent, or eligibility.
• Send messages or update campaign member status.
• Add waits, decisions, or exits based on behavior.

The key platform behavior is that the segment is the entry source. The flow is not watching every field on every Contact or Lead record directly. It reacts when the person qualifies through the segment process. That makes it powerful for audience strategy, but it also means segment refresh timing, identity resolution, and activation configuration matter.

A common issue is assuming segment-triggered automation is always instant. It is safer to treat it as segment-driven activation rather than a direct CRM field trigger. If a sales user updates a Contact field and expects the campaign to fire immediately, a Record-Triggered Flow may be the better fit.

Segment-triggered flows also need careful exit planning. If someone enters a segment and later stops qualifying, the flow does not automatically behave like a live audience filter unless the automation is designed to re-check eligibility. For example, if a customer enters a renewal campaign but renews before the second email, the flow should check renewal status again before sending the follow-up.

The practical difference is well captured by Segment-Triggered Flow behavior in Marketing Cloud Next, where the important concept is that entry comes from segment qualification rather than a simple record save.

When to use a Segment-Triggered Flow

Use this Flow type when the audience definition is the most important part of the automation.

Good examples include:

• Customers with high purchase intent
• Subscribers entering a loyalty tier
• Contacts becoming eligible for renewal nurture
• Leads matching a nurture segment
• Customers who have not purchased within a defined period

When not to use it

Avoid it when the trigger must happen immediately after a single operational event, such as a case being closed, an order being created, or a form being submitted into a CRM object. Those use cases usually fit Record-Triggered Flow, Platform Event-Triggered Flow, or Data Cloud-Triggered Flow better.

2. Engagement Event-Triggered Flow

An Engagement Event-Triggered Flow starts from a marketing engagement event. In beginner terms, it reacts to what someone did with a marketing message.

This Flow type is useful when behavior should drive the next step. For example, someone clicks a product link in an email, and the flow sends a follow-up message, updates a campaign status, or routes the person into a more relevant branch.

In practice, clicks are usually more reliable than opens for decisioning. Email opens can be affected by image loading, privacy features, and bot scanning. If the business action matters, such as sending a sales alert or moving someone into a high-intent audience, a click or form submission is usually a stronger signal than an open.

Common use cases

Engagement Event-Triggered Flow works well for:

• Follow-up after a high-value email click
• Updating campaign member status after engagement
• Sending a second message based on link category
• Triggering internal alerts when a prospect interacts with a priority offer
• Branching nurture paths based on engagement behavior

A practical example is a webinar promotion. If a contact clicks the “Register” link, an Engagement Event-Triggered Flow can update the campaign member status to “Interested” and then wait for registration confirmation before sending the next message.

Trade-offs and limitations

The biggest limitation is dependency on tracking data. If tracking is disabled, delayed, filtered, or affected by privacy tools, the flow may not behave the way the marketer expects.

Another issue is event volume. If a campaign sends to a large audience and every click can start automation, the flow should include entry criteria and duplicate prevention. Without guardrails, one person clicking the same link multiple times can create repeated processing unless the flow design prevents it.

For beginner builds, always decide whether the flow should react once per person, once per campaign, or once per event. Those are different designs.

3. Data Cloud-Triggered Flow

A Data Cloud-Triggered Flow starts when a qualifying Data Cloud event or data condition occurs. It is useful when the activation signal comes from unified customer data rather than a Salesforce CRM record alone.

This Flow type is often used when Marketing Cloud Next needs to respond to behavioral, calculated, or unified profile information. For example, a customer may cross a loyalty threshold, show product interest, abandon a journey step, or meet a calculated insight condition.

The practical value is that Data Cloud can bring together information from multiple systems. The trade-off is that the flow depends heavily on the Data Cloud model. If the data stream, identity mapping, or calculated logic is wrong, the flow will faithfully automate the wrong thing.

Common use cases

Data Cloud-Triggered Flow is a good fit for:

• Loyalty tier changes
• Product interest events
• Abandoned browse or abandoned cart signals
• Propensity score changes
• Unified profile changes that do not exist cleanly in CRM
• Cross-channel behavioral triggers

Implementation notes

Start by confirming the event or data object that will trigger the flow. Then check which fields are available to the flow at runtime. A common issue is assuming every profile attribute is automatically available in the trigger context. Often, extra lookup steps are needed to retrieve related profile, consent, or campaign data.

Data Cloud-triggered automation also needs volume planning. Behavioral events can be much higher volume than CRM lifecycle changes. If every browse event starts a flow, the design can become noisy and expensive to maintain. In practice, it is better to trigger from meaningful qualification events rather than raw low-value activity.

4. Record-Triggered Flow

A Record-Triggered Flow starts when a Salesforce record is created, updated, or deleted. This is one of the most common Salesforce Flow types, and it is still highly relevant in Marketing Cloud Next because many marketing processes depend on CRM data.

Use it when the business event is clearly tied to a Salesforce object. Examples include a Lead status change, Contact preference update, Campaign Member creation, Opportunity stage change, or Case closure.

The main difference from a Segment-Triggered Flow is precision. A Record-Triggered Flow reacts to a specific database transaction. If a Lead status changes from “New” to “Marketing Qualified”, the flow can start immediately from that record change.

Common use cases

Record-Triggered Flow works well for:

• Updating consent or preference fields
• Adding a person to a campaign when a CRM condition changes
• Reacting to Lead, Contact, Account, or Opportunity changes
• Creating follow-up tasks after campaign responses
• Keeping campaign member statuses aligned with CRM activity

Implementation notes

For marketing use cases, after-save flows are often more practical than before-save flows because campaign actions usually need related records, downstream updates, or external-side effects. Before-save flows are useful for fast field updates on the same record, but they are not ideal when the flow needs to create records, call subflows, or coordinate campaign activity.

A common issue is recursion. For example, a flow updates a Campaign Member, which triggers another flow, which then updates the Contact, which triggers the first flow again. In small tests this may not appear, but at production volume it can create hard-to-debug failures.

Record-triggered flows also need bulk-safe logic. What works for one Contact record in testing may fail when hundreds of records are updated through an import, integration, or data load.

5. Schedule-Triggered Flow

A Schedule-Triggered Flow runs at a defined time and processes records that match its configured criteria. It is best for recurring checks, batch updates, and maintenance-style automation.

In Marketing Cloud Next, this Flow type is useful when the timing matters more than a specific event. For example, every morning the flow can find campaign members who are due for a reminder, contacts whose renewal date is approaching, or leads that have been inactive for a set number of days.

This is not the same as real-time automation. If a customer becomes eligible at 10:05 AM and the flow runs at midnight, the customer waits until the next scheduled run.

Common use cases

Schedule-Triggered Flow is a good fit for:

• Daily renewal reminder checks
• Weekly inactive lead review
• Batch campaign status cleanup
• Scheduled suppression list updates
• Time-based eligibility checks
• Recurring internal alerts

Trade-offs and limitations

The main trade-off is timing. Schedule-triggered flows are predictable, but not immediate. That can be a strength for operational stability because batch processing is easier to monitor than thousands of individual real-time triggers.

A common issue is using schedule-triggered automation as a workaround for unclear entry logic. If the flow scans too many records and contains too much decisioning, it becomes slow, harder to test, and more likely to hit platform limits. The better pattern is to filter as tightly as possible before the flow starts processing records.

6. Platform Event-Triggered Flow

A Platform Event-Triggered Flow starts when a Salesforce platform event is published. This is useful when Marketing Cloud Next needs to react to an integration event rather than a direct CRM save.

Think of a platform event as a message that another system or process publishes. The flow subscribes to that message and runs when it arrives. This is a strong pattern for decoupling systems because the external system does not need to directly update multiple Salesforce objects or campaign records.

Common use cases

Platform Event-Triggered Flow works well for:

• Order shipped events
• Booking confirmed or cancelled events
• Webinar attendance events
• Subscription status events
• Product usage milestones
• External system alerts that should trigger marketing or CRM activity

Implementation notes

The event payload matters. If the platform event only includes an external customer ID, the flow may need to look up the related Contact, Lead, Account, or unified profile before doing anything useful.

A common issue is missing idempotency. If the same event is published twice, should the flow run twice or ignore the duplicate? Marketing automation usually needs duplicate protection, especially when the event can send a message, create a campaign member, or notify sales.

Platform events are powerful, but they require cleaner technical design than simple record triggers. Someone needs to define the event schema, publishing logic, retry behavior, and expected payload fields.

7. Autolaunched Flow

An Autolaunched Flow has no screen and no direct user interface. It runs when something else calls it, such as another flow, a button, Apex, an API process, or an automation pattern.

For beginners, the important point is simple: an Autolaunched Flow does not start by itself. It is reusable logic, not an entry source.

In Marketing Cloud Next implementations, Autolaunched Flows are useful for shared campaign logic. Instead of rebuilding the same eligibility checks in five campaign flows, create one Autolaunched Flow that checks consent, suppression, customer status, or campaign membership rules.

Common use cases

Autolaunched Flow is a good fit for:

• Reusable consent checks
• Campaign eligibility logic
• Standardized campaign member creation
• Lead routing helper logic
• Shared suppression checks
• Common error handling or logging patterns

Implementation notes

Design the input and output variables carefully. If the flow needs a Contact ID, Campaign ID, or segment member reference, define those as required inputs. If it returns an eligibility decision, return a clear boolean value or status string.

A common issue is building too much logic into a subflow without documenting what it expects. Six months later, another campaign flow calls it with missing or incorrect variables, and the failure appears in the parent flow rather than where the real logic lives.

Autolaunched Flows are excellent for maintainability, but they should be treated like reusable components. Keep them focused and predictable.

8. Screen Flow

A Screen Flow is an interactive flow that displays screens to a Salesforce user. It is not a background campaign automation tool. It is a guided user experience.

In Marketing Cloud Next projects, Screen Flows are useful when a human needs to review, choose, confirm, or enter data before automation continues. For example, a marketer might use a Screen Flow to create a campaign request, select an audience type, confirm consent handling, or capture briefing information from sales.

Common use cases

Screen Flow works well for:

• Campaign intake forms inside Salesforce
• Guided preference updates by service agents
• Sales-assisted opt-in capture
• Manual campaign member review
• Internal approval or exception handling
• Guided setup for repeatable marketing processes

Trade-offs and limitations

The limitation is that a Screen Flow requires a user session. It should not be used for automated campaign entry, engagement response, or background sends.

A practical pattern is to pair Screen Flow with Autolaunched Flow. The Screen Flow collects user input, then calls an Autolaunched Flow to perform the reusable backend logic. This keeps the user experience separate from the automation logic.

Marketing-specific Flow types vs platform Flow types

Not all Flow types in Marketing Cloud Next serve the same purpose. Some are clearly marketing entry triggers, while others are Salesforce platform automation tools that support the marketing process.

Marketing-oriented triggers

These are usually closest to campaign automation:

• Segment-Triggered Flow
• Engagement Event-Triggered Flow
• Data Cloud-Triggered Flow

They are useful when the starting point is audience membership, customer behavior, or unified customer data.

Platform-oriented triggers

These are broader Salesforce automation patterns:

• Record-Triggered Flow
• Schedule-Triggered Flow
• Platform Event-Triggered Flow
• Autolaunched Flow
• Screen Flow

They are useful when marketing automation needs to connect with CRM records, integrations, internal users, or reusable logic.

In practice, mature Marketing Cloud Next implementations use both. A segment-triggered campaign may call an Autolaunched Flow for eligibility checks. A record-triggered flow may update campaign membership. A screen flow may collect marketer input before campaign setup begins.

How to choose the right Marketing Cloud Next Flow type

The safest way to choose is to identify the real trigger before opening Flow Builder.

If the audience definition starts the campaign

Use a Segment-Triggered Flow.

Example: “Send a renewal nurture campaign to customers entering the renewal eligibility audience.”

The audience is the trigger. Segment logic should control who enters.

If customer behavior starts the next step

Use an Engagement Event-Triggered Flow.

Example: “When someone clicks the pricing link in an email, update their campaign status and send a sales alert.”

The engagement event is the trigger. The flow should include duplicate handling if multiple clicks are possible.

If unified data or behavioral data starts the automation

Use a Data Cloud-Triggered Flow.

Example: “When a customer crosses a product interest threshold, add them to a relevant campaign path.”

The Data Cloud event or data condition is the trigger. Confirm the data model and identity rules before building the automation.

If a CRM record change starts the process

Use a Record-Triggered Flow.

Example: “When Lead Status changes to Marketing Qualified, create a campaign member and notify the owner.”

The Salesforce record transaction is the trigger. Watch for recursion and bulk update behavior.

If time starts the process

Use a Schedule-Triggered Flow.

Example: “Every morning, find campaign members whose reminder date is today.”

The schedule is the trigger. Keep the record filter tight to avoid unnecessary processing.

If an external system starts the process

Use a Platform Event-Triggered Flow.

Example: “When the commerce platform publishes an order shipped event, update the customer record and trigger a post-purchase campaign.”

The integration event is the trigger. Build duplicate protection and payload validation into the design.

If another automation needs reusable logic

Use an Autolaunched Flow.

Example: “Check whether a contact is marketable before any campaign flow sends a message.”

The parent process is the trigger. Define input and output variables clearly.

If a person needs to make choices on screen

Use a Screen Flow.

Example: “Let a service agent update a customer’s communication preferences through a guided form.”

The user interaction is the trigger. Keep screen logic separate from reusable backend automation where possible.

Common beginner mistakes with Marketing Cloud Next Flow types

Choosing Segment-Triggered Flow for real-time CRM updates

A segment-triggered design is usually not the right answer when the business expects immediate action after a record save. If the requirement says “as soon as Lead Status changes”, use a Record-Triggered Flow unless there is a specific reason to route the logic through Data Cloud segmentation.

Treating engagement events as perfect intent signals

Clicks are useful, but they are not perfect. Bot clicks, repeated clicks, forwarded emails, and tracking limitations can affect behavior-based automation. For high-value actions, add extra checks before triggering sales alerts or changing lifecycle status.

Building everything in one large campaign flow

Large flows become hard to test and harder to debug. A better pattern is to use the entry Flow type for orchestration and call Autolaunched Flows for reusable checks, updates, and logging.

Forgetting consent and suppression checks

Audience entry does not automatically mean a person should receive every message. In practice, eligibility should be checked close to the send or action step, especially when flows include waits.

Ignoring re-entry rules

Before building, decide whether the same person can enter once, once per campaign, once per segment qualification, or multiple times. This matters most for Segment-Triggered, Engagement Event-Triggered, Data Cloud-Triggered, and Platform Event-Triggered Flows.

Testing with one record only

Many Flow types behave differently at volume. Record-triggered and schedule-triggered flows especially need bulk testing. Platform event and engagement-triggered designs also need duplicate-event testing.

Practical design pattern for beginners

A clean Marketing Cloud Next automation usually separates entry logic, eligibility logic, action logic, and error handling.

Entry logic

The Flow type handles entry. Segment-triggered flows receive people from audience qualification. Record-triggered flows receive CRM record changes. Platform event-triggered flows receive integration events.

Keep the entry criteria narrow. The more precise the trigger, the less defensive logic the flow needs later.

Eligibility logic

Eligibility checks should confirm whether the person still qualifies. This is especially important after waits.

Typical checks include:

• Consent status
• Suppression status
• Customer lifecycle status
• Recent purchase or conversion
• Existing campaign membership
• Frequency rules

In practice, eligibility logic is a strong candidate for an Autolaunched Flow because it is reused across campaigns.

Action logic

Action steps perform the actual work: send a message, update a record, create a campaign member, notify a user, or call another process.

Keep action steps easy to trace. If one flow sends messages, updates CRM, and handles integration responses in the same branch, troubleshooting becomes painful.

Error handling

Every production flow should have fault paths for important actions. At minimum, capture enough information to identify the record, campaign, trigger source, and failed step.

A common issue is treating flow errors as rare edge cases. In real implementations, errors happen because of missing permissions, unexpected null values, deleted records, duplicate data, or integration timing. Clear fault handling makes those failures manageable rather than invisible.

Share With Others