M365.FM - Modern work, security, and productivity with Microsoft 365

Business Central works. Your finance team trusts the numbers. The company grows. Then someone says: “We’ll just move to Finance & Operations later.”There’s one problem: Business Central and Dynamics 365 Finance & Operations are not two steps on the same ERP ladder.In this episode of M365 FM, Mirko Peters breaks down why moving from Business Central to Finance & Operations is not a traditional upgrade or migration. We explore the architectural differences, data models, consolidation challenges, Dataverse integration, M&A scenarios, migration costs, process redesign, and how organizations can prepare before growth exposes the gap.

THE BUSINESS CENTRAL TO F&O TRAP
Business Central and Finance & Operations come from two different product families.Business Central evolved from Dynamics NAV, while Finance & Operations evolved from Dynamics AX. They were created for different organizations, different levels of complexity, and different operating models.That means moving from BC to F&O isn't equivalent to upgrading NAV to Business Central. There is no simple upgrade button because the underlying architecture itself is different.

WHY THIS IS A REIMPLEMENTATION
The technical architecture, data models, posting logic, dimensions, account structures, and legal-entity concepts differ between the platforms.Moving data therefore requires extraction from Business Central, transformation into F&O's structures, loading through F&O's data-management tooling, and extensive validation.Each stage introduces its own workload and risk, making the move closer to a new ERP implementation than a conventional software upgrade.

WHAT BUSINESS CENTRAL WAS BUILT FOR
Business Central prioritizes simplicity.It works particularly well for organizations with one entity or a relatively small number of connected companies, straightforward financial structures, regional operations, and teams that need an ERP without enterprise-level complexity.Complexity is something Business Central allows organizations to add when necessary rather than something every implementation starts with.

WHAT FINANCE & OPERATIONS WAS BUILT FOR
Finance & Operations starts from a very different assumption.Multiple legal entities, multiple countries, multiple currencies, enterprise consolidation, sophisticated manufacturing, complex approval structures, and global financial operations are fundamental parts of its architecture.F&O treats enterprise complexity as something that exists from day one rather than an exception added later.ㅤ

WHEN GROWTH EXPOSES THE DIFFERENCE
The architectural gap can remain invisible for years.Then an acquisition happens. Suddenly there are multiple ERP instances, charts of accounts, currencies, financial definitions, and legal entities.Leadership still expects one consolidated view of revenue, margin, and financial performance. Finance teams can find themselves extracting information from multiple systems and reconciling it manually in spreadsheets.This is often the moment when “let's move to F&O” changes from a future roadmap idea into an urgent business requirement.

WHY M&A MAKES THE PROBLEM BIGGER
Acquisitions multiply ERP complexity.Several acquired companies can mean several Business Central environments, separate charts of accounts, different master-data definitions, different configurations, and different financial processes.Intercompany eliminations and consolidation then become particularly difficult because F&O's native capabilities operate inside its own architecture rather than automatically solving every external Business Central scenario.

DATAVERSE AND THE INTEGRATION REALITY
Dataverse can provide a shared data layer across Microsoft business applications, but this does not mean Business Central and Finance & Operations suddenly become one system.F&O's dual-write capabilities and Business Central's Dataverse synchronization are separate integration mechanisms.Organizations operating BC subsidiaries alongside an F&O headquarters therefore need to understand that they're connecting separate integration architectures rather than enabling one universal synchronization switch.

WHY REAL-TIME FINANCIAL VISIBILITY GETS DIFFICULT
Financial information crossing system boundaries can introduce synchronization and batch-processing delays.This becomes particularly important during month-end close, when headquarters needs accurate consolidated numbers while subsidiaries continue posting transactions.Integration can move information between systems, but it does not magically turn independent ERP platforms into a single real-time database.

WHEN THE PATCHWORK BECOMES MORE EXPENSIVE
Integration has an ongoing cost.Custom mappings need maintenance. Elimination logic changes. Synchronization jobs need monitoring. Acquisitions introduce additional complexity. Finance teams spend time reconciling systems, and auditors need to follow transactions across multiple environments.Eventually, organizations need to compare the continuing cost of maintaining that architecture with the cost of consolidating onto Finance & Operations.ㅤ

MIGRATION IS THE WRONG WORD
A BC-to-F&O project involves much more than transferring data.The systems use different table structures, posting logic, account frameworks, workflows, and business assumptions.Extraction, transformation, loading, and validation are substantial projects themselves. Calling the initiative a simple “migration” can therefore lead organizations to underestimate both budget and timeline before implementation even begins.

