Fix Contacts Stuck in Dynamics 365 Customer Insights Journeys

A troubleshooting guide for Dynamics 365 Marketing (Customer Insights Journeys) email journeys where contacts are not progressing and no error is shown, from audience membership and consent to wait tiles, publishing, and sending limits.

If contacts in your Dynamics 365 Marketing (Customer Insights Journeys) email journeys are stuck without errors, or a journey stopped halfway for thousands of contacts, this guide helps you diagnose and recover. Pause new entries, export the stuck audience and find the step they halted on from journey analytics. Then check the common causes: segment criteria and refresh, consent and contact point state, exit conditions, wait or branch conditions that never become true, and sending limits. Recover the affected people with an emergency re-send journey that suppresses anyone already reached, and escalate to Microsoft support when the evidence points to the platform. Solzet diagnoses and fixes stalled journeys as part of our Dynamics 365 delivery.

What commonly causes contacts to stall with no error?

The contact never entered the audience in the first place

A journey only moves contacts that are actually in its entry audience. Segment based and audience based journeys are populated on a refresh cycle rather than instantly, so a contact you added a moment ago may not have been picked up yet, and a segment that failed to run or has stale membership will simply not hand anyone to the journey. Confirm the contact is a live member of the exact segment or audience the journey uses, and that the segment has run recently, before assuming the journey itself is broken.

Consent and contact eligibility are quietly blocking the send

A contact with no valid email address, with a bounced or blocked address, with the do not email or do not bulk email option set, or without the consent required for the purpose the journey sends under, is filtered out at send time rather than raised as an error. The contact appears to stall because the platform is deliberately not emailing it. Check the email field, the contact point consent records, and the compliance or purpose settings the journey is configured to respect.

A wait tile or a trigger the journey is waiting for never resolves

Journeys pause contacts at wait tiles and at tiles that wait for a trigger or a specific action such as an email being opened or a form being submitted. If that trigger never fires, or the wait condition can never become true, the contact sits at that step indefinitely with nothing wrong reported. Open the journey, find which tile the contact is parked on, and confirm the event it is waiting for is one that can realistically happen and is flowing into the environment.

The journey is in draft, stopped, or was edited without republishing

Changes to a live journey do not take effect until the journey is stopped and published again, and a journey left in draft or stopped will hold or never advance its contacts. It is common to edit a tile, assume the change is live, and watch contacts appear stuck against the old version. Verify the journey status is live and published, and that the version the contact is on is the one you expect.

Quiet hours, send scheduling, and sending limits are throttling delivery

Quiet hours, send time settings, and the environment sending quota can all hold or pace emails so contacts look stalled when they are really queued. A large batch entering at once, or an environment that is hitting its sending or service protection limits, will drain slowly rather than fail loudly. Check whether the send is scheduled or held by quiet hours and whether the environment is being throttled before treating a delay as a defect.

Data, ownership, or security scoping is hiding or excluding the contact

A contact that has been deactivated, merged into another record, reassigned across business units, or placed outside the security scope the marketing app can see will not progress the way you expect, and the record you are looking at may not be the one the journey holds. Confirm the contact is active, is the surviving record after any merge, and sits within the business unit and security context the journey and its users actually operate in.

How do you diagnose and unblock the journey, step by step?

