DIALOGE — G: Go-Live¶

Go-Live is not an event. It is a discipline. The difference between a solution that can be trusted in production and one that cannot is almost entirely determined by how it was deployed — and how every subsequent change was deployed after that.

TL;DR

Solutions are the non-negotiable packaging unit. Never build directly in production. Use environment variables and connection references for environment promotion. Run Solution Checker before every deployment. Deploy as managed solutions to production. Use Git integration for source control. The tenth deployment should be as controlled as the first.

Applies To

Audience: Solution Engineer · Platform Lead BOLT Tiers: Tier 2–4 (Tier 3–4 require full ALM) Maturity: Intermediate → Advanced Frameworks: DIALOGE · SCALE-OPS (Automation) · SHIELD (Inspect gate)

Go-Live and SCALE-OPS Automation

SCALE-OPS Automation covers platform-level ALM infrastructure — pipeline setup, Azure DevOps Build Tools, environment strategy. This page covers solution-level deployment practices — how a specific solution is packaged, versioned, tested, and deployed through that infrastructure.

What Go-Live Means in DIALOGE¶

Go-Live is the bridge between building and operating. It is the discipline of moving a solution safely, repeatably, and auditably from development through testing into production — and of keeping it there in a controlled state as it evolves.

Most solutions are built with care. Many are deployed carelessly. A solution built with a well-designed data model, robust logic, and thoughtful AI integration can be undone entirely by a deployment practice that bypasses version control, skips testing, and makes production changes directly in the browser.

Enterprise solutions need repeatable, governed deployment — not just for the initial release, but for every subsequent change. The tenth deployment to production should be as controlled as the first.

The connection to SCALE-OPS: SCALE-OPS Automation covers the platform-level ALM infrastructure — Power Platform Pipelines setup, Azure DevOps Build Tools configuration, environment strategy, and tenant-level governance of the deployment pipeline. DIALOGE Go-Live covers the solution-level practices — how a specific solution is packaged, versioned, tested, and deployed through that infrastructure. The platform team sets up the pipeline; the solution team uses it correctly.

Why Go-Live Discipline Matters¶

The most common source of production instability in Power Platform solutions is not bad code or poor data design. It is undisciplined deployment:

Changes made directly in the production environment — no version history, no review, no rollback
Solutions deployed as unmanaged — every maker can see and edit the components in production
Environment variables not configured — the solution connects to development data sources in production
No testing gate — a change that worked in development breaks an integration in production that nobody tested
No rollback plan — when a deployment causes an issue, the only option is to fix forward under pressure

Every one of these failure modes is preventable with deployment discipline.

Solutions — The Non-Negotiable Packaging Unit¶

Solutions are the fundamental unit of deployment in Power Platform. A solution is a container that packages all the components of a solution — tables, columns, apps, flows, plugins, web resources, environment variables, connection references, and more — into a single deployable artefact.

Why solutions are non-negotiable for enterprise: Without solutions, components exist in an environment with no defined ownership, no version history, no deployment mechanism, and no rollback capability. You cannot promote a canvas app to production reliably without a solution. You cannot track what changed between versions. You cannot roll back to a previous state.

Solution design principles:

One solution per bounded context: A solution should contain the components that belong together — the components that are always deployed together, that have the same ownership, and that share the same release cadence. A solution that contains everything is as problematic as a solution that contains nothing — changes to unrelated components are bundled together, increasing deployment risk and complicating version tracking.

Publisher prefix: Every solution must have a defined publisher with a consistent prefix applied to all custom components. The publisher prefix is permanent — components cannot be renamed after creation. Establish the publisher prefix before the first component is created, not after discovering that all components have the default prefix.

Managed properties: Use managed properties to protect solution components from unintended modification in downstream environments. Lock components that should not be customised in production — preventing well-intentioned but ungoverned changes that bypass the deployment pipeline.

Dependency management: Solutions can depend on other solutions — a core data model solution depended upon by an application solution. Document and manage these dependencies explicitly. A deployment that installs an application solution without its dependent data model solution will fail in an environment where the dependency is not present.

Environment Strategy for Solutions¶

Every enterprise solution should flow through a defined environment progression before reaching production. The specific stages depend on solution complexity and organisational risk tolerance — but the principle is universal: production is never the first place a change is tested.