BUSINESS PROCESS REDESIGN
The difficult part isn't only data.Procurement, manufacturing, finance, sales, approvals, dimensions, and other business processes can operate differently in Finance & Operations.Organizations therefore aren't simply teaching employees where familiar buttons moved. They may be redesigning how entire business processes operate.That organizational change is a major reason enterprise ERP implementations require significant time.

CLEAN THE DATA BEFORE MOVING IT
A technically perfect migration can still produce a bad result when the source data is poor.Duplicate vendors, unreconciled balances, forgotten customizations, outdated workflows, and undocumented fields can all become migration problems.Every customization should be evaluated: rebuild it, replace it with native F&O functionality, find an alternative application, or retire it completely.

NOT EVERYTHING SHOULD MOVE
A clean implementation does not require transferring every piece of the previous system.Legacy custom code may no longer make sense. Business Central reports often need to be rebuilt against F&O's different data model. Historical information can potentially remain available through archived or read-only systems rather than being loaded into the new production ERP.The objective should be a clean enterprise foundation—not recreating every historical workaround inside a more expensive platform.

BUSINESS CENTRAL CAN STILL BE THE RIGHT CHOICE
None of this means organizations should avoid Business Central.For the companies it was designed to serve, its simplicity, implementation speed, and lower complexity can make it the appropriate ERP.The important distinction is between growing in size and growing in organizational shape. Adding revenue, customers, and employees does not automatically create the same ERP requirements as adding countries, legal entities, acquisitions, and complex consolidation.

DESIGN FOR FUTURE CONSOLIDATION
Organizations that may eventually grow through acquisitions can prepare early.Design the chart of accounts and dimensions with future consolidation in mind. Establish consistent customer, vendor, product, and GL master data. Consider future Dataverse requirements. Most importantly, document customizations when they are created rather than attempting to reverse-engineer their purpose years later.The goal isn't to over-engineer Business Central. It's to avoid making a future transition unnecessarily difficult.

THE PHASED PATH TO FINANCE & OPERATIONS
A realistic transition happens in stages.First, stabilize and clean existing Business Central environments. Second, establish the required shared-data and integration architecture. Third, deliberately design consolidation and elimination logic. Fourth, treat the actual BC-to-F&O implementation as its own project with its own budget, testing, timeline, and parallel-run period.Skipping early phases rarely eliminates the work. It usually moves the problem to a later and more expensive stage.

THE KEY TAKEAWAY
Business Central does not simply “scale into” Finance & Operations.Moving between them means rebuilding on a different ERP foundation.If acquisitions, international expansion, multiple legal entities, or enterprise consolidation could become part of your future, start preparing before those requirements arrive.Audit your chart of accounts. Document your customizations. Understand your master data. And stop planning around an upgrade bridge that was never designed to exist.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