Work through these in order. The early steps find where the contact is really parked and whether it ever qualified; the later steps rule out publishing, throttling, and record issues, then confirm the fix with a controlled test.

  1. Confirm the contact is really in the journey and note where it is parked

    Open the journey analytics or the contact record and confirm the contact actually entered the journey, then identify the exact tile it is currently sitting on. A contact that never entered and a contact stopped at a specific step are two different problems, and knowing which one you have decides everything that follows. Note the tile name and step so every later check is targeted rather than a guess.

  2. Verify segment or audience membership and that it has refreshed

    Check that the contact is a current member of the precise segment or audience the journey runs on, and that the segment has recalculated recently rather than showing stale or failed membership. Segment based and audience based entry is populated on a cycle, so a recently added contact may simply be waiting for the next refresh. If membership is missing or the segment did not run, the fix is in the segment, not the journey.

  3. Check email address, consent, and compliance eligibility

    Confirm the contact has a valid, non blocked email address and is not set to do not email or do not bulk email. Then check the consent and contact point consent records and the purpose or compliance profile the journey sends under, because a contact without the required consent for that purpose is silently filtered out at send time rather than errored. If eligibility is the issue, the contact will never advance past the email step until consent or the address is corrected.

  4. Inspect the tile the contact is stuck on and what it is waiting for

    If the contact is parked on a wait tile or a tile that waits for a trigger or an interaction, confirm that the event it is waiting for can actually occur and is flowing into the environment. A wait until condition that can never be true, or a trigger that no longer fires, will hold the contact forever with no error. Trace the awaited event end to end so you know it is reaching Dataverse, not just expected to.

  5. Confirm the journey is live, published, and on the version you expect

    Check that the journey status is live and published rather than draft or stopped, and that any recent edits were republished, since changes do not apply until the journey is stopped and published again. Confirm the contact is on the version of the journey you think it is on. A journey that looks correct in the designer but was never republished is a frequent reason contacts appear frozen.

  6. Rule out quiet hours, scheduling, and sending or service limits

    Check whether the send is being held by quiet hours or a send schedule, and whether the environment is hitting sending quotas or service protection limits that pace delivery. A large batch or a throttled environment drains slowly and can read as stuck. If the contact is simply queued behind limits, the resolution is capacity and scheduling, not a change to the journey logic.

  7. Validate the contact record itself for state, merges, and security scope

    Confirm the contact is active, is the surviving record after any merge, and sits inside the business unit and security scope the marketing app and its users can see. A deactivated, merged, or out of scope record will not behave as expected, and you may be inspecting a record that is not the one the journey is actually holding. Correct the record state or scope so the journey has a valid, visible contact to move.

  8. Reproduce with a controlled test contact and monitor it through the journey

    Create a clean test contact that clearly meets the segment, consent, and eligibility criteria, add it to the entry audience, and watch it move through each tile. A controlled run confirms whether the journey itself works and isolates the blocking condition to configuration, data, or eligibility. Once a known good contact flows end to end, apply the same fix to the stuck population and confirm they progress.

What do you do when a journey stopped halfway for thousands of contacts with no error?

A stall at scale is a different problem from one contact sitting still. Many people are affected at once, customers are missing messages while you investigate, and a hasty change can destroy the evidence or send everyone the same email twice. Work in this order: contain, locate, diagnose, fix, recover and, only if the evidence says so, escalate.

  1. Pause new entries before you change anything

    Stop more people flowing into a journey that is already failing, without destroying the state of those inside it. If your version offers a pause or a way to close entry, use it; if the only option is to stop the journey, check current Microsoft documentation first, because stopping a live journey generally ends it for everyone in it and cannot simply be undone. Also freeze edits to the segments, emails and data the journey depends on, so the evidence does not change under you.

  2. Find the step they halted on from journey analytics

    Open the journey analytics and read the counts tile by tile. The halted step is the first tile where the number of contacts that reached it stops matching the number that moved on, after allowing for any deliberate wait. Note the tile name, the time progression stopped, and whether everyone stopped there or only part of the audience, because a partial stall usually points to data or consent rather than the journey design.

  3. Export or rebuild the stuck audience

    Get a list of the affected people with their record IDs, the tile they are on and when they entered. Where the analytics or insights view lets you list or export contacts at a tile, use that; otherwise rebuild the list from interaction data, for example contacts who received the message before the halted tile but not the one after it, using a segment on journey interactions. Keep this export: it is the input for the fix, the re-send and any Microsoft ticket.

  4. Check the usual causes against a sample of the stuck contacts

    Take ten to twenty stuck records and compare them with a few that progressed. Work through the causes listed below in order: a wait or branch condition that can never be true, an empty attribute the step depends on, consent or contact point state, exit conditions, a segment refresh that changed membership, and a delivery block. The difference between the stuck sample and the progressed sample is almost always the answer.

  5. Fix the cause and prove it with a controlled test contact

    Correct the condition, the data, the consent records or the delivery setting, in a test environment first where you can. Then run a clean test contact through the corrected path end to end. Remember that edits to a live journey do not apply until it is republished, and that contacts already in the journey may stay on the version they entered.

  6. Recover the affected people with an emergency re-send journey

    Rather than hoping the stuck contacts move once the cause is fixed, build a separate recovery journey for exactly the exported audience, starting from the step they missed, with suppression so nobody receives a message twice. The design is set out in the next section.

  7. Escalate to Microsoft when the evidence points to the platform

    If the stuck and progressed samples look identical, several journeys stalled at the same time, or a minimal test journey reproduces the stall, open a Microsoft support ticket with the evidence listed further down this page, while the recovery journey looks after your customers.