Standard enterprise environment progression:

Environment	Purpose	Access
Developer (personal)	Individual development and experimentation	Solution Engineer only
Shared Development	Team integration — combining components from multiple developers	Development team
Test / UAT	Pre-production validation — mirrors production configuration	QA team and business stakeholders
Production	Live workload — restricted maker access, Managed Environments	End users

The configuration principle: Each environment should mirror the previous one as closely as possible — same DLP policies, same security roles, same data model — differing only in the data it contains and the external systems it connects to. A test environment that does not mirror production configuration will not surface production issues during testing.

Managed Environments in production: Production environments should always be Managed Environments — enabling solution checker enforcement, sharing limits, IP firewall, and usage insights. Solutions that pass all gates in a non-managed test environment and then encounter policy enforcement for the first time in managed production have been tested against the wrong configuration.

Environment Variables and Connection References¶

Environment variables and connection references are the configuration layer that makes solutions deployable across environments without modification.

Environment Variables¶

Environment variables store configuration values that differ between environments — API endpoints, SharePoint site URLs, email addresses, feature flags, processing thresholds. They are defined within the solution and their values are set per environment — separate from the solution package itself.

Why environment variables are critical for enterprise ALM: A solution that contains hardcoded URLs, email addresses, or environment-specific identifiers cannot be cleanly promoted across environments without modifying the solution content. Modification of solution content outside the development environment breaks the deployment audit trail and introduces the risk of environment-specific changes contaminating the solution package.

The rule: Every value that differs between Dev, Test, and Production belongs in an environment variable. No hardcoded environment-specific values in solution components.

Environment variable types: - Text — strings, URLs, identifiers - Number — thresholds, limits, counts - Boolean — feature flags, on/off switches - Data source — SharePoint site references - Secret — sensitive values stored in Azure Key Vault, not in the solution package

Azure Key Vault integration for secrets: Environment variables of type Secret reference Azure Key Vault secrets rather than storing sensitive values in Dataverse. API keys, connection strings, and credentials that must be environment-specific and must not be visible in the solution export belong in Key Vault, not in environment variable values.

Connection References¶

Connection references decouple connector credentials from solution logic — allowing connections to be updated per environment without reimporting the solution. Every connector used within a solution should be referenced through a connection reference, not connected directly.

The deployment implication: When a solution is deployed to a new environment, connection references must be configured with environment-appropriate connections before the solution's flows will run. This is expected and correct — it is the mechanism by which production flows connect to production systems rather than development systems. A deployment process that does not include connection reference configuration as an explicit step will result in flows that do not run or run against the wrong systems.

Power Platform Pipelines vs Azure DevOps — The Solution Builder's Decision¶

The platform team is responsible for setting up the deployment infrastructure. The solution builder's decision is which infrastructure to use for their solution — and how to use it correctly.

Power Platform Pipelines — the right choice for most solutions: Power Platform Pipelines is the native, in-product ALM capability. It is configured in the Power Platform Admin Center, visible within the maker experience, and requires no external tooling. For the majority of enterprise solutions — including complex ones — Pipelines provides all required capability: - Defined deployment stages (Dev → Test → Production) - Pre- and post-deployment approvals - Solution Checker enforcement as a deployment gate - Deployment history and audit trail - Maker-initiated deployments with approval workflows - Automated deployments triggered from external CI/CD

Azure DevOps with Power Platform Build Tools — when Pipelines is not enough: Azure DevOps provides full pipeline control for scenarios that exceed what Power Platform Pipelines handles natively: - Solutions with complex multi-repository source control requirements - Organisations with existing DevOps maturity and established pipeline patterns - Solutions requiring integration with non-Power Platform components (Azure Functions, APIs) in the same deployment pipeline - Regulated environments requiring deployment pipeline configuration that cannot be met within Pipelines

The decision principle: Start with Power Platform Pipelines. Move to Azure DevOps when Pipelines genuinely cannot meet a specific requirement — not because DevOps feels more mature or more familiar. The overhead of maintaining Azure DevOps pipelines is non-trivial, and Pipelines handles the majority of enterprise scenarios well.

For the full platform-level setup of both options — pipeline configuration, environment registration, service principal setup — see SCALE-OPS — Automation.

