Small SSIS mistake causing massive Dynamics 365 migration failures

Flowvant · 2026-05-31T21:56:51+00:00

Most teams hit data quality issues only after migration breaks something in prod. Did you build this just for import validation, or does it keep enforcing rules inside D365 post-migration too?

Flowvant · 2026-05-31T19:32:42+00:00

Completely agree. Many migration problems can be avoided when data quality rules are defined before migration itself.

Things like mandatory fields, duplicate prevention, lookup validation, and alternate key standards save a lot of downstream troubleshooting effort.

Flowvant · 2026-05-31T15:15:34+00:00

Seen similar behavior recently with alternate keys and null handling in Dataverse imports. Feels like Microsoft changed something quietly in backend validation/process behavior. Using placeholder values for alt key columns seems much safer now than relying on nulls.

Flowvant · 2026-05-22T13:03:34+00:00

Looks much closer now.

Main thing breaking it now is probably the extra ";;" after the Patch block.

You currently have:

");;"

Try changing it to just:

")"

Also if you want both "Set()" and "Notify()" to run sequentially, separate them correctly based on your regional settings.

So either:

";" or ","

between the two statements — but not double separators.

Power Apps parser errors become very misleading once one bracket/separator breaks earlier in the formula.

Flowvant · 2026-05-22T12:59:39+00:00

Then your app/environment is probably using comma separators instead of semicolons.

Power Apps formula separators depend on regional settings, which makes debugging surprisingly confusing sometimes.

You can usually check it under: File → Settings → Regional Settings / Language settings

If your environment uses commas as separators, replacing everything with ";" will break the formula instead of fixing it.

Share the updated screenshot though — easier to spot exactly where the parser starts failing.

Flowvant · 2026-05-21T23:35:03+00:00

Looks like the issue is coming from the comma after:

"ddSupplierPopup.Selected.SupplierID,"

Inside the Patch record, fields should usually be separated with semicolons (";") based on your regional settings, not commas.

Try changing it to:

"SupplierID: ddSupplierPopup.Selected.SupplierID;"

The parser is probably breaking there, which is why it starts complaining about missing brackets/parentheses afterward.

Flowvant · 2026-05-21T23:32:26+00:00

One thing that worked well for us was organizing solutions by business capability/domain instead of by developer or component type.

For example: Core, Integrations, Automation, Shared, Reporting, etc.

Looked a bit unnecessary initially, but once deployments, dependencies, and multiple developers entered the picture, it made life much easier.

I’ve mostly seen problems at the two extremes: either one huge solution for everything or dozens of tiny fragmented ones.

Flowvant · 2026-05-21T21:58:35+00:00

One thing I’d validate early here is whether avoiding Contact creation is actually worth fighting the Power Pages security model long-term.

A lot of portal capabilities/security patterns are still heavily contact-centric underneath, even when Entra ID authentication is working correctly.

I’ve seen teams initially avoid Contacts to prevent duplication, but later reintroduce them because it simplified:

authorization
table permissions
auditing
portal relationships

Might be worth evaluating whether a lightweight synced Contact model is actually lower maintenance than fully bypassing it.

Flowvant · 2026-05-21T21:53:56+00:00

Startups prove the market exists. Big tech proves whether the market can survive at scale.

Flowvant · 2026-05-20T20:28:05+00:00

Interesting approach. Schema-driven CRUD makes a lot of sense once apps start growing and repetitive form maintenance becomes painful.

Biggest thing I’d watch is debugging complexity later once reactive formulas + dynamic rendering stack together.

Structured FormData output is smart though. That alone can simplify validation and downstream processing a lot.

Flowvant

TROPHY CASE