PowerPoint is one of the most widely used business applications in the world — but many professionals are only scratching the surface of what it can actually do.
In this episode of the M365 FM Podcast, Mirko Peters talks with Microsoft PowerPoint MVP Fiona Walsh about the PowerPoint features that experienced users still overlook, how organizations can build better corporate templates, and where Microsoft Copilot genuinely helps — and where it still has work to do.
Fiona brings more than 20 years of experience helping organizations improve presentations and presentation skills. Her central point is simple: many PowerPoint problems aren't caused by PowerPoint itself. They're caused by people using the same type of deck for completely different purposes. A presentation designed to be read as a PDF should not look the same as slides supporting a speaker on stage.
ㅤㅤ
POWERPOINT FEATURES YOU'RE PROBABLY NOT USING
Some of PowerPoint's most valuable capabilities aren't new at all. Fiona explains why even experienced users regularly miss features that have existed for years and how understanding the fundamentals can dramatically speed up everyday presentation work.
The conversation dives into alignment and distribution tools, grouping, the Selection Pane, object layers, and practical ways to understand complex slides created by someone else. Fiona explains why the Selection Pane in particular can become indispensable when dealing with layered objects, grouped elements, maps, diagrams, and complicated corporate slides.
ㅤㅤ
BUILDING CORPORATE POWERPOINT TEMPLATES THAT ACTUALLY WORK
A corporate template shouldn't simply enforce brand colors and logos. It should make it easier for employees to create good presentations.
Fiona discusses why the Slide Master and available layouts form the foundation of an effective corporate PowerPoint environment. Templates need enough flexibility for different presentation scenarios, including useful title-only layouts, blank layouts and strong image placeholders. Overly restrictive templates often force users to delete placeholders or work around the template instead of benefiting from it.
Good templates also become increasingly important as organizations adopt Copilot. Copilot relies heavily on the layouts available within the presentation template, meaning a poorly designed template can directly limit the quality of AI-generated slides.
ㅤㅤ
SMARTART WITHOUT THE OUTDATED LOOK
SmartArt has been part of PowerPoint for years, but it doesn't have to look dated.
Fiona explains how to keep SmartArt cleaner and more modern, including avoiding unnecessary 3D effects. The discussion covers newer SmartArt options such as timelines, Meet the Team layouts and text cards, as well as converting ordinary text into SmartArt.
One particularly useful workflow is converting SmartArt into grouped shapes. This gives users much greater control when creating organization charts and other custom diagrams while still benefiting from SmartArt during the initial design process.
ㅤㅤ
POWERPOINT SHORTCUTS THAT SAVE REAL TIME
You don't need to memorize dozens of keyboard shortcuts to become faster in PowerPoint.
Fiona highlights Ctrl+D for duplicating objects and slides, Ctrl+G for grouping content, and the often-overlooked Quick Access Toolbar. By placing frequently used commands such as alignment tools and the Selection Pane directly on the toolbar, users can dramatically reduce repetitive navigation through PowerPoint's menus.
ㅤㅤ
WHERE COPILOT IN POWERPOINT ACTUALLY HELPS
Copilot isn't only about asking AI to generate an entire presentation.
Fiona sees significant value in using Copilot before slide creation begins. Users can brainstorm verbally, perform a "brain dump," describe their audience and objectives, and ask Copilot to help structure the presentation.
It can also help develop stronger opening hooks, suggest endings and calls to action, anticipate questions from different audiences, develop analogies, and generate supporting imagery. This can make Copilot particularly useful as a presentation-thinking assistant rather than simply a slide-generation engine.
ㅤㅤ
WHERE COPILOT STILL STRUGGLES
Copilot continues to have difficulty understanding that different presentation formats require fundamentally different approaches.
A presentation intended for an executive meeting, a conference stage and a PDF handout shouldn't automatically use the same design philosophy. Fiona argues that Copilot still struggles with this context and often treats presentations as though one type of deck fits every scenario.
This is also why presentation designers aren't disappearing. AI can assist with creation, but people still need to understand the audience, distill ideas into clear messages and make appropriate design decisions.
ㅤㅤ
BECOMING A BETTER PRESENTER
Creating slides is only part of PowerPoint.
Fiona explores features inside Presenter View that many business users don't know exist, including quickly jumping between slides without showing the audience every intermediate slide. This can be especially valuable during Q&A sessions or when presenters need to adjust their presentation because they're running out of time.
The episode also covers PowerPoint's live subtitle capabilities and translation features, which can make presentations more accessible to multilingual audiences.
ㅤㅤ
REHEARSE TIMINGS AND PRESENTER COACH
PowerPoint can also help you practice your delivery.
Rehearse Timings allows presenters to understand exactly how much time they're spending on individual slides, while Presenter Coach can provide feedback on areas such as speaking pace, filler words, monotone delivery, reading directly from slides and inclusive language.
Fiona recommends practicing presentations out loud rather than simply rehearsing them mentally.
ㅤㅤ
ANIMATIONS, MORPH AND VISUAL STORYTELLING
Animations aren't inherently bad — unnecessary animations are.
Fiona recommends using subtle animation strategically to control when information appears and keep the audience focused on the point currently being discussed. Morph can also replace more complicated animation workflows and help progressively reveal information across slides.
For data storytelling, the same principle applies: visual design should direct attention. Rather than displaying every chart element with equal visual weight, presenters can emphasize the specific data point that matters to the story.
ㅤㅤ
POWERPOINT ISN'T DEAD
Despite recurring predictions that AI and newer presentation platforms will replace PowerPoint, Fiona doesn't see PowerPoint disappearing.
Large organizations remain deeply invested in Microsoft environments, and AI is more likely to change how people work with PowerPoint than eliminate the application entirely. The bigger opportunity is creating presentations that are genuinely fit for purpose and using AI to accelerate specific parts of the workflow.
ㅤㅤ
KEY TAKEAWAYS
PowerPoint mastery isn't about knowing every feature. It's about understanding the fundamentals that make everyday work faster and presentations clearer.
Start with the alignment tools. Learn the Selection Pane. Configure your Quick Access Toolbar. Understand how your corporate template actually works. And use Copilot as a thinking, preparation and storytelling assistant instead of expecting it to automatically produce the perfect presentation.
As Fiona's final recommendation puts it: go explore the Arrange tools and Selection Pane, then put the features you use most onto your Quick Access Toolbar.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

