Pre- & Post-Deployment Tasks

Deployment of a Dataverse solution is rarely just "import the .zip". This chapter documents the tasks that must run immediately before and after that import, and — for the server-side push — what actually happens inside the tooling, so you know what to expect when something doesn't look right.

Pre-deployment

Task	Tool	Notes
Regenerate early-bound models	dgtp codegeneration	Must run before the dependent build step compiles, not before deployment itself — see Build Pipeline. Listed here as a reminder it's a pre-deploy dependency, not a deploy-time one.
Bump solution version	dgtp maintenance solution-version	Targets the build environment, before export — see Versioning.
Push plugin/Custom API assemblies	dgtp push <file>.nupkg --solution <name> --publish	See dgtp push in depth below.
Push web resources	dgtp push <folder> --solution <name> --publish [--delete-obsolete] [--config mapping.json]	See web resource push below.
Ensure target is a Managed Environment	—	Required for Power Platform Pipelines; see Power Platform Pipelines.
Resolve environment-specific values	Environment variable values, connection reference connections	These are not solution-aware in the way schema is — see Env Variables & Connection References and Config & Reference Data Migration.

dgtp push in depth

dgtp push is the tool we use instead of (or alongside) pac plugin push for registering compiled server-side artifacts, because it does more than copy an assembly: it reconciles the entire registration — types, steps, and step images — against what's declared in code via registration attributes.

dgtp push ./bin/Release/MyPlugins.nupkg --solution dgt_myproject_plugins --publish

Depending on whether Target is a .nupkg, a plain .dll, or a web-resource folder, dgtp push creates or updates the package/assembly and then reconciles plugin/workflow types, SDK message processing steps, and pre/post entity images against the registration attributes in code — upserting and purging, so removing a [PluginRegistration] attribute and re-pushing is enough to unregister the step. A successful dgtp push is therefore the definitive signal that registration matches code. --publish publishes the affected customizations afterwards; without it, changes land but stay unpublished.

The full per-target-type breakdown and the supported web-resource extensions are in the Command Reference → push.

Web resource push

dgtp push ./WebResources --solution dgt_myproject_client --publish --delete-obsolete

When Target is a folder, dgtp push walks it and creates/updates web resources in the given solution, matching files to existing web resources by name. --delete-obsolete removes unmanaged web resources that exist in the solution but no longer exist in the folder — useful for keeping a dev environment's web resources in sync with a renamed/removed file, but treat it as a one-way sync and review its effect on a shared environment before automating it unattended. --config points to a mapping file when the on-disk layout doesn't map 1:1 to web resource names.

Import behavior: Upgrade, not Update

DGT-ALM-080 — Import managed solutions as an Upgrade (or stage for upgrade where the deletes need to happen in a controlled second step) — not as an Update. Update merges the incoming version over the installed one and never deletes anything: a component you removed in dev quietly lives on in every downstream environment. Upgrade reconciles the target against the new version and removes what's gone. See Microsoft's import/export documentation.

Deployment settings file

DGT-ALM-090 — Automated deployments provide environment-specific values — connection references and environment-variable values — through a deployment settings file per target environment (pac solution import --settings-file, the Power Platform Build Tools equivalent, or Power Platform Pipelines' pre-deployment step), checked into source control with secrets referenced, not embedded. Manually clicking values into the target after import is not a deployment mechanism. See Microsoft's guidance on connection references and environment variables in pipelines.

Post-deployment

Task	Tool	Notes
Set/confirm environment variable values	Manual, or an unmanaged "values" solution per environment	Definitions are solution-aware; values, by design, are not. See Env Variables & Connection References.
Re-point connection references	Manual (per-user) or service-principal connection	Connection assignment is user-specific even after deployment — re-confirm after every target environment refresh.
Confirm flow ownership & run-as	Power Platform admin center / pac	After an import via service principal, flows are owned by that service principal — its connections must exist, and run-as/ownership may need re-assignment. See Microsoft's delegated-deployment guidance.
Check for unmanaged layers	dgtp analyze noactivelayer / "Solution layers" view	An unmanaged layer on top of a managed component silently overrides every future deployment of it — the most common cause of "the change didn't arrive". Remove active custom layers; run this check periodically in test/prod, not just after incidents. See solution layers.
Re-import migrated config/reference data	dgtp import ...	See Config & Reference Data Migration.
Smoke-test registered steps	—	Confirm the steps you expect to see after a dgtp push are actually present and enabled, especially after a --delete-obsolete run.
Tag the release in Git	CI, automatic	Only after the deployment to that stage's reference environment succeeds — see Versioning.

Pipelines extensibility as the trigger point

If you deploy via Power Platform Pipelines, the pre-/post-deployment tasks above that aren't already baked into the build artifact (e.g. config data migration, environment variable values) are good candidates for a gated extension Power Automate flow triggered by OnDeploymentRequested / OnDeploymentStageRunCompleted, rather than a manual checklist step.