A shared solution breaks other people's work first
The solutions that need a release conversation are the ones other makers build on. A Dataverse table that three canvas apps read. A custom connector to the HR system that a dozen flows call. When one of those changes, the person who feels it first is usually not the person who shipped it.
I've sat in enough of these reviews to know the failure has a shape. A maker promotes a managed solution through the pipeline on a Thursday afternoon and the pipeline reports success. On Friday morning a canvas app owned by a different team opens to an error because a column it depended on was renamed, and nobody on that second team was told a release had happened. The maker did nothing reckless. They skipped a conversation that takes about fifteen minutes.
This guide is that conversation. It is the same every time, which is the point, and it keeps makers shipping without a review board. That is the balance governance that keeps low-code work moving is meant to strike.
Say which tables the solution owns and which it only reads
The first question is about data. Which Dataverse tables does this solution create, and which does it only reference? The answer decides who else has to be in the room. A solution that owns a table can change its columns and its business rules. A solution that references a table from another publisher can only add to it, and even an added column can collide with the owner's next release.
The way I check is unglamorous. Open the solution in the maker portal, look at each table, and ask whether it carries this solution's publisher prefix. Then run the dependency check on anything the release removes or renames. If a column is going away, the dependency list tells you which forms and flows still point at it, and each of those has a maker who deserves a message before the pipeline runs.
Write the answer down in one line per table. Owns the contact extension columns. Reads account. References the shared address table from the finance solution. That line is what a reviewer reads six months from now when the finance team wants to change the address table and needs to know who sits downstream. The Dataverse hub collects more on table ownership.
Name every environment the release can reach
The second question is where the solution can land. A pipeline whose test environment lacks the downstream apps that production has is the thing that lets a broken dependency sail through. If the test environment holds this solution alone, the test proves only that the solution installs, and nothing about what it breaks.
I ask the maker to name the target environments, the connection references and environment variables the release expects to find there, and who owns the DLP policy on each one. A release that works in dev because the maker's own connection is wired in, then fails in production because the service account's connection reference was never set, was never tested where it will run. Your environment strategy should already say which environments carry other teams' solutions, and that is the invitation list for the release.
If the solution touches an environment where another team's solution also lives, that team hears about the release before it happens. A message in the maker channel with the solution name and the changed tables is enough. Silence is the failure mode.
Decide the rollback before the pipeline runs
The third question is the one people answer with a shrug. If this release breaks something at four in the afternoon, what exactly does someone do? The honest answer depends on choices made before import. A managed solution upgrade that deletes a column deletes the data in that column, and there is no button that brings it back. A staged upgrade gives you a window to check before the old version is removed.
Name the mechanism. Is the previous version of the managed solution exported and stored somewhere the on-call admin can reach? Does the pipeline stage the upgrade or apply it directly? If the release adds a column and a flow that writes to it, can the flow be turned off without removing the solution? The rollback for a shared solution is often partial, a flow disabled and an app version reverted, and it helps to have said so in advance.
I ask one more thing here. Who holds the security role to run the rollback? Too often the only person who can re-import the previous version is the maker who shipped the change, and they've gone home. If the on-call admin can't do it, the rollback plan does not exist. The first thirty minutes of a platform incident go more calmly when this question was answered a week earlier.
Keep the answers with the solution
The answers to these questions rot fastest when they live in a chat thread. Six months on, the maker has moved teams, the thread has scrolled away, and the new owner opens the solution to find a description field that says "v2". The fix is to store the answers where the solution is.
In practice that means two places. The solution description carries the one-line table ownership and the target environments. The release record, whether that is a work item in Azure DevOps or a row in a small Dataverse table the platform team keeps, carries the date, the rollback mechanism, the owner, and the teams who were told. The record exists for the next owner, who needs to know why the solution was built this way before they change it.
I've watched a platform team spend two days reconstructing a solution's history from pipeline run logs, and they still guessed wrong about why a table had been split in two. A release record takes four minutes to fill in.
Support ships with the release
The last question is who picks up the phone. A shared solution without a named owner becomes the platform team's problem by default, which is how automation owners lose the thread. Name a person and a backup, and put both in the release record. Then name the route: which support queue, which channel, which form.
Then say what a failed release looks like from the user's chair, because that is the only signal support will get. A canvas app that opens to a red banner. A flow whose run history shows a 403 on the connection reference. A model-driven form with a blank section where a column used to be. Give support those symptoms and the solution name, and the first ticket routes to the right person instead of bouncing between queues for a day.
The owner also watches the first day. Most shared-solution failures show up within hours as a spike in failed runs from one dependent flow, and an owner who checks the run history the morning after catches it before the second team's users do.
The conversation, in order
Here is the checklist I run. It fits on one page. The maker answers each question out loud, with the platform owner and anyone downstream on the call.
- Which Dataverse tables does this solution own, and which does it only reference?
- Which environments does the pipeline target, and whose solutions already live there?
- Are the connection references and environment variables set in every target environment?
- Which downstream teams were told about the release, and when?
- Is the previous version exported and stored where the on-call admin can reach it?
- Does the pipeline stage the upgrade or apply it directly?
- Who can run the rollback, and do they hold the security role to do it?
- Who owns support, what is the route, and what does a failed release look like to a user?
- Where is the release record, and has the solution description been updated to match?
Run it on the release you are least worried about
Take that list into your next shared release. If any answer comes back as something you will find out on the day, the release is not ready, and the fifteen minutes it takes to find out beforehand cost less than the Friday morning.
The release to watch is the one the platform team ships itself. The checklist has a habit of being skipped by the people who wrote it, because the change is small and everyone in the room already knows the answers. Those are the releases that rename a column in the shared table, so run the conversation on that one too, and let someone from a downstream team be the one asking the questions.
