Rescuing a Failed Frontline Rollout: Rebuilding Trust With 500 Users Across 12 Sites

If your first frontline rollout produced garbage data, regulators are asking questions and the internal IT lead who owned it has gone, do not relaunch the same app with more training. Frontline builds fail because the design never matched how the work is actually done. Recover in sequence. Quarantine the bad data and state plainly what can and cannot be trusted. Run genuine observation at two contrasting sites. Rebuild one site's workflow to standard as the reference, and only then scale, site by site, with local champions. A board demo becomes credible in 90 days when it runs on live reference-site data under visible governance, and the second attempt is measurable when the partner contract carries written acceptance criteria.

Why do frontline rollouts fail when the software works?

Most failed frontline rollouts worked in the demo. They failed on the floor, in the van or on the ward, because the design was built from a requirements document and a meeting room rather than from a shift. The capture screens asked for what the office needed to report on, at the moment the person doing the work had the least time and the least information. Offline behaviour was assumed rather than tested in the places signal drops. Shared devices meant shared logins, so nobody could tell who recorded what. The pilot ran at the best-run site, with the most engaged manager, and proved nothing about the other sites.

When that happens, people do the sensible thing: they keep the old paper sheet or the WhatsApp group as the real record and type something into the app afterwards to satisfy the report. That is where the garbage data comes from. It is a design failure, not a discipline failure, and more training on the same screens makes it worse.

This article is about relaunching after that has happened. How to design a frontline capture app properly, including staging tables and audit requirements, is covered in how Power Apps replaces paper forms on the shop floor. Office teams resisting a working CRM are a different problem, covered in our guide to Dynamics 365 adoption and user resistance. If the frontline work is Dynamics 365 Field Service, the specific stabilisation order for technicians back on paper is on our Field Service implementation partner page.

What should happen before anyone mentions a relaunch?

Stop the rollout from getting worse and take back control of the system. Pausing the next site costs less than launching it into the same design.

• Freeze further site launches and changes to the live app, and name the one person who can lift the freeze.
• Decide per site whether it keeps using the app or moves to one sanctioned fallback. Two unofficial records per site is the worst outcome, because neither can be trusted.
• Recover ownership, which matters most when the IT lead has left. Confirm who now holds administration of the environment, who owns the apps, flows and connections, which account each integration runs as, and where the source and configuration are kept. The mechanics of taking the keys back from a departed person or partner are set out in our project rescue and takeover service, and our guide to handing over a business-critical app before its maintainer leaves covers what knowledge to recover from the people who are still reachable.
• Preserve what exists before correcting anything: export the data, keep audit history and run history, and record what you switch off and when.

How do you quarantine bad data and state what can be trusted?

Treat the rollout period as a data incident. The goal is not to fix every record straight away. It is to stop anyone relying on data that has not earned it, and to be able to say precisely which data that is.

Start by setting the affected window: from the first site launch to the date the freeze took effect, per site. Then classify the records from that window into three groups rather than two:

1. Trusted: records you can confirm against an independent source, such as a signed sheet, a delivery record, a device log or a second system that the app did not feed.
2. Suspect: records that may be right but cannot be confirmed, for example entries typed in bulk at the end of a shift, entries made under a shared login, or entries whose timestamps cluster in a way the work never could.
3. Known wrong: records contradicted by an independent source, duplicates and placeholder values entered to get past a required field.

Mark every record with its classification rather than deleting or silently correcting it. Correction comes later, in one planned pass with counts before and after, once the design that produced the errors has changed. Where duplicates are part of the damage, our guide to duplicate data cleanup covers merging without breaking the records that depend on them.

Then publish a one-page data trust statement. For each data set and each site it says the period affected, the classification, and what the data may and may not be used for: operational decisions, management reporting, customer billing or anything submitted externally. Every dashboard and report that reads the quarantined data carries the same warning until the statement changes. The statement is the first thing that rebuilds trust, because it shows people that leadership knows exactly what went wrong.

What should you tell the regulator about the affected period?

The regulatory position is not a system question, and nothing here is legal advice. Take advice from your compliance lead and, where needed, your legal advisers on what to disclose, when and in what form. What the system work can do is give them facts they can stand behind rather than estimates.

• A dated timeline of the rollout, the sites involved, the affected window and the freeze.
• The classification counts from the quarantine, by site and data set, and how each classification was decided.
• For each record type that matters to the regulator, where the original evidence lives for the affected period, such as paper sheets, device logs or another system, and whether it has been secured.
• The controls that failed and the controls replacing them, such as individual sign-in, server-side timestamps and append-only records.
• What will not be claimed: no corrected figures until the correction pass is complete and reconciled, and no relaunch dates the plan below cannot support.

Two things to avoid while that conversation is open. Do not correct or delete records in the affected window before the evidence has been preserved, and do not let anyone restate numbers from the quarantined data in any external document.

Why observe two contrasting sites before redesigning anything?

Because the first design was built from what people said the work was, and one site will only show you one version of it. Choose two sites that differ in the ways most likely to break the design: large and small, good and poor connectivity, day shifts and round-the-clock shifts, and ideally one site that kept using the app and one that went back to paper.

Genuine observation means being present for real shifts, including a handover and a night or weekend shift where they exist, not running a workshop in a meeting room. Record, for each task:

