You Hired a Dynamics Developer Who Misrepresented Their Skills: Damage Control

If a Dynamics 365 developer who overstated their experience has left you with a failed migration and a compliance audit is coming, make the first moves in this order. Revoke or scope down their access, including app registrations, client secrets and connections they created. Take an environment backup. Inventory every change they made: solutions imported, flows created, security roles altered, plug-in steps registered and records bulk-updated. Then assess honestly what is recoverable and what has to be rebuilt, and write that down before the audit rather than during it. After that come a remediation sequence, a factual account of the affected period for the auditor, and a vetting standard that never mistakes a certification for delivery experience.

Why does the order of the first moves matter?

Every step after the first changes the environment, and every change can overwrite the evidence you will need to explain the affected period. Fixing a flow before you have recorded what it did, or deleting a solution before you have exported it, turns a documented problem into an unexplained one.

Keep the work about the system, not the person. Record what was changed, when and with which account, and leave judgements about conduct, contracts and any recovery of fees to HR and legal advisers. A neutral, factual record is also the one an auditor can rely on.

How do you revoke or scope down access without breaking production?

Do it today, but in a way that does not take down processes the business depends on.

• Remove System Administrator, System Customizer and any other elevated security roles from their Dynamics 365 user, and remove them as an environment admin in the Power Platform admin center.
• In Microsoft Entra ID, list the app registrations they created or own. Rotate every client secret and certificate they could have copied, and check which Dataverse application users map to those registrations and what roles those users hold.
• List the Power Automate flows they own and the connections and connection references those flows run under. Flows running on a personal connection will stop when the account is disabled, so move them to a service account first, then disable the account.
• Remove access to Azure DevOps or GitHub repositories, pipeline service connections, shared credentials and any integration endpoints they configured.

Write down the time of each revocation. That timestamp marks the end of the affected period.

What should the environment backup capture?

Take a manual backup of each affected environment in the Power Platform admin center, labelled with the date and the reason. Restores go to a target environment rather than silently rolling back production, and retention and restore rules change, so check current Microsoft documentation rather than assuming.

A platform backup is not enough on its own. Also export every unmanaged solution and record the installed solution list with versions, save flow definitions and plug-in assemblies, and export the audit history for the affected period before your retention setting ages it out. Then copy production to a sandbox and do the investigation there, not in the live system.

How do you inventory every change they made?

Build one register, with a row per change: component, type, environment, date, account used, current state and evidence. The sources are these.

• Solutions: solution history in the maker portal shows imports, upgrades and deletions with who and when. The solution layers view on key tables and forms shows unmanaged changes sitting on top of managed ones.
• Flows: every flow created or modified by their account, its owner, its connections and its run history, including flows that write to the tables the migration touched.
• Security roles: role assignments and privilege changes, taken from audit history where auditing captured them, and compared against a pre-engagement solution export or another environment where it did not.
• Plug-ins: assemblies and step registrations, including message, stage and filtering attributes, from the Plug-in Registration Tool, along with custom workflow activities, webhooks and service endpoints.
• Bulk updates: audit history filtered to their user and the date range, system jobs for bulk deletes and asynchronous operations, and the data import records created by migration runs.

Audit history only exists for tables and columns where auditing was switched on. Where it was not, record the gap as a finding rather than filling it with assumptions.

How do you decide what is recoverable and what must be rebuilt?

Put every row of the register into one of three groups. Keep: it works, someone understands it and it matches a requirement. Fix: the design is sound but the implementation has defects. Rebuild: nobody can explain it, it relies on unsupported techniques, or correcting it would cost more than replacing it.

Treat data the same way. Records overwritten in bulk can often be restored from audit old values or from the backup. A partial migration loaded without alternate keys, with duplicates and broken lookups, is usually cheaper to reset and reload than to patch row by row. Our guide to recovering a failed Dynamics 365 migration covers that decision.

Write the assessment down, date it and have the system owner sign it before the audit. If nobody in-house can judge the build, the fixed scope audit in our project rescue and takeover service exists for exactly this moment.

What order should the remediation follow?

1. Security first: least-privilege roles, cleaned-up app registrations and service accounts that own every production connection.
2. Stop further damage: switch off, without deleting, the flows and plug-in steps that write bad data.
3. Correct data in a sandbox rehearsal first, with record counts before and after, then in production.
4. Put solutions under source control and deploy managed solutions through a pipeline, as set out in our Power Platform ALM guide.
5. Rebuild the components marked for rebuild, starting with those the audit will test.
6. Rerun the migration properly, with keys, dependency order and reconciliation.
7. Add the controls that would have caught this: a second reviewer and no single account with unreviewed production admin.

What should you tell the auditor about the affected period?

This is technical guidance, not legal advice. Agree the approach with your compliance lead and, where personal data was affected, your data protection officer or legal advisers. What the system work can give them is a factual, dated account:

• a timeline from access granted to access revoked, with the dates of the main changes and of discovery;
• what was affected, by table and record count, taken from the inventory;
• what evidence exists and where it has gaps, such as tables without auditing;
• what was corrected, how it was verified and what is still open;
• the controls added since, with the date each took effect.

Describe the work and the control failures, not the individual. Do not quote corrected figures until reconciliation is complete. How Dataverse auditing, retention and export work as evidence is covered in our guide to Dynamics 365 audit trails for compliance.

What vetting standard prevents a repeat?

A certification shows that someone passed an exam. It does not show that they have shipped a plug-in, run a migration or taken a solution through a release pipeline. Ask for delivery evidence instead, and test it with a short paid work sample on a real item from your backlog in a sandbox, watching how they read what is already deployed before changing anything.

Our staff augmentation page sets out, in its vetting section, the questions that let you vet a Dynamics 365 supplier properly, and they apply to an individual contractor as much as to a consultancy. Before hiring anyone, it is worth deciding which work needs a developer at all, using our guide on when to hire a Dynamics 365 consultant.

When should you bring in a delivery team instead of another hire?

When there is no internal capacity left to assess, remediate and prepare for the audit at the same time, another single hire repeats the original risk. Solzet's senior consultants and full-stack developers bring 8+ years of Dynamics 365 Customer Engagement and Power Platform work, delivering remotely from Yerevan, Armenia, directly or white-label for Microsoft partners. Where the assessment shows the platform itself never fitted the requirement, we also build custom CRM systems without Microsoft licensing.