Release Gates and Quality Checks¶

A release gate is a defined checkpoint that a solution must pass before it can be promoted to the next environment. Gates are the mechanism that prevents untested, low-quality, or non-compliant changes from reaching production.

Solution Checker¶

Solution Checker is an automated static analysis tool that evaluates solution components against a set of quality and security rules — identifying deprecated API usage, performance anti-patterns, accessibility issues, and security vulnerabilities.

Enterprise requirement: Solution Checker must be configured as a mandatory gate in the deployment pipeline. Solutions that fail Solution Checker above a defined severity threshold (Critical or High) must not be promoted to Test or Production until the issues are resolved.

Running Solution Checker manually before deployment is insufficient for enterprise governance — it is bypassable. Configure it as an automated pipeline gate that blocks promotion on failure.

Interpreting Solution Checker results: Not every Solution Checker warning requires remediation before deployment — Medium and Informational findings represent opportunities for improvement, not blockers. Establish a clear organisational standard: which severity levels block promotion and which are tracked as technical debt backlog items.

Security Review — SHIELD Inspect¶

Before a solution reaches production, it must pass the SHIELD Inspect gate — the risk-based security review described in the SHIELD framework. The Go-Live stage is where Inspect is executed:

Is the solution within an approved safe zone pattern — auto-pass?
Does it match an approved workload pattern — pattern approval applies?
Does it require a full security review — new connectors, regulated data, external-facing?

The security review outcome must be documented and stored as part of the deployment record. Deployments to production without a corresponding Inspect record are a SHIELD Enforce violation.

UAT — User Acceptance Testing¶

User Acceptance Testing is the business validation gate — confirming that the solution meets the business requirements before going live with real users on real data.

Enterprise UAT principles: - UAT must be performed in the Test environment — not in a developer's personal environment or, worse, in production - Test environment must be configured identically to production — same DLP policies, same security roles, same connection references pointing to production-equivalent systems - UAT must be conducted by the business stakeholders who will use the solution — not by the developers who built it - UAT sign-off must be a formal recorded approval — not a verbal confirmation or an email that gets lost - UAT test cases must cover failure scenarios as well as happy path — error handling, edge cases, and integration failure behaviour

Performance Baseline¶

Before go-live, establish a performance baseline — the expected response times, load times, and throughput under expected user volumes. This baseline is the reference point against which production performance is compared in the Operations phase.

Solutions that have never had their performance measured under realistic load frequently surprise their operators. A canvas app that loads in two seconds with one concurrent user may take fifteen seconds with fifty.

Versioning Strategy¶

Solution versioning provides the audit trail of what was deployed, when, and what changed. Without versioning, rollback is guesswork and release history is nonexistent.

Version number convention: Power Platform solutions use a four-part version number: Major.Minor.Patch.Build (e.g. 2.3.1.0).

Component	When to increment	Example
Major	Breaking changes — data model changes that require data migration, architectural changes that are not backwards compatible	1.x.x → 2.0.0
Minor	New features or capabilities added in a backwards-compatible way	1.2.x → 1.3.0
Patch	Bug fixes and minor corrections	1.3.0 → 1.3.1
Build	Automated build identifier — incremented by the pipeline	1.3.1.0 → 1.3.1.42

Source control as the version of truth: Solution packages exported from environments are binary artefacts. The version of truth is the unpacked solution source in version control — tables, flows, apps, and configuration as human-readable source files that can be diff'd, reviewed, and merged. Every production deployment should correspond to a source control commit and a pipeline run.

Release notes: Every version deployed to production should have release notes — a human-readable summary of what changed, what was fixed, and what users should be aware of. Release notes are the communication artefact that bridges Go-Live and Operations — they inform the support team of what changed and provide the baseline for post-deployment monitoring.

Git Integration — Native Source Control from the Maker Experience¶

Solution Engineers and professional developers expect source control to be a natural part of their development workflow — not a separate step requiring tooling outside the platform. Power Platform's native Git integration addresses this directly, bringing source control into the maker experience without requiring Azure DevOps pipeline configuration as a prerequisite.

