The MQL That Vanished Between Two Workspaces
Northwind Robotics runs two Marketo instances: a production workspace for the Americas and a second workspace used by an acquired EMEA team. The EMEA team uploads a purchased list of 4,200 contacts into its workspace with a static list of the same size. Two weeks later, EMEA marketing reports that only 3,100 people received the intro email, and the Americas team reports that 900 of its existing engaged leads suddenly show 'Marketing Suspended = true' and stopped receiving all email. The EMEA upload used a data-management flow that set Marketing Suspended to true for anyone whose 'Region' was not EMEA. Nobody configured a channel-based communication limit. The CRM sync is bidirectional and both workspaces sync to the same CRM fields.
1. Diagnose the most likely cause of the 900 Americas leads being suspended and explain the mechanism, given the workspace setup.
Read the worked answer
The EMEA upload's data-management flow almost certainly ran in a way that touched records belonging to the Americas workspace. Key reasoning:
- Workspaces partition people (leads) in Marketo, but a person can only live in one workspace at a time. If a record already existed in the Americas workspace and the EMEA upload matched it (by email), the update behavior determines what happens - depending on the import/update settings, the record can be moved into the EMEA partition rather than duplicated.
- Once moved, the EMEA flow's choice 'Region != EMEA → Marketing Suspended = true' fires against those records, because their Region field was Americas. The suspension is a consequence of the move, not a bug in the choice logic.
- The bidirectional CRM sync compounds it: the suspended flag and any field changes write back to the CRM, so the Americas team sees the damage in both systems.
So the root cause is cross-workspace record movement driven by an import/update that matched existing people, combined with a broad destructive flow. The fix is to scope the flow to the EMEA static list (or a dedicated source field), and to control import settings so records are not reassigned across partitions.
2. Explain why 1,100 of the 4,200 purchased contacts did not receive the email, and list the checks you would run to confirm the cause.
Read the worked answer
1,100 non-recipients is consistent with several compounding filters, and you should confirm which ones apply rather than guess:
- Email invalid / hard bounce suppression. Purchased lists carry high invalid rates. Check the count of 'Email Invalid = true' among the 4,200.
- Marketing Suspended / Unsubscribed. Some purchased contacts may already exist as unsubscribed or suspended records from prior sends; the flow may have set suspension on non-EMEA records before the send.
- Duplicate/matched records moved out of the list. If some of the 4,200 matched existing people who were then reassigned to the other workspace, they may no longer be in the EMEA static list at send time.
- Communication limits. Even without an explicit channel limit, confirm no global communication limit or per-channel cap is active.
- Send eligibility / qualification. Confirm the smart campaign's smart list membership and that the send used the static list, not a smart list that excludes suspended/invalid.
Run a smart list per condition and compare counts to the 1,100 gap. The lesson: purchased-list imports must be validated against existing suppression states before any send.