• what triggers it, who does it and what they are holding at the time;
• what they actually record, where and when, including anything written on a hand, a glove or a scrap of paper;
• where the device is, whether it is shared and whether there is signal at that spot;
• what the old paper form or informal channel captured that the app did not, and the reverse;
• the workarounds, because each one is a requirement the first design missed.

Also sit with the supervisors and the people in the office who used to key paper in. They know which fields were always wrong and why.

The output is a task inventory for both sites, with each difference marked as genuine process variation the design must support or habit that can be standardised. That inventory, not the original requirements document, is the brief for the rebuild.

How do you rebuild one site as the reference?

Pick a reference site that is representative rather than easy, with a site manager who wants it to work and enough volume to prove something. Rebuild its workflow to standard from the task inventory: one capture flow per task, scanning instead of typing wherever possible, offline behaviour tested at the actual spots where signal drops, and individual sign-in for every person. The capture design detail is in the shop floor article and offline sync and duplicate prevention are in our guide to preventing field data loss in offline Power Apps, so they are not repeated here.

What makes it a reference rather than a second pilot is that the standard is written down and the old route is switched off:

• Write the exit test before go-live: all tasks captured in the app for an agreed number of consecutive weeks, data reconciling against an independent source within an agreed tolerance, no parallel paper record, and supervisors running their shift meetings from the system.
• Set a date after which the paper sheet or informal channel is withdrawn at that site, and make sure there is a sanctioned fallback for real outages.
• Keep a visible change log so the people at the site can see their feedback turn into changes.
• Freeze the design once the exit test passes. From then on, any site-specific variation goes through a single design authority rather than being built into a local copy.

How do you relaunch the remaining sites with local champions?

Site by site, in an order set by readiness rather than by seniority of the site manager, with a go or no-go decision before each one.

Each site needs a champion who is a respected member of the frontline team, not the site manager, with time given back to them for the role. Their job is to be trained first and properly on the reference design, to walk the other shifts through it on real tasks, and to report what does not fit their site before launch rather than after.

Before each launch, check the basics that sink rollouts: every person has their own account and a working device, signal has been checked where the tasks are done, the local variations agreed with the design authority are in place, and there is a named person on every shift for the first days. Launch on a normal working day, not the busiest one. Withdraw the old route on a stated date, and do not open the next site until the current one meets the same exit test the reference site met.

If you are relaunching across many sites, for example 500 users across 12 sites, resist compressing the waves to recover lost time. A site that fails a second time costs far more trust than a week of delay.

What governance makes a board demo credible in 90 days?

The board has already seen one demo that did not survive contact with the floor. A second one is believed when it shows live data from a site that is actually running, the data trust statement next to it, and a plan whose next steps have dates and exit tests rather than promises.

A realistic 90-day shape, if scope is held:

1. Weeks 1 to 3: freeze, ownership recovered, quarantine and trust statement published, compliance lead briefed, observation at the two contrasting sites complete.
2. Weeks 4 to 9: reference site rebuilt and live, with the old route withdrawn on its stated date and the exit test measured weekly.
3. Weeks 10 to 13: reference site running on real data, correction pass for the affected window underway, the second site prepared with its champion, and the board shown the reference site working from the live system.

Underneath that, the governance is plain. One sponsor who makes decisions, one channel where they are written down, and a weekly written brief that says what was found, what changed and what is next. Change control that any change to the frontline design must pass. A risk register that includes the regulator conversation. A scorecard that measures process completion and data accuracy from the records, not logins or training attendance.

What acceptance criteria belong in the partner contract for the second attempt?

The first attempt was probably accepted on delivered features. The second should be accepted on measured outcomes at the reference site and each subsequent site, with payment milestones tied to them. Useful criteria include:

• Capture: the share of observed tasks recorded in the app at the reference site over the agreed consecutive weeks, measured from system records against the task inventory, with no parallel paper record.
• Accuracy: reconciliation of a defined sample against an independent source, within a tolerance agreed before build.
• Task time: capture time per task at or below the baseline measured during observation.
• Offline: submissions made without signal at named locations arrive once, with no duplicates and no silent loss, demonstrated on real devices.
• Audit: individual sign-in, server-side timestamps, append-only submissions and auditing enabled on the tables that matter.
• Ownership: source and configuration in a repository you control, administration held by your staff, documentation and a handover session, so the system does not depend on one person again.
• Support: defect severity definitions, response and fix commitments for each, and a hypercare period per site.
• Site rollout: a written go or no-go test for each site, which the partner cannot waive on its own.

The same contract should be clear about platform. Most failed frontline rollouts do not need a different platform, and a second attempt that also switches technology carries two risks at once. Where licensing for a large frontline workforce or hosting requirements genuinely do not fit, a custom-built application you own outright is a legitimate option to evaluate on evidence, and our Power Platform consulting covers the case where the platform stays and the design changes. Solzet takes over and rebuilds frontline apps on Power Apps, Dynamics 365 and custom stacks, delivered remotely from Yerevan, Armenia, directly or white-label for Microsoft partners.

What should you do this week?

1. Freeze further site launches and changes to the live app, and name who can lift the freeze.
2. Confirm who now holds administration, app and flow ownership, and every integration account.
3. Preserve the data, audit history and run history before anyone corrects a record.
4. Set the affected window per site and start classifying records as trusted, suspect or known wrong.
5. Brief your compliance lead with the timeline and ask what they need from the system.
6. Choose the two contrasting sites and book real shifts for observation, including a handover.
7. Draft the acceptance criteria you want in the next contract before you speak to any partner.