Customer-facing uninstall option for unused first-party Microsoft-published managed solutions

In the Power Platform admin center, the Environments > Dynamics 365 apps surface is intentionally an install, configure, and update experience and does not offer an Uninstall action for first-party Microsoft-published managed solutions. The same removal request from the Power Apps > Solutions page is, in practice, almost always blocked by managed properties or by dependencies the customer cannot resolve. The combined result is that solutions from retired or unused first-party product families remain permanently installed on an environment even when the customer has never adopted them and has no plan to. Administrators discover them, recognize them as unused, and reasonably try to remove them, but there is no supported customer path to do so.

This is not a hypothetical concern. A real example surfaced through a recent Microsoft Support case for a small education-sector tenant running on its default production environment. The tenant relies on the included Dataverse quota (3 GB database, 3 GB file, 1 GB log) and has no paid storage add-ons. On that environment, the residual first-party footprint that the customer cannot remove looks like the following:

• The Project Service Automation (PSA) family, covering Project Service Core and 12 related Project / Scheduling solutions, is the largest contributor and accounts for the bulk of the approximately 520 MB observed in the Solution table on this environment.
• PSA itself is a retired product that reached end of support on March 31, 2025, with Project Operations as the supported successor, and there is no customer-removable path for the residual solutions.
• Microsoft Check-ins is a platform-provisioned first-party package that maintains a persistent footprint on the environment and is also not customer-removable.
• Data Archive Service - Trial is another platform-provisioned first-party package, related to the long-term retention capability, with the same persistent footprint and no customer-removable path.

For a tenant of this profile, ~520 MB inside the Solution table is a meaningful share of the 3 GB included database quota, and it is content the customer never asked for and cannot release. The orphaned-component cleanup script that Microsoft Support runs in the backend addresses a different scenario (orphaned shared web resources in WebResourceBase) and does not touch this category, so support engineers today have no remediation lever to offer beyond "leave it in place."

The pattern this creates is repetitive and avoidable.

A customer notices the unused solutions, attempts removal, hits the missing-Uninstall behavior, and opens a support case. The support engineer confirms the behavior is by design, recommends against forcing removal because of dependency and data-loss risk, and routes any further capacity need to the documented Dataverse capacity-management path.

Each cycle consumes both customer and Microsoft time on something that cannot be remediated under the current product behavior, and the absence of a definitive public statement on Microsoft Learn (especially for Microsoft Check-ins and Data Archive Service - Trial, where there is no documented customer-side uninstall procedure at all) reinforces the loop.

Several improvements would address this in a way that is consistent with how the platform already behaves elsewhere, listed in order of preference.

1. The first and strongest option is to expose an Uninstall action in PPAC > Dynamics 365 apps specifically for first-party solutions that the platform itself determines are safe to remove, such as packages from retired products, trial packages, and packages that have never been used in the environment and have no remaining dependencies.
2. A second option, slightly weaker but still valuable, is to make the same category of solutions properly removable through Power Apps > Solutions, paired with a clear and actionable dependency report so the customer understands exactly what blocks removal and what is safe to proceed with.
3. A third option, much lower effort but still meaningful, is to publish definitive Microsoft Learn guidance, on a per-solution-family basis, stating whether each first-party solution is customer-removable, what the prerequisites are, and what the supported mechanism is. Even an explicit "not customer-removable, by design" statement would significantly reduce the support pattern described above.
4. Finally, as a longer-term improvement, an opt-in platform job could automatically retire residual solution footprints from end-of-support first-party products (for example, removing PSA components from environments that have not used them for N months following the EOS date), aligning the platform behavior with the product lifecycle.

This request is intentionally narrow and does not ask for bulk removal of actively supported first-party solutions, nor for any action that would affect tenants currently using those products. It asks specifically for customer-facing clarity and optional removal of unused or retired first-party footprints, with the platform itself deciding which solutions qualify. The goal is to give administrators an honest answer to a reasonable question they keep asking: "if I am not using this, and Microsoft has retired it, why must it stay?"