Microsoft Cloud PKI brings certificate-based authentication into the cloud—but what exactly does that mean, why would you need certificates, and can it really replace traditional on-premises PKI infrastructure?In this episode of Microsoft Knowledge Nuggets, Mirko Peters explains Microsoft Cloud PKI in plain English. We explore certificates, certificate authorities, Intune, SCEP, device authentication, secure Wi-Fi, VPN access, certificate renewal and revocation, and where Cloud PKI fits into a modern Microsoft environment.

WHY CERTIFICATES EXIST
Every time a device connects to a protected service, there is an identity question: should this device be trusted?Digital certificates provide a way to prove identity without repeatedly sharing passwords. A certificate contains identity information and a public key, while the corresponding private key remains protected on the device. This allows a laptop, phone, or user to prove possession of the certificate without exposing the underlying secret.

WHAT PKI ACTUALLY DOES
PKI stands for Public Key Infrastructure. Think of it as the badge office for your digital workplace.PKI creates certificates, delivers them to the appropriate users or devices, renews certificates before they expire, and revokes them when they should no longer be trusted.At the center is the Certificate Authority, or CA. A typical architecture includes a Root CA establishing trust and an Issuing CA handling the day-to-day issuance of certificates.

THE PROBLEM WITH TRADITIONAL PKI
Traditional Microsoft PKI commonly relies on Windows Server and Active Directory Certificate Services.Connecting modern Intune-managed devices to that infrastructure can require additional components such as certificate connectors, NDES servers, reverse proxies, firewall rules, backups, patching, monitoring, and specialist knowledge.For smaller IT teams, a relatively simple requirement such as certificate-based Wi-Fi can therefore become a substantial infrastructure project.

WHAT MICROSOFT CLOUD PKI IS
Microsoft Cloud PKI is Microsoft's managed Certificate Authority service inside Intune.Instead of operating the certificate infrastructure on local Windows Servers, organizations can use Microsoft-hosted Root and Issuing Certificate Authorities. Cloud PKI can issue certificates to Intune-managed users and devices, renew them, and revoke certificates that should no longer be trusted.ㅤ

INTUNE, ENTRA ID AND CLOUD PKI
The different Microsoft services each have a specific role.Microsoft Entra ID manages identity. Intune manages company devices, applications, configurations, and policies. Cloud PKI provides the certificate infrastructure that can issue trusted digital credentials to those managed devices.Together, they create a model where devices can receive certificates automatically without employees manually requesting or installing them.

HOW SCEP FITS INTO CLOUD PKI
SCEP stands for Simple Certificate Enrollment Protocol.It provides the request path through which a managed device can obtain a certificate. The device generates its private key locally and keeps it there. Cloud PKI receives the public information required to issue the certificate rather than receiving the device's private key.This allows certificate enrollment to happen automatically while keeping the device's most sensitive cryptographic secret protected.

WHAT HAPPENS WHEN A DEVICE NEEDS A CERTIFICAT
EIntune first provides the device with the certificates necessary to trust the organization's certificate chain.The device generates its private key locally and sends a certificate request through SCEP. Intune verifies that the request originates from an enrolled and managed device. When the checks succeed, the Issuing CA signs the certificate and it is delivered back to the device.For the employee, the entire process can happen invisibly in the background.

PASSWORDLESS WI-FI AND VPN ACCESS
Secure Wi-Fi is one of the clearest Cloud PKI use cases.Instead of giving every employee the same Wi-Fi password, each managed device can receive its own certificate. When connecting, the laptop presents the certificate and the network verifies whether it chains back to a trusted Certificate Authority.The same model can be used with compatible VPN services and internal applications that need to recognize managed company devices.ㅤ

