[vignesh chandra bose]

Up

0

Down

::

This shared-responsibility model is actually quite common in AX 2012 → Dynamics 365 F&O upgrade projects, especially when industry-specific ISVs or complex customizations are involved.

In most projects, the primary implementation partner usually owns:

• core code upgrade activities

• environment management

• data migration

• release planning

• overall project governance

The secondary partner generally focuses on:

• ISV compatibility

• customization remediation

• module-specific functionality

• industry workflows

• functional validation and gap analysis

For example, specialized Microsoft partners like Dynamic Netsoft are often involved in projects where real estate, property management, or contract management solutions are part of the upgrade scope.

One best practice that helps in these multi-partner upgrades is maintaining a shared DevOps backlog, unified testing cycles, and clearly defined ownership boundaries from the beginning. Without that, overlap between technical remediation and functional testing can create delays quickly.

From what I’ve seen, projects tend to succeed when:

• responsibilities are clearly documented

• architecture standards are aligned early

• both partners participate in joint UAT cycles

• escalation and dependency tracking are centralized

The move toward extension-based development and clean-core architecture in Dynamics 365 F&O has also made this collaboration model much smoother compared to older AX overlayering approaches.

[vignesh chandra bose]

Up

0

Down

::

Honestly, I’d pick industry experience over partner tier any day. A team that understands your business will get you live faster than a “top” partner figuring things out as they go.

Also, try to stick to standard features first. Too much customization early on usually creates problems later. And if a partner agrees to everything you say, that’s usually a red flag.

[vignesh chandra bose]

Up

0

Down

::

Hi Richard, this is a really relevant question.

The documentation does feel a bit high-level around AI agent dependencies.
Interested to hear from anyone who’s already set this up end-to-end.

[vignesh chandra bose]

Up

0

Down

::

Yes, we’ve integrated Dynamics 365 SCM with Power BI in a few real-world scenarios, and it’s been quite effective when set up properly. In practice, the data is usually near-real-time rather than truly real-time, depending on whether you’re using direct query, entity store, or scheduled refresh, but for most supply chain KPIs that cadence works well.

From what we’ve seen at Dynamic Netsoft Technologies, teams get the most value when they first agree on the KPIs that actually matter: inventory turnover, fill rates, supplier performance, production variance and then design dashboards around those instead of pulling everything into Power BI. Customization is fairly straightforward once the data model is understood, especially if you build a semantic layer rather than querying raw tables.

One lesson learned is to invest some time upfront in data modeling and governance. When that’s done right, Power BI becomes a strong layer for visibility and decision-making on top of D365 SCM rather than just another reporting tool.

Curious to hear how others are handling refresh strategies and performance at scale.