What native Git integration provides: Power Platform environments can be connected directly to a GitHub or Azure DevOps Git repository. Once connected, makers and Solution Engineers can commit solution changes to the repository from within the maker portal — without exporting solution packages, unpacking them with the CLI, and pushing manually. The platform handles the unpacking and commit, storing solution components as human-readable source files in the repository.

Why Git integration matters for enterprise: Enterprise solution development involves multiple contributors making changes concurrently. Without source control, concurrent changes create conflicts, overwrite each other, and produce a production environment that nobody can fully account for. Git integration makes Power Platform solutions first-class citizens in the organisation's source control infrastructure — subject to the same branching, review, and merge discipline as any other enterprise software asset.

Git integration vs pipeline-based deployment — complementary, not competing: A common point of confusion is whether native Git integration replaces Power Platform Pipelines or Azure DevOps deployment pipelines. It does not — they serve different purposes:

Capability	Git Integration	Deployment Pipeline
Source control — tracking what changed	Yes	No
Committing changes from the maker portal	Yes	No
Pull request review of solution changes	Yes (via GitHub/ADO PR workflow)	No
Deploying to Test and Production environments	No	Yes
Approval gates before production deployment	No	Yes
Solution Checker enforcement as deployment gate	No	Yes

Git integration is the source control layer. The deployment pipeline is the promotion layer. Both are needed for a complete enterprise ALM practice — Git integration without a deployment pipeline provides version history but no governed promotion process; a deployment pipeline without Git integration provides governed promotion but no source history or review capability.

Branch strategy for Power Platform solutions: Power Platform Git integration supports standard Git branching patterns — the same strategies used for application code apply:

Main / trunk branch — represents the current production state. Only pipeline-deployed, approved changes reach main.
Development branches — individual Solution Engineers work in feature or fix branches, committing changes as they build
Pull request reviews — changes from development branches to main are reviewed via pull requests — providing a human review step for solution changes before they enter the deployment pipeline
Environment alignment — development environments align to development branches; the deployment pipeline promotes from main

What Git integration stores: When a solution is committed via Git integration, the platform unpacks the solution into its component source files — canvas app source, flow definitions, Dataverse table and column metadata, plugin assemblies, web resources, and configuration. These are stored as structured text files (JSON, XML, YAML) that are human-readable, diff-able, and mergeable.

This means solution changes are reviewable in a pull request — a reviewer can see exactly which flow steps changed, which canvas app formula was modified, which column was added to a table. This level of review visibility was previously only achievable through manual solution unpacking with the Power Platform CLI.

Power Platform CLI and Git workflows: For Solution Engineers who prefer CLI-based workflows — or who need to automate source control operations in CI/CD pipelines — the Power Platform CLI (pac solution clone, pac solution pack, pac solution unpack) provides the same source control integration without the maker portal. CLI-based Git workflows are the foundation of Azure DevOps pipeline automation for Power Platform solutions.

The enterprise source control requirement: Every enterprise solution should have its source in a Git repository before the first production deployment. Source control is not optional for enterprise solutions — it is the mechanism that makes deployments auditable, changes reviewable, and rollback possible. Teams that defer source control setup until after go-live are operating without a safety net.

Rollback¶

Every production deployment must have a defined rollback plan. The question "what do we do if this deployment breaks something?" must be answered before the deployment is executed — not during the incident that follows.

Rollback mechanisms in Power Platform:

Solution rollback: Redeploying a previous solution version is the primary rollback mechanism. Power Platform Pipelines retains previous deployment artefacts — enabling re-deployment of a prior version. Azure DevOps pipelines retain solution packages in the pipeline artefact store. The rollback procedure is: identify the last known good version, redeploy it through the pipeline, verify restoration.

The rollback constraint: Solution rollback restores logic and configuration — it does not restore data. If a deployment includes data model changes (new tables, column modifications, record creation), rolling back the solution does not undo the data changes. Data rollback requires a separate data restoration process — and for most enterprise deployments, data rollback is not feasible.

The implication for data model changes: Deployments that include breaking data model changes — dropping columns, restructuring relationships, changing data types — have limited or no rollback capability. These deployments require: - Thorough testing before deployment - A maintenance window to minimise user impact - A data migration plan that is reversible where possible - Explicit acknowledgement that rollback is not available and fix-forward is the only remediation path

The hotfix exception: When a critical production issue requires immediate resolution that cannot wait for the standard pipeline — see the Hotfix Process section below.

