A Dynamics 365 release that passed SIT and broke on the way to production

Tracked down why flows imported fine and then didn't run, fixed it at the source, and wrote down what each new environment needs.

The problem

The organisation runs member events and its sales side in Dynamics 365 CE. The build is spread across several solutions, with Power Automate flows, plugins and an outbound contact integration. Changes go through SIT and pre-prod pipelines.

A release that passed SIT fell over on the way to production. Two causes.

First, connection references. A large batch of flows came across pointing at the wrong connections, or none. They imported fine, then didn't run, and nobody knew until a record that should have been there wasn't.

Second, an environment variable holding an app ID had no value in the new environment. Nothing in the pipeline set it, so whatever depended on it broke quietly.

What was done

  • Traced the flow failures to the connection references and fixed them at the source, not flow by flow, so the next deploy doesn't bring it back.
  • Worked out which environment variables need a value per environment and can't ship with the solution.
  • Wrote down the one-time setup each new environment needs before a deploy, so it isn't something one person remembers.
  • Kept normal work moving alongside: event registration plugin fixes, clearer fulfilment messages, fields for the outbound integration.

The result

The cause was found and fixed once, not patched environment by environment. The next person deploying has a written list instead of guessing. Most inherited Dynamics builds have a version of this.

Release problems like this are part of every Dynamics 365 health check I do.

Tech used

Dynamics 365 CE, Dataverse, Power Automate, C# plugins, Azure DevOps pipelines, managed solutions.

Releases that work in test and break in production?

If this sounds like your project, book 20 minutes.

Book a 20-min call