The usual causes of a stall at scale, in the order to check them

A wait or branch condition that is never true

A wait until condition or an if/then branch built on an event that does not happen, a value that is never set, or a date in the wrong format or time zone will hold everyone at that tile. Check the condition against the actual values on the stuck sample, not against what the field is supposed to contain.

An empty attribute the step depends on

A branch or a personalised message that reads a field which is blank for part of the audience can hold or skip those contacts, depending on how the tile handles empty values and whether a default is set. A recent import or integration that left a column empty often explains why one group stopped and another did not.

Consent or contact point state

If the step sends a message, contacts without the consent the journey purpose requires, or whose email address or phone number is blocked, bounced or missing, are filtered out at that step rather than errored. A bulk consent change, a new compliance profile or a data load that reset contact point consent can affect thousands of records at once.

Exit conditions

Journeys can remove contacts when they meet an exit condition or join an exclusion segment. A condition written too broadly, or a segment that unexpectedly grew, can look like a stall when contacts have actually left. Compare the exit and exclusion settings with the stuck sample before assuming anyone is still inside.

A segment refresh that changed membership

If the journey or one of its conditions depends on segment membership, a refresh that failed, ran late or recalculated on changed data can drop contacts from the population the journey expects. Check when the segment last refreshed successfully and whether its count changed around the time progression stopped.

A delivery block

Contacts can wait at a send step when delivery is held: quiet hours or a send schedule, the environment sending quota or service protection limits, a sending domain that lost its authentication, or a message that is no longer published. These pace or hold delivery silently. Check current Microsoft documentation for where delivery status and limits are shown in your version.

How do you re-send to the affected contacts without anyone getting a duplicate?

Build an emergency recovery journey rather than waiting for the stuck contacts to move once the cause is fixed. Contacts already inside the original journey may stay on the version they entered, may resume unpredictably, or may never resume at all, and you cannot leave customers without a renewal notice, an event joining link or an onboarding step while that plays out. The recovery journey reaches exactly the people who missed out, and suppression keeps it away from everyone else.

  • Target only the exported affected audience, through a static list or a segment built from it, never the original segment, which may have changed since.
  • Start from the step they missed, not from the beginning of the original journey, and rewrite any copy that no longer makes sense after the delay.
  • Suppress anyone who already received the message, for example with an exclusion segment or an exit condition on the delivered or sent interaction for that email, depending on what your version offers.
  • Suppress anyone who has since converted, opted out, been deactivated or merged, or entered another journey that covers the same purpose.
  • Check consent again at send time, because the recovery journey must respect the same purpose and compliance profile as the original.
  • Disable re-entry so a contact cannot pass through the recovery journey twice, and keep the original journey from resuming for the same people.
  • Send to a small batch first, check the delivered numbers and a few inboxes, then release the rest.

Exclusion segments, exit conditions and re-entry settings are named and placed differently between releases, so check current Microsoft documentation for the options in your version before you build the recovery journey.

When should you open a Microsoft support ticket, and what evidence should you attach?

Open a ticket when the evidence points to the platform rather than to your configuration or data, and open it in parallel with the recovery journey rather than instead of it. Tickets are raised from the Power Platform admin center for the affected environment; check current Microsoft documentation for the exact route and the support plan it requires.

Open a ticket when

  • The stuck and progressed samples are identical in data, consent and segment membership, and the condition evaluates true for the stuck contacts.
  • Several journeys in the same environment stopped progressing at about the same time.
  • A minimal test journey with a clean test contact reproduces the stall.
  • The Microsoft 365 or Power Platform service health pages show an incident or advisory for your region that matches the timing.
  • The stall started straight after a platform update with no change on your side.

