Introduction¶
Teams working on Dynamics 365 CE / Dataverse projects often don’t struggle with writing code, but rather with obtaining environment information: Will importing this solution to SIT crash other customized solutions? Which forms and views reference a specific field? Why are the same forms different between two environments? Will this MR deployment to UAT cause issues? Running scripts on your own computer, browsing the Power Platform Admin Center, or manually writing Power Platform CLI commands all fall into the category of “doable but fragmented.”
The dsh-d365-kit introduced below is a DeepSeek Harness (DSH) plugin bundle released by maintainer iTanzhao, specifically designed to delegate these queries to the DSH agent. It is read-only by default; without granted capabilities, the agent can only view, not modify.
What is it¶
In short, dsh-d365-kit is a development and deployment assistant for Dynamics 365 CE / Dataverse, installed as a DSH bundle. It turns a real D365 organization into an object that the agent can query directly—covering metadata, solution layering, snapshot differences, reference relationships, migration risks, code change impact, and controlled writes.
Users provide URL, tenant, ClientId, and secret; the plugin accesses the environment via the Dataverse interface. The agent sees structured tool call results, not raw web pages or exported files that require manual parsing.
The positioning in the README is ten tools, one settings page, read-only as default.
Core Features¶
Connection and Environment¶
| Tool | Function |
|---|---|
d365_envs |
Environment inventory, checks if credentials are complete; with check: true, it actually connects once |
d365_configure |
Add/Edit/Delete environments (URL, tenant, ClientId, secret), test connectivity |
d365_health |
Suspended or failed background jobs, currently running import/publish tasks, recently installed solutions |
Metadata and Solution Layering¶
d365_metadata: Covers 19 resource types, including entities, attributes, relationships, forms, views, workflows, business rules, plugins, web resources, solutions, components, Custom API, site maps, option sets.d365_layers: Readsmsdyn_componentlayer, answers which solutions cover a component, which layer is on top, and which layer is currently effective.
Snapshots and Differences¶
d365_sync: Pulls the environment’s metadata into a local snapshot, recording “complete / truncated / failed” status for each resource.d365_diff: Field-level differences between two snapshots (added, deleted, modified), with noise filtering and expired snapshot reminders.
Impact Analysis and Data¶
d365_refs: Reverse lookup. Which forms/views/processes does a field point to? Which forms and events reference a web resource? Which types and steps do assemblies correspond to?d365_data: Business record count / group by / sample; requiresdata.readcapability.d365_data_write: Create or update a single business record; executes only after confirmation in the conversation; requiresdata.writecapability.
Write Operations¶
d365_write supports adding, updating, deleting option values and fields, renaming tables, and adding/removing system view columns. plan-* actions only produce plans; execute requires manual confirmation and leaves a queryable audit record afterwards.
Migration and Checks¶
d365_migrate: Solution migration risk assessment, covering layer masking, missing components, lost option values, versions, and managed status.d365_contract: Contract matrix and drift, comparing assemblies, plugin types, steps, form libraries, handlers, site maps, and option values; supports exemptions and trends.d365_code_check: Reads GitLab MR, maps JS/C# changes to the target environment, reports blocker / warning / requires manual confirmation. JS changes map to web resources and forms; C# changes map to assemblies/types/steps/images.
Operations¶
d365_reports: Local artifacts and disk usage, cleanup based on retention policy (default dry run), snapshot compression.
Settings Page¶
“Settings → D365 Toolkit” in the DSH Web UI, consisting of six tabs:
- Environments: Environment inventory, connection tests, default environment
- Permissions: Toggle capabilities by environment (read business data / various writes), change used solutions, copy to other environments
- Plans: Pending write plans, recent change records, and publish results (can be republished)
- Data: File count, size, retention policy for various artifacts, dry run and cleanup, snapshot compression
- GitLab: Repository address, default project, read-only token (
read_api) - General: Number of snapshots to keep, default row limit, request timeout
Interface language follows DSH (CN/EN). The environment inventory and d365_configure use the same storage code, so the interface display is consistent with the results read by the agent.
Installation and Enablement¶
Prerequisites: DSH Desktop; ability to access *.dynamics.com; a read-only app user (ClientId + secret).
# Install from npm (shortest path, upgradable; available after package publish)
plugin_manager install_bundle target="dsh-d365-kit@0.22.1"
# Install from Git (no registry needed, can pin a tag)
plugin_manager install_bundle target="git+https://<your-git>/<group>/dsh-d365-kit.git#v0.22.1"
# Install from local directory (link mode, code changes take effect immediately)
plugin_manager install_bundle target="D:\path\to\dsh-d365-kit"
dsh-d365-kit@<version> resolves from the npm registry; a separate GitHub repository requires the git+https:// form. The repository includes .github/workflows/publish.yml. After configuring NPM_TOKEN, pushing a v* tag will publish it to npm.
Restart DSH after installation to allow the web client to load the settings page code into the module graph. Then, add the environment in Settings → D365 Toolkit → Environments (key, URL, tenant, ClientId, secret), test the connection, and save. It is read-only by default; when reading business records is needed, check “Read business data” under Permissions.
Typical Usage¶
1. Pre-deployment Solution Assessment¶
What are the risks of shipping this solution to SIT and UAT?
d365_migrate action=assess source=dev solution=ContosoBase targets=["sit","uat"]
The report answers: Does the target environment already have this solution? Is the source version higher? Which layer suppresses which on each component (lists of obscured solutions)? Will option sets lose values? Results are saved to .d365/reports/migration-*.md.
2. Can this field be deleted?¶
Who else still uses account.contoso_customertier? Also check how many records carry a value.
d365_refs kind=field entity=account attribute=contoso_customertier
d365_data action=group entity=account field=contoso_customertier
3. Why are two environments different?¶
d365_sync environments=["dev","sit"]
d365_diff base=dev head=sit resources=["forms","views","attributes"]
d365_layers component=Account componentType=SystemForm
First pull snapshots of both environments, then do a field-level diff, and finally see which component is covered by whom.
4. Can this MR go to UAT?¶
d365_code_check mergeRequest="https://gitlab.example.com/contoso/powerapps/-/merge_requests/7759/diffs" targets=["uat"]
Suitable Scenarios and Notes¶
Suitable for those already using DSH and need to frequently compare and evaluate D365 solutions across environments: determining solution layer masking, impact scope before deleting fields, locating cross-environment differences, checking before MR deployment, and plugin registration drift upstream/downstream.
Points to note:
- The plugin runs with the permissions of the current DSH process. Before installing, check the source code (repository is MIT License, viewable directly) and the license to ensure no reading scope exceeds expectations.
- Write capabilities are not granted by default. They must be explicitly checked in Permissions, and
executerequires manual confirmation. Please manage read-only credentials and write credentials separately. - Metadata pulling and business data reading are affected by network and row limits; snapshots may be marked as truncated. Check the record status of
d365_syncbefore publishing. - The availability of online tools depends on the network path to
*.dynamics.comand the validity of credentials.
Conclusion¶
The value of dsh-d365-kit lies in transforming information in the D365 environment that requires repetitive manual queries into tools the agent can invoke, and blocking write operations until human confirmation. The feature set is broad; practical use usually starts with read-only diagnostics.
Directory: https://www.skillhub.cn/plugins/iTanzhao/dsh-d365-kit
GitHub: https://github.com/iTanzhao/dsh-d365-kit