CERTIFICATE RENEWAL AND REVOCATION
Certificates intentionally have expiration dates.Cloud PKI and Intune can begin renewing certificates before they expire, allowing devices to obtain replacement certificates in the background.If a laptop is lost, an employee leaves, or a certificate should otherwise stop being trusted, administrators can revoke it. Services checking certificate status can then reject that certificate even if the physical device still exists.

WHERE CLOUD PKI FITS BEST
Cloud PKI is particularly useful when managed company devices need to prove their identity before receiving access.Typical scenarios include certificate-based Wi-Fi, VPN access, and internal applications that should only accept managed devices.The model supports Intune-managed Windows, macOS, iOS, iPadOS, and Android devices where the relevant Intune certificate profiles are supported.ㅤ

WHAT CLOUD PKI DOES NOT REPLACE
Cloud PKI is not a universal replacement for every certificate requirement.Its focus is certificates for Intune-managed devices. It is not intended to replace every certificate used by web servers, VPN gateways, load balancers, unmanaged computers, isolated systems, or unsupported devices.The Wi-Fi controller, VPN gateway, or application also needs to trust the Root and Issuing CA chain used by Cloud PKI.

START WITH ONE USE CASE
Rather than beginning with a company-wide PKI transformation, choose one concrete problem.That could be eliminating a shared Wi-Fi password, improving certificate-based VPN access, or restricting an internal application to managed company laptops.Start with a small pilot group. Configure the trust chain, certificate profile, and corresponding Wi-Fi, VPN, or application policy together. Test enrollment, authentication, renewal, and certificate revocation before expanding deployment.

THE KNOWLEDGE NUGGET
Microsoft Cloud PKI is Microsoft's managed certificate service for Intune-managed devices.It does not replace every PKI workload, but it can significantly simplify certificate-based authentication for Wi-Fi, VPN, and application access by moving much of the traditional certificate infrastructure into Microsoft's cloud.The practical starting point is simple: identify one place where your organization still relies on a shared password for device access, then determine whether Intune and Cloud PKI can replace that shared secret with managed device certificates.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

Internal Developer Platforms promise faster development, less friction, and happier developers—but what exactly is an IDP, and how does it work behind the scenes?In this episode of Microsoft Knowledge Nuggets, Mirko Peters explains Internal Developer Platforms in plain English. We explore how platform engineering turns cloud infrastructure, security rules, automation, and developer tooling into reusable self-service experiences that help development teams build, deploy, and operate applications without starting from zero every time.

THE PROBLEM INTERNAL DEVELOPER PLATFORMS SOLVE
Launching even a simple application can involve repositories, Azure subscriptions, networking, identities, secrets, CI/CD pipelines, monitoring, permissions, and multiple teams. Instead of focusing on features, developers can spend significant time navigating tickets, documentation, portals, and infrastructure decisions.An IDP provides a self-service front door to approved software-building blocks, connecting developers with the automation, standards, tools, and policies already established by the organization.

GOLDEN PATHS
Golden paths are approved and repeatable routes for common development tasks. Rather than forcing every development team to design infrastructure from scratch, a golden path provides sensible defaults for repositories, CI/CD, Azure resources, identities, monitoring, security, and other standard requirements.Developers provide only the information that matters—such as the service name, owner, environment, runtime, and approved options—while the platform handles the underlying setup. Good golden paths also provide controlled escape routes for applications with unusual requirements.

THE SERVICE CATALOG
As organizations accumulate hundreds or thousands of applications and services, understanding what exists becomes increasingly difficult.A service catalog provides a central map of running software, including ownership, documentation, dependencies, source code, operational status, dashboards, and support information. It helps developers and operations teams quickly answer questions such as who owns a service, where its code lives, what it depends on, and where its monitoring can be found.

GUARDRAILS WITHOUT SLOWING DEVELOPERS DOWN
Self-service does not mean unrestricted access.Guardrails build organizational requirements directly into the platform. Microsoft Entra ID can control identity and access, Azure Policy can enforce resource standards, management groups can organize subscriptions, Azure Key Vault can protect secrets, managed identities can reduce password usage, and Microsoft Defender can help identify security risks.The objective is to automatically approve normal, safe workflows while directing unusual or risky requests through the appropriate review process.

