Summary
Add first-class CLI support for deleting Dataverse solution components from the target environment, instead of relying on indirect workarounds through generic data CRUD or external/manual cleanup.
Why this matters
During a clean-room end-to-end test, solution import was blocked by existing unmanaged security roles with the same names but different GUIDs:
Warehouse managerWarehouse worker
We were able to recover only by deleting the conflicting roles from the environment first. The current CLI surface does not expose this as an obvious component-management workflow.
Current surface
txc environment component currently supports inspection only (layer, dependency)txc environment data record may be able to delete raw rows, but that is not discoverable as a solution-component remediation flow and pushes users to know Dataverse internals
Desired outcome
A first-class component deletion concept in the CLI, for example:
txc environment component delete ...- possibly with component-type-aware safety checks, dependency reporting, preview/dry-run, and production confirmation handling
Suggested capabilities
- Delete by component type + logical identity, not just raw table/row details
- Show dependency / safety analysis before delete
- Support common ALM recovery cases like:
- conflicting security roles
- stale plugin steps / plugin assemblies
- leftover unmanaged components blocking import
- Offer clear guidance when deletion is the appropriate remediation path
- Preserve production safeguards (
--allow-production)
Context from test run
In this session, the Security solution import failed with:
Cannot import security role with Id [..] and name [Warehouse manager]. A security role with the same name but different Id already exists.
The existing role had no blocking dependencies and was safe to remove, but the cleanup path was not first-class in the CLI UX.
Summary
Add first-class CLI support for deleting Dataverse solution components from the target environment, instead of relying on indirect workarounds through generic data CRUD or external/manual cleanup.
Why this matters
During a clean-room end-to-end test, solution import was blocked by existing unmanaged security roles with the same names but different GUIDs:
Warehouse managerWarehouse workerWe were able to recover only by deleting the conflicting roles from the environment first. The current CLI surface does not expose this as an obvious component-management workflow.
Current surface
txc environment componentcurrently supports inspection only (layer,dependency)txc environment data recordmay be able to delete raw rows, but that is not discoverable as a solution-component remediation flow and pushes users to know Dataverse internalsDesired outcome
A first-class component deletion concept in the CLI, for example:
txc environment component delete ...Suggested capabilities
--allow-production)Context from test run
In this session, the Security solution import failed with:
Cannot import security role with Id [..] and name [Warehouse manager]. A security role with the same name but different Id already exists.The existing role had no blocking dependencies and was safe to remove, but the cleanup path was not first-class in the CLI UX.