Journey Builder is where a Marketing Cloud interview gets serious. The panel has already checked whether you can build an email. Now they want to know whether you can inject a contact into an automated flow, keep the data attached to that contact correct, and say what happens when the business changes its mind after the flow is live. These questions come from an interview question bank built for real Marketing Cloud rounds, covering entry sources, splits and waits, versioning, and the Contact Builder model underneath.
Entry sources and entry criteria
What is Journey Builder?
Journey Builder is the orchestration tool in Marketing Cloud, where an entry source decides which contacts come in and a canvas of activities decides what happens to them. A journey runs per contact rather than per batch, so each contact moves on their own clock, unlike Automation Studio which processes a whole set of records in one run.
What are Entry Sources in Journey Builder?
The entry source is the trigger that injects contacts. You choose one per journey version, and that choice fixes how the journey behaves for the rest of its life.
| Entry source | How contacts come in | What it can and cannot do |
|---|---|---|
| Data Extension | On an evaluation schedule, from a sendable data extension | Batch and file driven work. Not real time. Picks up only what exists when the evaluation runs |
| API Event | A REST call fires an event for one contact | Real time, one contact per call, carries a payload. Needs a developer at the other end and a running journey |
| Salesforce Data | A record is created or updated in Sales or Service Cloud | Near real time. Needs Marketing Cloud Connect and a synchronised object |
| Audience | An audience built in Audience Builder | Only where Audience Builder is licensed |
| CloudPages form | A Smart Capture form submission | Sign up flows. Tied to the page and the data extension behind it |
| Behavioural trigger | Collect tracking code raises an abandonment event | Cart and browse abandonment. Depends on correct site tagging |
If you cannot say which entry source your last project used and why the alternative was rejected, the answer sounds borrowed. Interviewers go five levels deep on a project claim.
What is a Data Extension Entry Source?
The journey watches a data extension and injects records on a schedule you configure, picking up rows added since the last evaluation. Marketing Cloud expects a sendable data extension here, because it has to relate each row to a contact key. The usual design is a query activity that writes today's eligible population into that table, with the evaluation scheduled after the automation finishes.
What is an API Event Entry Source, and how do you configure it?
An API Event injects a single contact in real time. Define the event against a data extension that describes the payload, note the event definition key Journey Builder generates, and publish the journey, because a journey that is not running will not accept events.
The fields on that data extension become the journey data for the contact, so design the payload before the canvas. A custom event works the same way against your own schema, for a process such as a policy renewal.
How do you trigger a journey via API?
Authenticate against the REST auth endpoint, take the access token, then post the event.
POST /interaction/v1/events
{
"ContactKey": "CUST-10045",
"EventDefinitionKey": "APIEvent-8f1c2a",
"Data": { "OrderId": "SO-99213", "OrderValue": 4999 }
}
A success response means the event was accepted, not that the contact entered, because entry criteria or the re-entry mode can still block it.
What is a Salesforce Data Entry Source?
With Marketing Cloud Connect in place, the journey listens to a synchronised Sales or Service Cloud object and injects contacts when a record is created or updated and matches your filter. The object has to be set up as a synchronised data source first, and injection depends on that sync, so call it near real time rather than instant.
What is journey re-entry configuration, and what are the re-entry options available?
Re-entry decides whether a contact who has already been in this journey can come in again. It is set in journey settings, applies to the whole version, and cannot be changed while that version is running.
| Mode | Behaviour | When to use it |
|---|---|---|
| No re-entry | The contact enters once, ever, even after exiting | One time programmes such as a welcome series |
| Re-entry anytime | The contact can be in the journey more than once at a time, as separate instances | Transactional flows such as order confirmation |
| Re-entry only after exiting | The contact can return, but only after the previous instance ends | Recurring campaigns such as abandoned cart, where overlap means duplicate mails |
The classic mistake is choosing re-entry anytime for a promotional flow and then wondering why one contact received four copies. Know when the rule is checked as well as what it says. It is evaluated at injection, so a blocked contact never appears on the canvas at all.
How do you allow re-entry after 10 days?
No setting says wait ten days, so you build the gap. Either hold the contact inside the journey, with re-entry only after exiting and a ten day wait at the end of the canvas, or write a last entry date at entry and exclude anyone within ten days of it from the query that builds your entry population.
What is Contact Data versus Journey Data?
Journey data is the payload that arrived with the entry event. It belongs to that instance of the contact and stays as it was at injection. Contact data comes from the contact model in Contact Builder and is read when the activity runs, so it reflects the current value.
A split on journey data asks what was true at entry, and a split on contact data asks what is true now. Candidates who know the syntax but not the execution get caught here, because writing the reference is not the same as knowing when it runs.
Activities and flow control
Panels often ask you to name the activity types before asking how one of them works.
| Activity type | Examples | What it does |
|---|---|---|
| Message | Email, SMS, push, in app | Sends the message at that point in the flow |
| Flow control | Wait, decision split, engagement split, random split, path optimizer, join | Decides where the contact goes next and how long they pause |
| Update | Update contact, and Salesforce record actions | Writes data back to a table or to CRM |
| Custom | Activities installed in the account | Extends the canvas for vendor services |
What is a Decision Split?
A decision split routes contacts using attribute values from contact data or journey data, with a remainder path for anyone who matches nothing. Order matters, because contacts take the first path they qualify for, so put narrow conditions before broad ones.
What is an Engagement Split, and how do you use it for non-openers?
An engagement split routes contacts on how they engaged with a specific message earlier in the journey, such as opened or clicked. It evaluates as soon as the contact reaches it, so without a wait in front of it everybody lands on the not opened path.
For a resend, send the email, wait two or three days, then split on opened. The no branch goes to a fresh email activity with a different subject line, which keeps tracking clean for the second attempt.
What are Exit Criteria, and how do you exit contacts based on a purchase event?
Exit criteria are evaluated for contacts inside the journey and pull them out before they reach the end. They are set on the journey rather than on an activity, so they apply at every point on the canvas.
For a purchase, the contact has to be able to see the event, so the data must reach the contact model and not sit in a reporting table.
- Land purchase data in a data extension keyed on the contact key, updated by your integration or by an hourly query activity.
- Link that data extension into the contact model so the attribute is available to the journey.
- Set exit criteria such as purchase flag equals true, or purchase date later than entry date.
- Check the refresh frequency of the source, because exit criteria cannot act on data that arrives a day late.
How do you handle an email change mid-journey?
A contact carries the data captured at injection, so updating the address on the source data extension does not update a contact already in flight. Keep the address on a contact model attribute so it is read at send time, or let the current instance finish and let the corrected record enter again.
Versioning and running journeys
Can you edit a live journey?
Structural change is not allowed on a running version. You cannot add or remove activities, change the entry source, or change the re-entry setting while contacts are moving through it, so to change the shape of the flow you create a new version.
Some things change without a new version. Editing the content of an email asset that an activity already points to affects contacts who have not yet reached that send, because the activity references the asset rather than a frozen copy. Changing which email is used is a canvas change and needs a new version.
Pausing holds contacts where they are and they continue when you resume, within the pause window Marketing Cloud allows, while stopping ejects everyone in that version. Stop is not an undo button.
What happens to contacts already in a live journey?
When you publish a new version, the older version stops accepting new entries and the new version takes over injection. Contacts already inside the old version stay there and finish in it, following the old canvas with the old waits and the old sends.
Both versions therefore run at the same time until the last contact in the old one exits, and nothing migrates contacts between them. If the change must reach people already in flight, either let the old version drain when the flow is short, or stop it and re-inject the affected contacts into the new version. This is why a canvas with long waits is built with its second version already in mind.
How do you troubleshoot a journey email not triggering, and how do you debug journey failures?
Walk the path the contact takes instead of guessing, because being able to answer this beats being able to define the activity. Test journeys the same way, with internal contact keys forced down each path and shortened waits, and verify in journey history rather than the inbox.
- Is the version running, and is it the version you edited. People publish version two and then inspect the canvas of version three.
- Did the contact enter at all. Check journey history for that contact key, because no entry means the problem is on the entry side.
- For an API event, check the response from the call, since a wrong event definition key or a missing contact key means nothing was accepted.
- For a data extension entry source, check the evaluation schedule and whether the row existed when the evaluation ran.
- Check re-entry, because with no re-entry set a contact who was in the journey earlier is blocked silently.
- Check entry criteria and any split before the email, since the contact may be in the journey but on another path, and check whether they are still sitting in a wait.
- Check the subscriber side, as unsubscribed, held or bounced addresses do not receive the send.
- Check the email activity itself, including send classification and any exclusion script, then the send log and tracking.
The contact model underneath
What is Contact Builder, and what is Contact Key mapping?
Contact Builder is where you define what a contact is in this account. It holds the contact record, the attribute groups that link data extensions to that contact, the relationships between them, and the contact deletion settings. Your data stays in the data extensions, and Contact Builder only describes how those tables relate to one contact.
The contact key is the single identifier for a contact in the account. Contact key mapping is the step in Data Designer where you tell Marketing Cloud which field in each attribute set carries that identifier, so a row in an orders table and a row in a profile table are recognised as the same person.
Three points are worth making. Use a stable source system identifier rather than the email address, because addresses change. Keep the value consistent in format across every source that writes it, since a mismatch creates a second contact rather than an error. And treat the key as permanent, because correcting one means deleting the contact and creating it again.
What is an Attribute Group?
An attribute group is a container in Data Designer holding related attribute sets, which are the data extensions or synchronised objects linked to the contact record. Grouping keeps the model readable, for example one group for profile and one for purchases. Once an attribute set is linked, its fields become available for segmentation and for decision splits in Journey Builder, which is the whole reason the group exists.
A population is a special attribute group that defines a set of contacts rather than a set of attributes, for example customers as against employees, and a contact belongs to only one population. Many implementations never use populations, and saying so plainly is a better answer than pretending every model needs one.
What are relationship types in Contact Builder?
You set cardinality when linking one attribute set to another or to the contact record. One to one means at most one matching row per contact. One to many means many rows, such as orders, where segmentation has to be told how to pick a row. Many to many is not supported directly.
How do you implement Many-to-Many using a junction DE?
A contact buys many products and a product is bought by many contacts, so the two tables cannot be linked directly. Create a junction data extension holding the contact key and the product identifier, one row per combination.
Contact_DE Contact_Product_DE Product_DE
ContactKey (1)---(N) ContactKey ProductId
FirstName ProductId (N)---(1) ProductName
PurchaseDate Category
Link the contact record to the junction as one to many and the junction to the product table as many to one. The junction also carries the attributes of the relationship itself, such as purchase date.
What is the difference between Contact Builder and Data Extensions?
A data extension is a table. Contact Builder is the model that says how tables relate to a contact.
The distinction the panel is really testing is data extension relationships against Data Designer links. In Email Studio, a sendable data extension has a send relationship mapping one of its fields to the subscriber key so the table can be mailed, which is a send time setting on one table. Data Designer links are the contact model, used by Contact Builder and Journey Builder to resolve attributes and build segments.
Neither behaves like a foreign key. There is no referential integrity, nothing cascades on delete, and a SQL query activity ignores both, because your query joins on whatever you write in the ON clause, whether or not the tables are linked in Data Designer.
What is the Master Data Extension, and how is it updated?
Marketing Cloud has no object called a master data extension. It is a design pattern, and interviewers use the term to see whether you have worked on a real model, meaning the single table holding one authoritative row per contact keyed on the contact key.
It is kept current by a query activity in update mode, or by an import with a primary key, so new records insert and existing records update in place. Overwrite mode is used only when you intend to rebuild the whole table, because it clears the table first.
What is the Contact Deletion process?
Contact deletion removes a contact from the account rather than from one table. Describe it as a process, because that is what is being asked.
- Enable contact deletion in Contact Builder settings. It is off by default and configured from the top level business unit.
- Set the suppression period, so the deleted contact key is held and cannot be reinstated immediately by a routine import.
- Request the deletion, by selecting contacts in All Contacts, by supplying a data extension of contact keys, or through the API for volume.
- Let it run, since the process is asynchronous and queued.
- Verify that the contact is gone from All Contacts and from the data extensions linked into the contact model.
Two limits are worth stating. Deletion applies across the account and not only to the business unit you are working in, and it cannot be reversed. Data extensions that are not linked into the contact model are not covered, and tracking data is retained, so deletion on its own is not the full answer to a data subject request.
How do you sync opt-in status from an external system in real time?
Consent has to land in two places, the marketing attribute your segmentation reads and the subscription status Marketing Cloud enforces at send time. For batch, a file lands on SFTP and an import loads it into a consent data extension keyed on the contact key. For real time, the source system calls the API as the change happens and updates the publication list subscription too.
Say plainly that a flag in a data extension does not stop a send by itself. Unless the send respects a publication list, a suppression list or an exclusion script, the opt out you recorded is only a column.
How do you manage contact uniqueness across BUs?
In an Enterprise account the contact is held at account level, so the same contact key in two business units is the same contact and not two people. Uniqueness therefore depends on every business unit deriving the key from the same source system identifier. Where two teams use different keys for one person, suppression applied in one business unit does not apply in the other and no report ties them together.
What the interviewer is actually checking
- Whether you can match an entry source to a business requirement and say what the alternatives could not do.
- Whether you know when a rule is evaluated, not only what it means. Re-entry at injection, engagement split on arrival, contact data at activity run time.
- Whether you have handled a change to a journey that was already live, and can say what happened to the contacts inside it.
- Whether the contact model is real to you. Contact key, attribute groups, cardinality, and what deletion does across the account.
- Whether you can debug. Given a contact who did not receive the email, whether you can walk from entry to send log without guessing.
Preparing for the Marketing Cloud round
Answer these out loud against one journey you have actually built. Name the entry source, the re-entry mode, every split condition and the exit criteria, then explain how you would release a change without disturbing contacts already in flight. Specificity is what makes an answer credible, and it is the part nobody can memorise the night before.
For structured practice on Journey Builder and Contact Builder, with mock interviews in this format, see the Salesforce Marketing Cloud training programme at RizeX Labs in Pune.