WHAT HAPPENS WHEN YOU CLICK “CREATE SERVICE”
A developer may see only a simple button or form, but one request can trigger a substantial automation chain.The platform can create a repository, generate a standard project structure, configure CI/CD, provision Azure infrastructure, assign permissions, connect monitoring, and automatically create documentation and catalog entries.Instead of describing every technical step, developers describe the desired result and let automation create the required environment.

GITOPS, BICEP, TERRAFORM AND AUTOMATION
GitOps can store the desired configuration in Git, providing reviewable and traceable infrastructure changes.Technologies such as Bicep or Terraform can provision infrastructure, while Azure DevOps Pipelines or GitHub Actions can automate testing and deployment. Applications might run on Azure App Service, Azure Kubernetes Service, or other approved environments.These technologies can support an IDP, but none of them individually is the platform.

AN IDP IS MORE THAN A DEVELOPER PORTAL
One of the biggest misconceptions is that an Internal Developer Platform is simply a portal such as Backstage.The portal can provide the user interface, but the actual platform includes automation, standards, infrastructure, security policies, operational processes, and the people maintaining those capabilities.An IDP also does not replace DevOps engineers, architects, security teams, or cloud teams. Instead, it turns their expertise into reusable paths that development teams can consume repeatedly.

HOW TO START WITH PLATFORM ENGINEERING
Do not begin by trying to build an enormous platform.Identify one painful and frequently repeated developer workflow. Create one useful golden path around it. Automate the Azure infrastructure, identity, security, deployment, monitoring, and ownership requirements behind that request.Then measure whether waiting times, tickets, setup failures, and developer friction actually decrease.

THE KNOWLEDGE NUGGET
An Internal Developer Platform is an internal self-service system that helps teams build, release, and operate software safely.The essential building blocks are golden paths for common workflows, a service catalog for ownership and discoverability, automation for repeatable provisioning, guardrails for safe choices, identity for access control, and visibility into running services.Before building the portal, build the foundation underneath it.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