Attach this evidence

  • The environment name, environment ID and region, and the app version if you can see it.
  • The journey name and ID, the tile it halted on, and the time progression stopped, in UTC.
  • Counts from journey analytics at each tile, with screenshots.
  • A handful of record IDs for stuck contacts and for contacts that progressed through the same tile.
  • What you have already ruled out, from the causes above, and how you checked each one.
  • Any changes made in the days before: imports, consent updates, segment edits, republishing, domain or DNS changes.
  • The result of the minimal test journey, if you ran one.

Can Solzet take on a journey that stalled for thousands of contacts?

Yes. We fix this as part of our Customer Insights and project rescue work, directly for your team or white-label for Microsoft partners. Senior consultants with 8+ years of Dynamics 365 Customer Engagement and Power Platform delivery work through it in the order above:

  • Contain the journey without losing state, and preserve the analytics and the stuck audience as evidence.
  • Find the halted step and the cause by comparing stuck and progressed contacts, then correct the journey, the data or the consent records, tested before it goes live.
  • Build and run the recovery journey with suppression, so the affected people are reached once and nobody else is.
  • Prepare and follow up the Microsoft support ticket when the evidence points to the platform.
  • Put monitoring in place so the next stall is noticed from the journey analytics, not from customer complaints.

What a wider engagement covers, from journey design to consent and segments, is on our Dynamics 365 Customer Insights implementation page.

Why do website and form triggers never fire in Customer Insights Journeys?

Sometimes contacts are not stuck inside the journey at all: they never reach it, because a behaviour based trigger upstream silently does nothing. For a website visit or a form submission to start or move a journey, every link in the chain below has to hold. None of them raises an error when it breaks, which is why these problems survive for weeks.

The tracking script or form embed is on the live page and actually runs

The code the app generates for a form or for website tracking has to be on the page visitors really use, in its current version, and it has to be allowed to run. A page rebuilt by a web agency, a tag manager change that was never published, a cookie consent banner that blocks marketing scripts until the visitor accepts, or a domain that is not enabled for hosting forms can each stop the interaction ever leaving the browser, with nothing reported in Dynamics 365.

The visitor is identified as a real contact or lead record

A journey acts on records, not on anonymous browsers. A form submission is matched to an existing contact or lead, or creates one, according to the form settings; a website interaction can only be tied to a person once they have been identified, for example by submitting a form or clicking a tracked link in an email. If the submission creates a lead while the journey targets contacts, or matches a duplicate record rather than the one you are watching, the interaction happens but not to the record you expect.

The interaction is recorded and mapped to the event the trigger uses

The submission or visit has to arrive as an interaction the app records, from the specific form or page the trigger refers to. Copies of a form with the same name, a form republished as a new version, or an old outbound marketing form still embedded after a migration all produce interactions, or submissions, that the real-time trigger is not listening for.

The journey is live and listening to that exact trigger for that record type

The journey start or the branch has to use the same trigger, for the same form or event, for the record type the interaction belongs to, and the journey must be live. Journeys also have entry and re-entry settings, so a contact who has already been through the journey may not start again. A trigger that looks right by name but points at a different form, or a journey still in draft, will never enrol anyone.

Which trigger checks can a non-developer run, in order?