Hotfix Process¶

A hotfix is an expedited deployment that bypasses the standard promotion cycle to address a critical production issue. Hotfixes are exceptional — they represent a controlled exception to deployment discipline, not an alternative to it.

When a hotfix is justified: - P1 incident — solution completely unavailable or data corruption in progress - Security vulnerability requiring immediate patching - Critical business process blocked with no viable workaround

Hotfix governance requirements: A hotfix that bypasses the standard pipeline without governance controls is an ungoverned production change — indistinguishable from the ad-hoc production editing that deployment discipline is designed to prevent. Hotfixes must be governed:

Emergency approval — documented approval from the solution owner and platform team before execution
Minimal scope — the hotfix contains only the specific fix, nothing else
Expedited testing — even under emergency conditions, test the fix in the Test environment before production — this takes minutes, not hours, for a targeted fix
Pipeline deployment where possible — even hotfixes should go through the pipeline if time allows. If a direct deployment is unavoidable, document it explicitly
Backfill to source control — the hotfix change must be committed to source control and the pipeline re-run within 24 hours to resynchronise the source with production
Post-incident review — every hotfix deployment generates a post-incident review item: what caused the issue and how does the standard deployment process change to prevent recurrence

Managed vs Unmanaged Solutions — The Production Rule¶

Power Platform solutions can be deployed as managed or unmanaged. This distinction is one of the most important — and most frequently misunderstood — aspects of enterprise solution deployment.

Unmanaged solutions: Unmanaged solutions allow all components to be viewed, edited, and extended in the target environment. They are the correct format for development environments — where makers need to modify components.

Managed solutions: Managed solutions lock components from direct editing in the target environment. Changes must be made in the development environment and deployed through the pipeline. Managed solutions also support managed properties — allowing specific components to be further locked from customisation or extension.

The production rule: All non-development environments — Test, UAT, and Production — must receive managed solution deployments. No exceptions.

Unmanaged solutions in production create an ungoverned customisation surface — any maker with sufficient access can modify components directly, outside of the deployment pipeline, without version control, without review, and without the ability to track what changed. This is the root cause of the "nobody knows what is in production" problem that plagues organisations without deployment discipline.

The layering model: Power Platform supports solution layering — multiple managed solutions from different publishers can coexist in an environment, with later layers extending or overriding earlier ones. For organisations building on top of Dynamics 365 or other managed base solutions, understanding solution layering is essential to avoid customisation conflicts and upgrade complications.

Release Communication¶

Go-Live is not complete when the solution is deployed. It is complete when users know what changed, what is new, and what they need to do differently.

Release communication principles:

Tell users what matters to them, not what the developer did: "We upgraded the flow engine and refactored the approval logic" is not useful to an end user. "Approval requests now appear in Teams as well as email — you can approve directly from the Teams notification" is.

Communicate before and after: - Before go-live — notify users of upcoming changes, especially if workflows or interfaces are changing significantly. Users who are surprised by changes lose confidence in the solution. - After go-live — confirm the release, summarise what changed, provide guidance on new features, and tell users how to get help.

Channels: - In-app notifications for minor changes — a banner or notification within the solution itself - Email or Teams message for significant feature releases - Updated in-app help content — the release is not complete until the help content reflects the new behaviour - Updated knowledge base articles — support team documentation updated before the release, not after the first support ticket

Maturity Levels¶

Level	Description	Suitable For
Basic	Solution used but deployment is manual and ad-hoc. No pipeline. Changes made directly in production occasionally. Version history incomplete.	Personal productivity solutions with a single developer and no compliance requirements
Intermediate	Solutions deployed through Power Platform Pipelines. Environment variables and connection references used. Solution Checker run before deployment. Managed solutions in production. Basic version numbering.	Team and departmental enterprise solutions with defined ownership and moderate change frequency
Advanced	Full ALM discipline — solutions in source control, automated pipeline with gates (Solution Checker, security review, UAT sign-off), managed deployments to all non-development environments, version strategy enforced, rollback plan documented, release notes published, hotfix process defined.	Mission-critical enterprise solutions with multiple developers, regulated environments, and formal change governance

Safe Zone¶