Why Power Platform Is Your Real Automation Layer — Not Custom Code
Every new automation request in Microsoft Dynamics 365 seems to become a development ticket. A new approval path, Teams notification, reminder, document-generation process, or integration enters a backlog while the business waits for an available developer.
In this episode of M365 FM, Mirko Peters challenges that traditional model and explains why Microsoft Power Platform should become the visible automation layer between Dynamics 365, Dataverse, people, decisions, and connected business systems.
This is not an argument against custom code. It is a practical framework for understanding where Power Automate, Power Apps, Power Fx, Dataverse, solutions, environment variables, security, and governance belong—and where professional development remains the correct architectural choice.
ㅤ
THE AUTOMATION ASSUMPTION IS BROKEN
Many Dynamics environments begin every process request with the same question: where should we write the code?
That question narrows the architecture before the team understands what changed in the business, which decision must be made, who needs to respond, which systems need information, and who owns the process after deployment.
Power Platform should sit between a Dynamics event and the surrounding business outcome. It can interpret signals, apply visible rules, coordinate human decisions, connect services, and record what happened. Custom code remains valuable, but it should not automatically own every process change.
ㅤ
THE OLD DYNAMICS CUSTOMIZATION MODEL
In the traditional model, every difference between the standard Dynamics application and the business process becomes another customization.
A developer creates a Dataverse plug-in, attaches JavaScript to a form, builds a custom workflow activity, adds a scheduled job, or creates another integration service. Each individual feature may work correctly, but the complete process gradually becomes distributed across assemblies, scripts, workflows, APIs, configuration values, and specialist knowledge.
The process owner understands the policy but cannot inspect the technical behavior. The developer understands the implementation but may not own the business decision. Support becomes responsible when something fails, even though it may not know which component triggered the outcome.
This creates delivery control without creating true process ownership.
ㅤ
THE HIDDEN COST OF CUSTOM AUTOMATION
The initial development cost is visible because it appears in estimates, project budgets, and delivery reports. The long-term operating cost is distributed across support tickets, testing cycles, incident investigation, documentation updates, platform upgrades, and the time required to locate old business rules.
A small policy change can become a multi-day development task when a threshold is hidden inside code. Someone must find the relevant implementation, identify the production version, change it, test related behavior, deploy it correctly, and confirm that nothing else relies on the same value.
The business may conclude that Dynamics is slow to change. In reality, the automation model is creating the delay.
ㅤ
WHY DOCUMENTATION AND SUPPORT OFTEN FAIL
Documentation usually describes the process as it existed when the solution launched. The business then changes, developers update the implementation, and the original documents slowly become unreliable.
Eventually, the code describes the current system behavior while the documentation describes an older version of the business. Neither gives process owners a clear and trustworthy answer.
Support teams feel this problem when a record changes unexpectedly or a notification fails. They can see that something happened, but they may not know whether the cause was a plug-in, JavaScript, a classic workflow, Power Automate, or an external integration.
The real escalation path becomes finding the person who remembers the automation. When that person leaves, the organization loses more than technical capacity—it loses the map.
ㅤ
CUSTOM CODE IS NOT THE ENEMY
Custom code still belongs in Dynamics and Power Platform architecture. Some requirements must execute inside the Dataverse transaction before a record is accepted.
A plug-in may be the correct choice when a rule must prevent invalid data from being saved, perform a controlled calculation, support a performance-sensitive operation, or guarantee consistent server-side behavior regardless of how the data enters Dataverse.
Code also remains appropriate for reusable software components, specialist integrations, PCF controls, custom connectors, products, and technical services with their own lifecycle and interface contracts.
The important principle is to keep the code boundary narrow. A plug-in should validate one rule, calculate one result, or perform one controlled operation. It should not quietly become responsible for approvals, reminders, documents, escalations, and several external systems.
Code earns its place through architectural necessity and engineering discipline—not through habit.
ㅤ
THE DIFFERENCE BETWEEN VALIDATION AND ORCHESTRATION
Some rules define what must be true before a record can be saved. These belong close to the Dataverse transaction.
Other rules determine what should happen after the record already meets that standard. These belong in the automation layer.
For example, mandatory legal data may need to block a contract from entering an active state. That is transactional validation. Requesting a legal review, notifying an approver, waiting for a response, and updating the contract afterward are orchestration.
Separating these responsibilities prevents users from waiting while unnecessary background work executes synchronously. It also prevents invalid data from entering the system while a downstream automation attempts to correct it later.
Enforce what must be true now. Orchestrate what needs to happen next.
ㅤ
POWER PLATFORM AS THE REASONING LAYER
An event only tells the system that something changed. It does not automatically explain why work should begin or what should happen next.
An opportunity reaches a stage. A case receives a priority. A customer changes owner. The automation layer must determine whether the business conditions are satisfied, which policy applies, who should respond, and which exception route should be used.
Power Automate conditions, approvals, switches, Dataverse data, and Power Fx formulas can make this reasoning visible. Process owners do not need to become developers, but they should be able to understand and validate the policy they own.
A decision about sales approval may depend on opportunity value, discount, region, account category, payment terms, ownership, or unresolved risk. These conditions should form a clear sequence rather than disappearing into one hidden block of technical logic.
ㅤ
A SALES APPROVAL WITHOUT A PLUGIN
Consider an opportunity that reaches a commercial threshold. The process may need to confirm the current stage, validate required information, determine the applicable approval route, request a decision, record the outcome in Dataverse, notify the seller, and handle delays or rejection.
This process crosses data, policy, people, time, and communication channels. It is orchestration rather than transactional validation.
Power Automate can begin from the Dataverse record, evaluate the relevant business context, route approval to the correct person, send information through Teams or Outlook, wait for a response, update the opportunity, and preserve a visible execution history.
The business can inspect where the process stopped and why. Support can review the run history instead of searching through an assembly. Policy changes can be delivered through a controlled Power Platform lifecycle without turning every adjustment into a new custom-development project.
ㅤ
SPEED MEANS TIME TO CHANGE
Technical teams often define speed as execution time in milliseconds. Business teams experience speed differently. For them, speed includes the time required to understand a request, implement a change, test it, release it, and support it afterward.
A custom plug-in may execute faster than a cloud flow while taking weeks longer to modify and deploy. A flow may take several seconds to complete while allowing the organization to change a business rule safely within days.
The correct architecture depends on the requirement. Transactional and high-volume operations may need code-level performance. Human approvals and cross-system business processes usually care more about visibility, adaptability, and time to change.
ㅤ
AUTOMATION NEEDS ORGANIZATIONAL OWNERSHIP
A personal flow can become business-critical without anyone deliberately making that decision. The creator changes role, leaves the company, loses a license, or has a connection expire, and an important process suddenly has no reliable owner.
Production automation should not depend on a single employee’s personal identity. It needs an ownership model aligned with the business process, data sensitivity, operating team, and support responsibility.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.