None of these needs code. Run them in order and stop at the first one that fails, because that is where the chain is broken. Trigger names and settings change between releases, so check current Microsoft documentation for where each option sits in your version.

  1. Write down exactly what the journey is listening to

    Open the journey and note the trigger at the start or on the branch: its name, the form or event it refers to, and whether the journey targets contacts or leads. Confirm the journey is live and check its entry and re-entry settings, because a contact who has already completed the journey may not be allowed back in. Every later check compares against this note.

  2. Confirm the form or tracking code is on the live page

    Open the real public page in a browser, not a preview, and use View page source to search for the form or tracking identifier shown in the app. If the site uses a tag manager, ask whoever owns it to confirm the latest version is published. If the form in the app is not the form on the page, or an old outbound marketing form is still embedded, stop here: that is the fault.

  3. Rule out cookie banners, blockers and form hosting settings

    Repeat the visit in a private window with browser extensions off, and accept all cookies on the consent banner before interacting. If the trigger only works after accepting cookies, the consent banner is holding the script back, which may be correct for your consent policy. Also confirm in the app settings that the website domain is enabled for hosting forms, since forms can fail to load or submit on domains that are not. Check current Microsoft documentation for where those settings sit in your version.

  4. Submit a test entry with an address you control

    Use a test email address that you control and that is not already on a duplicate record, fill in the form exactly as a visitor would, and note the time. Then check the submissions for that form in the app. No submission means the problem is still on the website side. A submission that arrived means the website side works and the fault is further down the chain.

  5. Find the record the submission matched or created

    Look up the test email address and see whether the submission updated an existing contact, created a new contact or created a lead. Compare that with your note from the first check. A lead created for a journey that targets contacts, or an update to an older duplicate contact, explains a trigger that fired but enrolled nobody you can see.

  6. Check the journey for the test record

    Open the journey analytics and look for the test record as an entrant, allowing a little time for processing. If it entered, the trigger works and any stall afterwards is covered by the troubleshooting steps above. If it did not, compare the trigger with the form the submission came from once more, including copies with the same name and newer published versions.

  7. Retest after every website release and form change

    Keep the test entry as a routine: submit it after each website release, tag manager change, consent banner change or form edit, and confirm a new entrant appears. Most triggers that stop firing were broken by a change made somewhere other than the journey, and this is the cheapest way to catch it on the day it happens.

A developer is genuinely needed when the trigger is a custom event raised from website or application code, or when the form sits on a site you cannot change without a code release. If the triggers stopped working right after moving from outbound marketing to real-time journeys, the migration causes and fixes are set out on our Dynamics 365 Customer Insights implementation page.

What no-code fallbacks restore conversions while a trigger is fixed?

Do not leave new sign-ups without follow-up while the root cause is traced. These fallbacks avoid website tracking altogether, so they work today and can stay in place as a safety net afterwards.

Link to a hosted marketing form instead of an embedded one

Where the embed is the problem, publish the form as a standalone page hosted by the app, if your version offers it, and point the website button or link at that page. The submission no longer depends on your site code, tag manager or scripts, and the form submitted trigger keeps working.

Start the journey from an email click instead of a website visit

If the journey depends on someone visiting a page, send an email with a clear link to that page and use the click on that tracked link as the trigger or branch condition. Clicks in emails sent from the app are recorded against a known contact, so they do not rely on website tracking or visitor identification.

Enrol from a segment or a list rather than a real-time trigger

Build a segment on data you can already trust, such as contacts who submitted the form, registered for the event or were added to a marketing list by the team, and start the journey from that segment. Entry is less immediate than a trigger, because segment membership refreshes on a cycle, but people who converted today will still receive their follow-up.

What do teams ask about stuck journey contacts?

Why are contacts stuck in a Dynamics 365 Customer Insights Journeys journey with no error?

Most silent stalls come down to a small set of causes: the contact is not actually a current member of the segment or audience the journey uses, or that audience has not refreshed yet; the contact is ineligible because of a missing or blocked email, a do not email setting, or missing consent for the journey purpose, so it is filtered out at send time rather than errored; the contact is parked on a wait tile or a trigger that never resolves; the journey is in draft or stopped, or was edited without republishing; or quiet hours and sending limits are pacing delivery. Because these are eligibility and configuration conditions rather than failures, the platform shows no error, so you diagnose by finding which one applies.

How do I tell whether a contact never entered the journey or entered and then stopped?

Open the journey analytics or the contact timeline and confirm whether the contact actually entered the journey, then look for the specific tile it is sitting on. If it never entered, the problem is upstream in segment or audience membership and its refresh cycle. If it entered and stopped at a tile, the problem is at that step, usually a wait or trigger condition, an eligibility filter at the email send, or the journey not being live. Separating these two cases first stops you from changing journey logic when the real issue is that the contact was never handed to the journey.

Can consent or email settings silently block a contact from progressing?

Yes. A contact with no valid email address, with a blocked or bounced address, with do not email or do not bulk email set, or without the consent required for the purpose the journey sends under is filtered out at the send step. The platform treats this as the contact being ineligible rather than as an error, so the contact appears to stall at the email tile. Checking the email field, the contact point consent records, and the compliance or purpose configuration usually explains a contact that will not advance past a send.