Solutions built and used by a single individual for personal productivity, with no shared users, no sensitive data, and no integration dependencies, can operate at Basic maturity.

Any solution that meets one or more of the following must reach Intermediate or Advanced maturity before Go-Live: - Has more than one developer contributing changes - Is used by more than one person - Integrates with enterprise systems of record - Contains sensitive, regulated, or personally identifiable data - Has compliance or audit requirements - Is mission-critical — unavailability has material business impact - Is deployed across multiple environments

Common Mistakes¶

No solutions — components floating in the default environment — apps and flows created directly in environments without being added to solutions. No deployment path, no version history, no rollback. This is the most fundamental ALM failure in Power Platform.
Unmanaged solutions in production — every maker with access can edit production components directly. Changes are untracked, unreviewed, and irreversible without a redeploy.
Hardcoded environment-specific values — URLs, email addresses, and identifiers embedded in flow logic rather than environment variables. The solution deployed to production connects to the development SharePoint site.
Connection references not configured on deployment — flows deployed to production that are still referencing development connections. Flows run against development data in production.
Solution Checker run manually and ignored — developers run Solution Checker, note the warnings, and deploy anyway. No automated gate enforcement.
UAT in the development environment — users sign off on behaviour in an environment that does not mirror production configuration. The production deployment reveals issues that should have been caught in testing.
No rollback plan — a production deployment causes an issue and the team discovers they have no documented rollback procedure and no retained previous version artefact.
Publisher prefix inconsistency — solutions built with different publisher prefixes by different team members, or with the default publisher prefix. Unmergeable components and deployment conflicts result.
Hotfixes made directly in production — critical fixes applied directly in the production environment browser, outside of source control and the pipeline. The source and production diverge immediately.
No release communication — users discover changes when they next open the solution. Confusion, support tickets, and loss of confidence in the solution follow.
Everything in one solution — a single solution containing every component of a large enterprise application. Every change — regardless of scope — requires deploying the entire solution, increasing deployment risk and duration.

Readiness Checklist¶

Solution Structure - [ ] All components in named solutions — nothing floating in the environment outside a solution - [ ] Publisher prefix defined and applied consistently - [ ] Solution boundaries defined — one solution per bounded context - [ ] Managed properties configured for production-locked components - [ ] Solution dependencies documented and verified

Environment Configuration - [ ] Environment variables defined for all environment-specific configuration - [ ] Azure Key Vault integration configured for secret environment variables - [ ] Connection references defined for all connectors — no direct connections - [ ] Test environment mirrors production configuration — DLP, security roles, managed environment settings

Deployment Pipeline - [ ] Power Platform Pipelines or Azure DevOps pipeline configured - [ ] Solution Checker configured as automated gate — severity threshold defined - [ ] Pre-deployment approval configured for production stage - [ ] Pipeline deployment history retained for rollback capability - [ ] Managed solution deployment confirmed for Test and Production

Quality Gates - [ ] Solution Checker passing at defined severity threshold - [ ] SHIELD Inspect gate completed and documented — safe zone, pattern approval, or full review - [ ] UAT completed in Test environment by business stakeholders - [ ] UAT sign-off formally recorded - [ ] Performance baseline established under realistic load conditions

Versioning and Source Control - [ ] Version numbering convention defined and applied - [ ] Git repository connected to development environment — native Git integration or CLI-based workflow - [ ] Branch strategy defined — development branches, main/trunk, PR review process - [ ] Solution source in version control — unpacked source files, not binary exports - [ ] Pull request review process established for solution changes before pipeline promotion - [ ] Every production deployment corresponds to a source control commit and pipeline run - [ ] Release notes prepared for production deployment

Rollback - [ ] Rollback plan documented — previous version artefact retained, procedure defined - [ ] Data model change impact on rollback assessed — fix-forward plan prepared where rollback is not feasible - [ ] Hotfix process defined — approval, scope, testing, backfill, review requirements

Release Communication - [ ] User communication prepared — what changed, what is new, what users need to do - [ ] In-app help content updated to reflect release changes - [ ] Support team briefed before release — aware of changes and ready for questions - [ ] Post-release monitoring plan in place — Application Insights, flow run history review

Part of the DIALOGE Framework — powerplatform.wiki Last updated: March 2026 Last reviewed: March 2026