Why do edits to a live journey not seem to take effect?

Changes to a journey do not apply until the journey is stopped and published again. If you edit a tile on a live journey and do not republish, contacts keep running against the previous version and can look frozen against the change you just made. Confirm the journey status is live and published after any edit, and check which version the stuck contact is actually on. Republishing so the intended version is live is often all that is needed for contacts to start moving again.

Can Solzet help fix marketing journeys that stall in Dynamics 365?

Yes. Solzet is a Dynamics 365 Customer Engagement and Power Platform consultancy based in Yerevan, Armenia, and diagnosing and fixing marketing automation is part of our implementation and project rescue work. We trace where contacts are parked, check segment and audience membership and refresh, verify consent and eligibility, inspect wait and trigger tiles, confirm the journey is live and correctly published, and rule out quiet hours and sending limits, then validate the fix with a controlled test contact. We work directly with in house teams or on a B2B and white-label basis for other Microsoft partners.

Why are website and form triggers not working in Customer Insights Journeys?

For a web interaction to reach a journey, four things must all be true: the form embed or tracking script is on the live page and allowed to run, the visitor is identified as a real contact or lead, the interaction is recorded from the exact form or page the trigger uses, and the live journey listens to that trigger for that record type. Cookie banners blocking scripts, old form embeds after a migration, leads created for a contact journey, duplicate forms with the same name and re-entry settings are the usual breaks.

Can a marketer fix Customer Insights Journeys triggers without a developer?

Usually the diagnosis, and often the fix. A marketer can note what the journey listens to, confirm the form on the live page is the one in the app, retest with cookies accepted and extensions off, check the domain is enabled for form hosting, submit a test entry and find the record it created, then look for that record in the journey analytics. A developer is genuinely needed for custom triggers raised from website or application code, or for a site you cannot change without a code release.

What can we use while a broken website trigger is being fixed?

Use no-code fallbacks that do not depend on website tracking: link to a hosted marketing form page instead of an embedded form, start or branch the journey on a click in a tracked email, or enrol people from a segment or marketing list built on data you trust. Segment entry is less immediate than a trigger but ensures people who converted still receive follow-up. Check current Microsoft documentation for the options in your version.

What should I do when a Customer Insights journey stopped halfway for thousands of contacts with no error?

Work in order. Pause new entries without stopping the journey if your version allows it, because stopping generally ends it for everyone inside. Read journey analytics tile by tile to find the step where counts stop moving, export or rebuild the stuck audience, then compare a sample of stuck contacts with ones that progressed against the usual causes: a wait or branch condition that is never true, an empty attribute, consent or contact point state, exit conditions, a segment refresh and a delivery block. Fix the cause, test it, then recover the affected people with a separate re-send journey.

How do I re-send to contacts stuck in a journey without sending anyone a duplicate?

Build a separate recovery journey that targets only the exported affected audience, starts from the step they missed, and suppresses anyone who already received that message, has since converted or opted out, or is no longer active, using an exclusion segment or an exit condition depending on what your version offers. Recheck consent at send time, disable re-entry, keep the original journey from resuming for the same people, and send to a small batch before releasing the rest.

When should I open a Microsoft support ticket for a stalled Customer Insights journey?

When the evidence points to the platform rather than your configuration: stuck and progressed contacts look identical, several journeys stalled at once, a minimal test journey reproduces it, or service health shows a matching incident. Attach the environment ID and region, the journey ID, the halted tile and the time it stopped in UTC, analytics counts with screenshots, sample record IDs for stuck and progressed contacts, what you have ruled out and any recent changes.

Journey and trigger fixes are part of our wider Dynamics 365 consulting work, and of the Customer Insights implementation projects we deliver for marketing teams.

We recommend the right solution: Dynamics 365 (Customer Engagement, Business Central or Finance and Operations), Power Platform, or a custom-built CRM. One team for CRM, ERP and the integration between them.

Journey stalled and no one can say why?

Solzet diagnoses and fixes Dynamics 365 marketing automation as part of our Customer Engagement and Power Platform delivery. Tell us where your contacts are stuck and we will trace the real cause and get the journey moving, directly or on a white-label basis for your team.