The connector only sees what the person sees

The first worry any operations or IT lead has is the obvious one: are we handing an AI tool the keys to every company file? With this kind of connector, no. Each user authenticates with their own account, and the assistant can only reach the files that user already has access to. Connect it under an account with a narrow view, and you get a narrow view. Connect your own account, and you get everything you can normally see, nothing more.

That's the model you want. It means access control stays where it already lives: in your file permissions. You're not building a second, parallel set of rules inside the AI tool. If someone shouldn't see a folder in Google Drive, the connector won't surface it for them either.

HOW SCOPE WORKS

The connector inherits the connected user's permissions. It can see what that account can see, and nothing more. Test it against a real account and you'll quickly find out what that account actually has access to.

Read-only versus write, and the approval prompts

When you set up the connector, you decide how much it can do. Reading and searching files is one level. Creating, editing, or deleting files is a stronger permission you grant explicitly. During testing, the tool prompts you each time it wants to reach into Drive, with options along the lines of allow once or always allow.

A reasonable posture: leave the read-only actions on always allow so the assistant can search without nagging, and keep the write actions (create, edit, delete) behind an approval prompt. That way nothing gets changed in your Drive without a human clicking yes. The point of the per-action prompts isn't friction for its own sake, it's a checkpoint on the operations that can alter your files.

Shared projects changed, and it matters for team dashboards

One thing to plan around: direct Google Drive integration is currently available for private projects and standard chats, but has been restricted for shared projects. So if someone on your team builds work inside Claude and wants to share that project with colleagues, the direct-to-Drive connection may not carry over the way it once did.

That trips up exactly the use case teams get excited about, where one person builds something off shared data and hands it around. It's worth confirming the current behavior before you promise the team a workflow that depends on shared projects reaching Drive. Vendor rules on this shift, so treat it as something to check rather than assume.

The gotcha that wasted most of the call: too many accounts

Here's the one that's easy to miss. The connector kept failing to find files that clearly existed and that the connected account could see. Everything looked configured correctly. The actual cause was that the browser was signed into six different Google accounts at once, and the connector was getting crossed up about which identity it was using.

The fix was to open an incognito window, sign in cleanly with just the intended account, and connect from there. Files showed up immediately. It wasn't a permissions problem or a setting deep in the admin console, it was account cross-pollination in the browser.

IF SEARCHES COME BACK EMPTY

Before you dig through connector settings, try an incognito or private window signed into only the account you want to connect. Being logged into several Google accounts at once can confuse the connector about which identity it's acting as.

Rolling it out to a team

Two practical takeaways for a broader rollout. First, each staff member has to connect their own account, so the connection is per user, not one-and-done for the whole company. Second, budget for the account-confusion issue, because plenty of people live signed into multiple Google accounts and will hit the same wall. Documenting the incognito step up front saves a lot of head-scratching.

If you're thinking through how to bring an AI assistant into your file storage safely, whether it's Google Drive or a Microsoft 365 tenant, we're glad to help you sort out the scoping and the rollout so access stays tied to what people are already allowed to see. Happy to talk it through.

Two ways a Mac lands in Intune

Apple Business Manager (ABM) is Apple's portal for assigning devices your company buys directly to your organization. When it's wired up to your Microsoft tenant, a brand new Mac enrolls itself the first time the user signs in with company credentials. No one has to hunt for an app or follow a checklist. That's the clean path, and it's the one you want for anything ordered going forward.

The catch is that the automated ABM path assumes the device can be set up fresh. For a Mac someone is already using every day, you usually can't just reset it on a Tuesday morning. That's where direct enrollment comes in. The user installs the Company Portal app, signs in, and follows the prompts to enroll the machine in place, no wipe required.

What direct enrollment gets you (and what it doesn't yet)

Even the interim direct-enrollment path gives you meaningful control. Once a Mac is enrolled, you can push applications and apply security policies to it. What you don't get right away is the full lifecycle control, including remote wipe, that comes once devices flow through Apple Business Manager. So it's worth being clear with your team that this is a stepping stone: you get security and policy today, and the tidier automated setup follows as machines cycle through.

WHY NOT WIPE NOW

Wiping a Mac someone is actively working on means downtime and migration risk. Direct enrollment lets you secure the device immediately, then move it to the automated Apple Business Manager path when it's replaced or reset.

A rough edge worth knowing about

During the walkthrough, the Company Portal app installed fine but didn't show up in Applications for close to ten minutes. macOS runs a verification step after install, and the app can lag behind before it appears. If you're rolling this out to a team, that gap causes a lot of "I don't see it" messages. The fix is simple once you expect it: search Finder for Company Portal, or just wait a few minutes.

Because of that, the better approach for a fleet is to package the Company Portal app and deploy it silently ahead of time, so it's already sitting on every Mac before anyone needs it. Then your instructions to the team are just "open Company Portal and sign in" instead of "go download this and wait."

Don't enforce everything on day one

One more decision that came up: whether to immediately require the company-managed Apple ID on every device. We held off. When people are still cutting over and migrating their data, enforcing that policy too early creates lockouts and support tickets. You can enroll everyone first, then turn on enforcement once the team has had time to move. Sequencing the enforcement after the enrollment keeps the rollout calm.

If you're staring at a mixed bag of Macs

Most small teams don't have the luxury of a fresh fleet. You've got some new machines, some three-year-old ones, and a couple of outliers with a person's name attached to every quirk. A workable plan enrolls what you can today, automates the new arrivals through Apple Business Manager, and schedules the older devices to move over as they get replaced. If you're weighing how to bring your Macs under management without disrupting the people using them, we're happy to talk through the sequencing.

The reason: the company had a product data management (PDM) implementation kicking off first, and the ERP's part-number master and bills of materials all need to come out of that PDM. His words were direct: he didn't want bad data on day one. That's the right instinct, and it's worth explaining why.

What a PDM owns and why the ERP waits on it

In an engineer-to-order shop, the engineering system (in this case a SOLIDWORKS-based PDM) is where part numbers get created, drawings get revised, and revisions get released. That's the source of truth for what a part is and what goes into a product. The ERP is where you buy, build, cost, and ship those parts. If the two disagree on part numbers or BOM structure, your ERP inherits the disagreement.

He described the current pain clearly: engineers change something, there's no official revision release the whole company sees, purchasing orders against a stale spreadsheet, and duplicate part numbers pile up because a couple of people can edit that spreadsheet freely. If you stand up an ERP on top of that mess, you don't fix it, you just move it into a more expensive system.

THE RULE OF THUMB

The system that creates and releases part numbers should be stable before the system that transacts against them goes live. Get the part master and BOMs clean in the PDM first, then let the ERP pull from a known-good source.

Why not run both at once

There's a technical answer and a human answer. Technically, the ERP's item setup and BOMs depend on data the PDM hasn't finished producing, so running them in parallel means building your ERP on a moving target. The human answer is just as important. He put it plainly: he didn't want to run two implementations at the same time, because people can only absorb so much change.

We agree. We're not a rip-it-all-out-at-once shop. An ERP go-live already asks for a real chunk of your team's time, not just ours. Stacking a second system change on top of that is how go-lives go sideways and how the team quietly decides the new tools aren't worth the trouble.

A sequence that gives you room

Here's how this kind of timeline can lay out without anyone feeling rushed:

1. Run the ERP evaluation now (platform fit and partner fit), while the PDM implementation is getting off the ground. Evaluating costs you nothing but time and can proceed in parallel.
2. Land on a platform, scope, and budget, then let that decision sit rather than kicking off immediately.
3. Let the PDM finish and stabilize so the part master and BOMs are clean and released.
4. Kick off the ERP implementation once the PDM is the source of truth.

In his case the PDM is expected to wrap around year-end or early the following quarter, and Q4 is the company's busiest stretch. That actually leaves plenty of runway: evaluate carefully now, decide, wait for the PDM, then implement in a quieter window with everything wrapped up well before the busy season. Evaluating early doesn't force an early start. It just means you're ready to move the moment the data is.

The other thing that has to come with the ERP

He named a second problem worth flagging: too many hats, not enough heads, and nobody sure whose job ends where. Things get ordered twice, and the owner never sees a purchase get approved. A foundation of clean data solves half of that. Approval workflows solve the other half, routing the transactions that need a second set of eyes to the right person automatically. Business Central handles that natively, and it's one of the first things worth turning on once the data underneath it is trustworthy.

If you're staring at the same sequencing question

If you're bringing in your first ERP and there's an engineering or PDM system feeding it, the order of operations is a real decision, not a detail. We're happy to talk through how your part master, BOMs, and go-live timing should line up, and where an ERP evaluation can run in parallel without committing you to anything. No rush on our end.

Where the feature lives

In Dynamics 365 Sales, the ability to track email opens and link clicks with tracking pixels and rewritten links is a feature of the higher licensing tier (Enterprise), not the more affordable Professional tier. So the moment engagement analytics becomes a requirement, you're looking at a per-user jump. In round numbers, that's a move from roughly $65 per user per month to roughly $105, close to double, so the decision deserves a second look rather than a reflex purchase.

How the tracking works, and why it backfires

Open tracking usually relies on a tiny invisible image (a tracking pixel) that loads when the recipient opens the message. Click tracking works by rewriting your links so they route through a tracking server before landing on the real destination. Both leave fingerprints in the message.

Modern spam filters are tuned to notice exactly those fingerprints. A pixel from a tracking domain and rewritten links are common markers filters weigh when deciding whether a message is legitimate or bulk marketing. The result is that the same feature meant to give you richer reporting can nudge more of your mail into the junk folder.

You get richer reporting on fewer emails that actually reach the inbox.

For a company sending investor updates or a small volume of high-value messages, that's the wrong trade. Knowing that 40% of your recipients opened an email is cold comfort if a chunk of the send never reached the inbox in the first place.

When the Enterprise tier is still worth it

Email tracking isn't the only difference between the tiers. The higher tier also raises ceilings on things like custom fields, custom entities, and dashboards, so a business with heavy customization needs may land there for reasons that have nothing to do with email. A couple of things worth checking before you decide:

• Are you likely to hit customization limits (custom tables, fields, or dashboards) that the Professional tier caps?
• Do you actually need embedded engagement analytics, or would send and delivery confirmation be enough?
• Is your email volume high enough that deliverability risk outweighs the reporting benefit?

GOOD NEWS ON UPGRADES

You don't have to guess forever. It's a tenant-wide choice (everyone is on the same tier, not a mix), but you can upgrade from Professional to Enterprise later if the need becomes real. Starting on Professional and moving up is far easier than the reverse.

The plain read

For most small teams whose main use of the CRM is tracking relationships and sending a modest volume of important emails, the Professional tier is the better starting point. You keep your deliverability clean, you spend less per seat, and the door to Enterprise stays open if a genuine customization or analytics need shows up down the road.

If you're sizing up Dynamics 365 and trying to figure out which tier fits how your team really sends and reports, we're happy to talk it through and pressure-test whether the extra features earn their keep for you.

If you are running a legacy on-premises ERP or a line-of-business system that sits on SQL Server and you have been weighing a move to Business Central, this is the part of the project that has usually been hand-built. It affects the cost and risk shape of that move more than the day-to-day experience of anyone already in Business Central.

What this changes about a legacy migration

Moving off a SQL-based system that Microsoft has no first-party path for has meant custom scripts: someone writes extraction and mapping logic, runs it, finds the gaps, runs it again, and the knowledge lives in that person's head and a folder of files. It works, but every migration starts closer to zero than it should, and the admin experience differs from project to project.

The alternative is building the migration engine once as an extension, then installing and reusing it, with the same wizard and the same admin experience as the supported migration types. Microsoft's stated goals for it are repeatability, fewer custom scripts, and lower risk.

WHAT THE ENTRY DOES NOT SAY

The release plan does not spell out licensing requirements, which specific source systems have published engines, how much developer effort a given engine takes, or how existing custom scripts might be reused. Those details are not stated, so we would not plan around assumptions about them.

What to look at now

Nothing here is urgent on its own. It does change what is worth doing early if a platform move is anywhere on your two-year horizon.

• Get clear on what has to come across: open balances and master data, or transaction history too, and how many years of it. This drives migration scope regardless of the tooling.
• Confirm whether your current system's data really sits in SQL and whether you or your software partner can get read access to it. The tooling is specific about SQL-based sources.
• Note how much of your data lives outside the ERP in spreadsheets and side databases. That work does not get easier because the ERP migration path did.
• Write down the reports and reconciliations you would use to prove a migration landed correctly. Repeatable tooling is worth more when you can test each run quickly.

How we would think about timing

If you have a business reason to move now, this is one fewer unknown in the scoping conversation rather than a reason to wait for anything. The useful question during scoping is whether a Generic Custom engine already exists for your source system, or whether building one is cheaper than the scripts you would otherwise write.

The other thing worth checking is whether engines exist for the systems common in your industry. Reuse only pays off when someone has already built for your source, so that is a question to ask your partner directly rather than assume either way.

If a platform move is on your list

Most of the value in a migration comes from decisions made before anyone touches data: what history you keep, which processes you rebuild rather than reproduce, and who owns the sign-off. Tooling that lowers the cost of the mechanical part makes those decisions more, not less, worth your time.

If you are mapping out a move off a legacy SQL-based system and want a second read on scope and sequence, we're happy to talk it through whenever it's useful.

What works on every plan now

The release plan entry names three capabilities as available on all Shopify plans:

• Company sync: import Shopify B2B companies and company locations, and map them to customers in Business Central.
• B2B order processing: when a B2B order arrives, the connector identifies the company and resolves the correct bill-to and ship-to customer based on the company location.
• Market catalogs: assign catalogs to B2B markets for price synchronization.

Where the plans still differ

This is the part to read before you touch your Shopify subscription. The entry is specific about two limits that keep Plus ahead:

• Market catalog assignments are capped at three active assignments on Basic, Grow, and Advanced. Plus is unlimited.
• Direct company catalogs, meaning catalogs assigned to a specific company or company location rather than to a market, require Advanced or Plus.

So if your wholesale pricing is organized by market and you need only a few catalogs, the lower plans now cover you. If you price per customer, or you run more than three market catalogs, the capability you depend on is still plan-gated.

Why the bill-to and ship-to detail matters

For most wholesalers, this is the part that decides whether the integration saves real time. A B2B buyer often orders on behalf of one location while the invoice goes to head office. If the connector resolves that correctly on arrival, orders land in Business Central ready to process. If it does not, someone in accounting is retyping addresses and account codes, and the online channel stops feeling like a channel and starts feeling like a second inbox.

That is worth testing with your own account structures rather than assuming. Companies with many locations, buyers who order across locations, and customers who exist twice in your customer list for historical reasons are the cases that expose gaps.

NOT STATED IN THE ENTRY

The entry does not say which Business Central versions or connector updates are required, and it does not describe pricing on either the Microsoft or Shopify side. Confirm the version requirement against your environment before you schedule anything.

What to look at now

There is a real decision here. If you are paying for Shopify Plus mainly to get B2B features, this is a reason to revisit that at your next renewal conversation, but count your market catalogs and check whether you assign catalogs per company first. Plus also covers more than B2B, and dropping a plan to save on one line item can cost you elsewhere.

If you have been running wholesale orders by email, phone, or a shared spreadsheet because Plus was out of reach, the groundwork is the same as it ever was, and none of it depends on Shopify:

1. Clean up your customer list in Business Central, especially duplicates and inactive accounts that a sync would pull forward.
2. Decide which system owns the customer master record, and stick to that answer.
3. Write down your wholesale payment terms and pricing rules as they exist today, including the exceptions someone keeps in their head.
4. Run a test with two or three real customers, including at least one with multiple ship-to locations.

If you want to think it through

Wholesale and direct-to-consumer running side by side in one system is a good goal, and the path there depends a lot on how your customer records and terms are set up today. If you would like to walk through your current setup and what this changes for you, we are happy to talk it through whenever it is useful.

The release plan entry describes the additions as an expansion of the standard worldwide solution. It names logistics flows that manage subcontractor transfers of raw materials and components, with warehouse handling and item tracking; flexible pricing that takes the work center, item, dates, and quantity into account; finished goods receipts with item tracking and warehouse handling from purchase orders; logistics flows that manage subcontractor transfers of finished goods; and usability and transparency changes in the production process pages.

Why this matters if you outsource production steps

Manufacturers who outsource a routing operation have usually done one of three things in Business Central: a purchase order plus manual adjustments, a workaround built on transfer orders and negative adjustments, or an add-on from an independent software provider that handles subcontracting properly. Each of those carries a cost, whether that's month-end cleanup time, inventory that sits in a place your system doesn't recognize, or an annual license and upgrade dependency.

A native path changes the math on that. It doesn't automatically make the add-on the wrong choice, and we'd be careful about assuming a first release matches a mature add-on feature for feature. But the question is open again, and now it can be answered by testing rather than by reading a plan.

What the entry does not settle

Being clear about the gaps is more useful than filling them in with guesses:

• Licensing is not stated. The entry says nothing about whether these capabilities sit in Essentials or Premium, so confirm that against your own license before you plan around it.
• The entry lists the capability areas without describing how each behaves in detail, so whether it fits your routing steps is a question for a sandbox rather than a reasonable assumption.
• If you run the Italian localization, there is a migration in here for you. The entry notes that Italy's existing local subcontracting functionality is deprecated in favor of this worldwide solution, that upgrade logic is provided, and that you choose when to start the transition. Treat that as its own small project, not a side effect of an update.

What to do now

1. Write down how your outsourced operations work today: what leaves the building, what comes back, who owns the inventory in between, and how the cost lands on the finished item.
2. Run one real routing step through the native flow in a sandbox, end to end, including the receipt and the resulting cost on the finished item. That is the only way to see whether the fit is close enough.
3. If you're on an add-on for this, check when your renewal falls and what an exit would look like. Knowing that before the conversation beats discovering it during one.
4. If you're using manual workarounds, note where they break. Those breakages are your test list.
5. Check what version your environment is on. A capability released in a wave only reaches you if you're taking updates on a normal cadence.

A NOTE ON ROLLOUT

General availability is when Microsoft releases a capability, not when it appears in your environment. What you can see depends on your version and your update schedule, so check where you are before you plan a test.

The decision underneath this

For most companies we work with, the real question isn't whether the native feature exists. It's whether your outsourced steps are visible in your numbers today. If a batch sits at an outside shop for three weeks and your system shows it as consumed, or shows nothing at all, your inventory value and your job costing are both carrying an estimate. The native capabilities are one way to close that. A well-fitted add-on is another. Tighter process discipline sometimes gets you most of the way there without either.

If outsourced production is part of how you build things, we're happy to walk through your current flow and what these capabilities would change for it. Reach out whenever it's useful to talk it through.

It is a fair question to ask what the same requirements look like without a second administrative ecosystem. This is the version of that answer we would give before knowing anything about your fleet.

Start from the requirements, not the platform

The comparison gets muddy when it starts as Google versus Microsoft. It gets clear when you write down what has to be true and then ask each design to satisfy it. For most companies handling regulated data, the list is close to this:

• Every laptop runs current, monitored endpoint protection, and someone is accountable for the alerts.
• Disks are encrypted, and you can prove it for a specific machine on a specific date.
• A lost or stolen device can be locked or wiped from a console.
• Operating systems, browsers, and third-party applications patch on a schedule you set.
• Access to company data depends on who the person is and what device they are on.
• Sensitive data is prevented from leaving the places it belongs, and retained for as long as your policy says.
• A new laptop reaches a working, compliant state without a technician spending half a day on it.
• Joiners, movers, and leavers are handled in one place, and closing an account closes everything.

Both architectures can be measured against that list. Neither satisfies all of it out of the box, including the Microsoft one.

What Google Workspace Enterprise already gives you

More than most teams have switched on. Worth an inventory before buying anything:

• Identity and single sign-on (SSO). Google Workspace can be the identity provider for your other applications (SSO overview), with two-step verification, passkeys, and security keys enforced by policy. Google Credential Provider for Windows extends that to the Windows sign-in itself, and Google Cloud Directory Sync connects an existing on-premises Active Directory.
• Context-Aware Access. Available in Enterprise Standard and above, this gates access to Google services on signals like device state, encryption status, IP address, and geography. It is the control that lets you say "company data only from a managed device."
• Data loss prevention (DLP). Rules for Drive, Gmail, and Chat that block or warn on patterns you define, and they can be combined with Context-Aware Access conditions.
• Endpoint management. Mobile devices enroll with basic or advanced management. Windows devices enroll too, from the same Admin console, which gives you inventory, remote wipe, update settings, and BitLocker configuration (what the Windows settings cover, and the FAQ on their limits).
• Google Vault. Retention and eDiscovery, which is the piece most compliance frameworks ask about first.
• A signed business associate agreement (BAA). Google will sign one covering its core services, accepted from the Admin console. That covers Google's side of the Health Insurance Portability and Accountability Act (HIPAA) obligations, not yours.
• Chrome Enterprise. Browser management is free at the core tier. Chrome Enterprise Premium adds browser-level data protection, threat protection, and access controls, licensed separately.

If your team has not walked through those settings, that alone is a project, and it is one that pays for itself whichever direction you go afterward.

What the third-party layer looks like

Here is the part that usually stays vague. In the Microsoft design, three products do the heavy lifting: Entra ID for identity and Conditional Access, Intune with Windows Autopilot for device management and provisioning, and Defender for Business for endpoint protection. Buy them separately or take Microsoft 365 Business Premium, which bundles all three with the Office apps.

A Google-native design covers the same ground with Google plus a small number of independent products. Named plainly, so you can price it and compare:

Three things stand out when it is laid out this way.

The first is that the Google-native column is a real, buildable architecture. Every line has a mature product behind it, most of them cloud-managed, and none of them require a Microsoft tenant.

The second is that it is more products, not fewer. The Microsoft design consolidates identity, management, and endpoint protection into one license and one console at the cost of introducing a second ecosystem. The Google-native design keeps one ecosystem for productivity at the cost of assembling three or four security and management products around it. Whichever way you go, "one pane of glass" is a slogan rather than a deliverable.

The third is cost, and it runs the opposite way from what most people assume. The Microsoft layer lands at roughly $17 to $22 per user per month: Entra ID, Intune, and Defender for Business bought a la carte at the low end, Microsoft 365 Business Premium at the high end with the Office apps included. The Google-native column is priced product by product, each one per user or per endpoint, and any combination that covers the same ground comes out well above that band. Both layers sit on top of what you already pay Google, so the comparison worth running is layer against layer, and the Google-native one is very unlikely to be the cheaper of the two.

Where co-managed and Phase 0 engagements can help

Companies hesitate at that table less because of the products themselves and more because of what sits behind them: selecting them, negotiating them, deploying them, and then owning the operational load of four consoles with a small internal team.

That work is what a co-managed arrangement is for. We bring the third-party stack already selected, licensed, deployed, and monitored, tuned across the environments we run it in rather than assembled from scratch for yours. Your team keeps the Google Admin console and the relationship with your users. We run the endpoint protection, the patch pipeline, the device enrollment, and the alert queue, and we are the ones who take the call when a machine is lost on a Sunday.

That model applies to either architecture. If the Microsoft layer turns out to be the right answer for you, co-managed looks the same, just with Intune and Defender in place of the products above. The point of it is that the number of consoles becomes our problem instead of yours.

If you are not ready to hand anything over, there is a smaller first step. A Phase 0 assessment inventories what you already own, who administers it, what it costs to run, and where the gaps sit, and it ends in a roadmap rather than a deployment. It is a scoped engagement with a defined output, and you can take that roadmap and execute it yourself. Companies weighing two architectures with an incomplete picture of their own environment usually get more out of that than out of another round of comparison.

The consoles do not disappear either way

"One ecosystem" is the strongest argument for staying Google-native, and the count is worth doing on both sides. A Google-native design with a separate endpoint protection product and a separate management product is also more than one console, more than one support contract, and more than one place a problem could be. You end up with second and third tools on both paths. What separates them is which ones, who administers them, and how well they are connected.

The questions that decide it

We would not pick a direction for you from a blog post. These are the inputs that move the answer, and they are specific to your environment:

1. What is the fleet? Make, model, Windows edition, and whether there is a Trusted Platform Module (TPM) chip. Machines bought through consumer channels often run Windows Home, which cannot join either management story without an upgrade.
2. Who is running this in a year? Both designs need an owner, whether that is your team, ours, or a split. The right answer often follows the skills already in place rather than the feature matrix.
3. What has to be provable, and to whom? Auditors ask for evidence, not architecture. Whichever design produces the report you will be asked for, with the least manual assembly, has a real advantage.
4. What happens to the on-premises pieces? An existing Active Directory, a virtual private network, or a file server changes the shape of both options.
5. What are you likely to add next? A design that is right at 40 people can be awkward at 400, and the reverse is also true.

Where this lands

A Google-native path is a legitimate answer, not a compromise, and for some companies it is the better one. It is also not free of second tools, and the Microsoft path is not the only route to zero-touch provisioning and managed endpoint protection. What separates the two, for your company, is a handful of facts about your fleet, your team, and your obligations.

If you are weighing this, bring us the hardware inventory and the requirements list. We will map both designs against it and tell you what each one costs you in operational load, not only in licenses.

The answer is more interesting than a feature list, because these five integrations sit at different points on the effort curve. One is close to automatic on a cloud tenant. Three need an administrator to install something. One needs a licensing conversation. And the scenario people most want to see, a purchase approval landing in a Teams chat, needs a Power Automate flow rather than a checkbox. Knowing which is which before you commit to a go-live date is worth more than knowing the feature exists.

Teams: records as cards inside a conversation

The Business Central app for Teams comes from the Teams marketplace. Once it's installed, pasting a link to any Business Central record into a chat expands it into a compact interactive card. From that card, people can open more detail, edit data, and take action without leaving Teams.

There are three other pieces worth knowing. You can look up customers, vendors, and other contacts from the Teams command box, including their interaction history and related documents. You can push the other direction with the Share to Teams action on most Business Central list and detail pages, which sends a message and a link to a person, group, or channel. And you can pin a Business Central list or card page as a tab in a channel or chat, so a shared view lives where the team already works.

The prerequisite is straightforward and easy to miss when you're counting seats: every person who uses the Teams app needs a Business Central online user account. The card is not a read-only preview for unlicensed staff.

Approvals in Teams: the part that needs a flow

This is where demos and reality most often drift apart, so here is the mechanism.

Business Central has a built-in approval workflow engine. You set up approvers and amount limits on the Approval User Setup page, and a purchase document over a threshold you define routes to the right person. Microsoft's documentation is direct about how that person hears about it: the default version of Business Central supports notifications in email or as internal notes. Teams is not on that list.

Getting an approval into Teams is a Power Automate job. From a card or document page in Business Central, Automate > Create approval flow starts you on a template, and the Business Central connector carries dedicated triggers for exactly this: purchase document, sales document, vendor, customer, item, and general journal batch or line approval requests. Approvers respond from an Outlook email, a Teams adaptive card, or the Power Automate action center. That has been generally available since April 2023, and it's a well-trodden path rather than custom development.

Two workflow systems, one list

Business Central's native approval workflows and Power Automate approval flows are separate systems, though any approval workflow template you build in Power Automate is added to the workflow list inside Business Central. Deciding which engine owns which approval is a design decision. Running the same approval in both is how you end up with two notifications and an argument about which one counts.

The cost question usually follows. Business Central includes a Power Automate use right for flows that work with your Business Central data, so an approval flow like this doesn't start with a separate purchase.

SharePoint and OneDrive: mostly connected, partly switched off

For Business Central online, Microsoft has already created the connection to OneDrive. The only requirement on the user side is that the person has opened OneDrive at least once. On-premises deployments need an administrator to configure it.

With that connection in place, most pages where files appear (the Report Inbox, and attachments on records) gain two actions. Open in OneDrive copies the file to a Business Central folder in your OneDrive and opens it. Share copies it to your OneDrive and shares it with other people, which is where the co-editing story starts: once a document is in OneDrive, Word and Excel behave the way your team expects.

Here's the nuance that catches people. A second set of behaviors, having Open in Excel, Edit in Excel, and report output automatically save to OneDrive and open in the browser instead of downloading to a device, is not on by default. An administrator turns it on through the OneDrive Setup assisted setup guide. If you demo Business Central on a tenant where someone already ran that guide and then go live on one where nobody did, the file experience will feel different, and it will look like a bug rather than a setting.

Outlook: two add-ins, and one environment each

The Business Central add-in for Outlook is really two smaller add-ins, and you can deploy either or both.

Contact insights surfaces Business Central customer and vendor information inside emails and calendar appointments, and lets someone create and send a business document such as a quote or an invoice to that contact without switching apps. Document view watches for a business document number in an email body and turns it into a direct in-line link to that document in Business Central, which is the small thing that quietly saves an accounting team a dozen lookups a day.

An administrator with the Exchange Administrator role deploys both through Centralized Deployment in the Microsoft 365 admin center, using manifest files that Business Central generates for you in an assisted setup guide. Individual users can install for themselves if that hasn't happened.

Two practical notes. The add-in is tied to a single Business Central environment; the environment name is written into the manifest at install time, so anyone who works across a production and a sandbox environment installs it again to switch. And after a successful deployment it can take up to 24 hours before users see the add-in, plus an Outlook restart. Build that into your go-live week rather than discovering it on the morning of.

Excel: viewing and publishing back are different features

Both live under the Share icon on list pages, and the distinction between them matters more than the names suggest.

Open in Excel exports what's on the page, respecting your filters, and it's a one-way trip. Edits you make in the workbook stay in the workbook.

Edit in Excel is the round trip. You change records in Excel and publish them back to Business Central. It's available on most lists but not all, and it requires the Business Central add-in for Excel, which an administrator can push out or a user can install from the Office Store on first use. The workbook and the platform stay in sync through that add-in, so there's no export file to reconcile and no import step to schedule.

Three limits worth writing down before you promise this to a team:

1. It works with Excel for the web and with the Excel app for Windows, but not with Excel on macOS.
2. When OneDrive is configured for system features, Business Central caps the exported workbook at 100 columns so the file stays viewable in Excel for the web.
3. Filters mostly carry over, so the workbook has almost the same records and columns as the page, not always exactly.

WORTH DEMOING WITH YOUR OWN DATA

Ask to see one of your real lists opened with Edit in Excel, changed, and published back, on the same kind of device your team uses. It's a two-minute demo that answers the macOS question, the column-count question, and the "is this list supported" question all at once.

Power Apps: extend the platform, then check the license

Power Apps reaches Business Central data and processes through the same Business Central connector that Power Automate uses, which makes it a reasonable way to put a purpose-built screen in front of people who should never see the full platform. A warehouse app on a tablet, or a small approval and lookup app inside Teams, are the usual first builds. Microsoft is also rolling out tooling and sample apps for this, currently in preview.

The licensing point belongs in the same paragraph as the capability. The Business Central connector is classified as a premium connector in both Power Apps and Power Automate. For Power Automate, the use right that comes with Business Central covers flows working with your Business Central data. For Power Apps, the people who use the app need Power Apps licensing of their own. That's not a large surprise if you plan for it, and an expensive one if you find out after the app is built.

What each one costs you in setup

What to turn on, and when

None of this redesigns a process. It removes steps from work your team already does: the lookup someone does in a second browser tab, the export and re-import that turns a spreadsheet edit into an hour, the approval that waits in an inbox nobody checks after four o'clock.

That's worth having, and it's also the reason to sequence these deliberately. Get the process right in the platform first, then decide which of these surfaces it belongs on. Turning them all on during go-live week gives your team a stack of new things to learn at the exact moment they have the least patience for any of them.

If you're evaluating Business Central and want to see these run against your own data rather than a demo company, bring us the two or three moments in your week where people are copying between systems. Those are the places where the ecosystem argument either earns its keep or doesn't.

Why a company would want less help, not more

Their first implementation ran long and cost more than double the original quote, partly because the monthly software fee kept running while the project dragged on. Along the way, their own team ended up doing a lot of the work anyway: importing inventory, building forms, writing customizations. By the end, they had real skills in-house and a healthy skepticism of paying for legwork they could do themselves.

That's a reasonable place to land. If your engineers can configure the system and load your data, you may not need a partner for that part at all. What you often still need is judgment: someone who can tell you when a thing you want to do will cause problems downstream, and who can handle the pieces that genuinely require deep platform knowledge.

The real scoping work: a shared-responsibility matrix

When the client is doing a big share of the work, the estimate isn't really about sizing a full build. It's about drawing clear lines. The exercise becomes a detailed conversation about who owns what, where our work starts and stops, and exactly which gaps you want us to fill.

Done well, that gives everyone a document that answers questions before they become disputes:

• Which configuration and data work your internal team owns
• Which decisions you want reviewed before you commit to them
• What you can escalate to us and how quickly you'll get an answer
• Which specialty items (integrations, tricky workflows, industry-specific needs) we handle end to end
• How the relationship continues after go-live for changes and new requirements

THE TRAP TO AVOID

The failure mode of a shared engagement is fuzzy boundaries: both sides assume the other owns a task, and it falls through the cracks near go-live. Nail the responsibility split in writing before work starts.

Advice work needs business fluency, not just developers

There's a reason this client's first experience felt thin on guidance. They said their implementers were technologists first, capable of writing code but light on understanding the business and steering them away from choices that would break later. That's the gap an advisory engagement has to fill.

On a Dynamics or Business Central project, the person you most need in these conversations is someone who can take a business need, translate it into a sound configuration, and push back when "you can, but you shouldn't" is the right answer. On our team that lead usually comes from an accounting or controller background and moved into systems work, precisely so those downstream-impact conversations happen up front.

Keeping support to one phone number

This company had also been burned by finger-pointing between a platform vendor and a third-party integrator, each blaming the other when something broke. That's worth planning around. Business Central covers general ERP needs, and some manufacturing-specific features come from independent software vendors (ISVs, third parties Microsoft maintains close partnerships with). Using an ISV is fine. What matters is scoping support so you call one team, and that team deals with the ISV on your behalf instead of sending you off to chase it.

If you've already got capable people in-house and you mostly want a knowledgeable partner on call for the hard parts and the strategic calls, that's a real engagement model, not a consolation prize. We're glad to talk through where the lines should sit for your situation.

The problem: too many permutations to model as separate items

This company sells equipment that ships with a lot of mix-and-match parts (different cables for different situations, various options that matter to production but not to the customer). Their old vendor offered two answers. One was to buy a configurator tool. The other was to build a separate assembly for every possible configuration.

Neither fit. The configurator was priced for a web storefront where customers self-serve, and this company doesn't sell that way; only internal salespeople would ever touch it. And an assembly per configuration meant thousands of records nobody could realistically browse to find the right one at quote time.

The workaround they built

They landed on what NetSuite calls an item group: a single line on the quote or sales order that contains many underlying items, priced as a unit, with the ability to remove items at the point of quote. Their insight was to flip the mental model. Instead of asking a salesperson to remember to add every part a configuration needs, they load the full list and have the rep remove what isn't needed.

You can't forget to add something when it's already there and you're just taking away what you don't need.

That one change made the data coming from sales into production accurate enough that it rarely needed corrections. The right parts got packed, built, and tested because the sales order reflected the real configuration, even when the customer didn't care about the details.

How this maps to Business Central and Dynamics 365 Sales

When you're evaluating a move, the question isn't whether the new platform has a feature with the same name. It's whether the platform can reproduce the outcome: an accurate configuration flowing from quote to production without a giant item master.

On the CRM side, Dynamics 365 Sales has a bundles concept that groups products into a single sellable unit, which is a reasonable place to reproduce that quote-time behavior. What deserves careful design is the hand-off: when a quote becomes an order and lands in Business Central, does the bundle stay bundled, and how does that drive work orders and invoicing? For many manufacturers, the bundle matters at the front of the process (making quoting fast and accurate) and stops mattering once it's an order moving through production. That's a design decision worth making on purpose, not by default.

WORTH DEMOING

Before you commit, ask to see your own configurable-product scenario walked from opportunity to quote to sales order to work order. Watching your real permutations flow through is far more useful than a feature checklist.

The point most buyers miss

A workaround that works isn't automatically something to carry forward, and a native feature isn't automatically better than the workaround you already trust. The right move is to name the outcome you need (accurate configuration, fast quoting, clean production data, no SKU explosion) and then test how the new platform delivers it before you build anything.

If you're weighing a platform change and you've got a configurable-product headache like this one, we're happy to talk through how it would look in Business Central and Dynamics 365 Sales before you're committed to anything.

No license makes you compliant. Microsoft sells capability. Compliance is something your organization does with that capability, documents, and then demonstrates to a third party. That distinction determines what you are buying and what work remains after the purchase order clears.

What follows covers the four regimes Wired CIO works in most often, where the capabilities live in the licensing tiers, and the decisions that are hard to undo.

Microsoft sells capability, not compliance

Microsoft says this itself, in the documentation it publishes for each regime.

On the Health Insurance Portability and Accountability Act (HIPAA), Microsoft states that signing a Business Associate Agreement helps support your compliance, but that using Microsoft services does not on its own achieve HIPAA compliance. On the Food and Drug Administration's electronic records rule, Microsoft notes that no certification exists for it at all, and that customers who build applications subject to FDA regulation are responsible for ensuring those applications meet FDA requirements. On the Cybersecurity Maturity Model Certification (CMMC), Microsoft's guidance opens by saying compliance depends on customer configuration, implementation, and operational controls, as well as on qualified assessors.

None of that is hedging. It is an accurate description of how these regimes work. The regulator or the auditor examines your organization, your processes, and your evidence. The platform is one input.

Shared responsibility in plain terms

Cloud services split the work. Microsoft is responsible for the security of the cloud: the datacenters, the hardware, the service code, and the operational controls it has audited. You are responsible for security in the cloud: who has accounts, what those accounts can reach, how data is classified and retained, what devices connect, and whether anyone is reviewing any of it.

Microsoft publishes a shared responsibility model mapping this out by service type. The practical version is shorter: identity, data, configuration, and process are yours in every model, and in every regime below they are where most audit findings land.

There is a useful detail in Microsoft's audit reports on this point. At the end of a System and Organization Controls (SOC) 2 report is a section titled "User Entity Responsibilities," listing the controls you have to operate for the overall system to meet the standard. It is worth reading before your auditor reads it back to you.

The four regimes, briefly

FDA 21 CFR Part 11, meaning Title 21, Part 11 of the United States Code of Federal Regulations (CFR), governs electronic records and electronic signatures in life sciences. It applies to FDA-regulated research, clinical study, manufacturing, and distribution. It requires that electronic records be trustworthy substitutes for paper, that systems carry audit trails for data values, that electronic signatures have integrity, and that systems be validated and documented as doing what they are meant to do. There is no certification for it. Microsoft's position is that its SOC 1 and SOC 2 Type 2, ISO/IEC 27001, and ISO/IEC 27018 audits can be used as inputs to your own validation effort, and it publishes guidance for regulated life sciences workloads on Azure.

CMMC is the Department of Defense's framework for contractors handling Federal Contract Information (FCI) and Controlled Unclassified Information (CUI). It has three levels, built on well-established standards from the National Institute of Standards and Technology (NIST). Its rollout status changed materially in July 2026, which is covered further down.

HIPAA governs the use, disclosure, and safeguarding of individually identifiable health information. It applies to covered entities, meaning healthcare providers, health plans, and clearinghouses, and to their business associates. A cloud service handling protected health information becomes a business associate too, which is why the Business Associate Agreement exists.

SOC 2 is not a regulation. It is an attestation performed by an independent accounting firm against the American Institute of Certified Public Accountants' Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. No law requires it. Customers do, usually in a procurement questionnaire and increasingly as a condition of the contract.

What auditors ask for, and what proves it

It is more useful to think in terms of the question being asked than the product being sold. Across all four regimes, the questions rhyme.

The first two deserve special attention. Audit logging tells you what happened; retention and hold tell you the record still exists to be examined. Everything else on that list can be reconstructed with effort. Those two cannot be reconstructed at all if they were not turned on at the time.

Where the capabilities sit in the licensing tiers

This is the part that surprises people, and it is worth being direct. A meaningful share of the compliance capability lives in the top Enterprise tier, Microsoft 365 E5, or in a specific add-on, rather than in Microsoft 365 Business Premium.

As of July 2026 the enterprise lineup is E3, E5, and a newer top bundle called E7, which packages E5 with Microsoft 365 Copilot and other components. For compliance purposes E5 remains the tier where the capabilities live, and E7 includes E5. Current contents and pricing are in the enterprise plan comparison and the small and medium business plan comparison. Broadly, according to Microsoft's Purview service description:

Available at Business Premium and E3:

• Audit (Standard), enabled by default
• Retention policies and retention labels, including publishing labels for manual use
• Manual sensitivity labeling
• Data loss prevention for Exchange Online, SharePoint Online, and OneDrive
• Conditional Access, which requires Microsoft Entra ID P1 and is explicitly available to Business Premium customers

Requires E5 or a specific add-on:

• Audit (Premium), which is where longer log retention lives
• Automatic and policy-based sensitivity labeling, including trainable classifiers
• Endpoint data loss prevention, meaning data leaving via a laptop rather than via email
• Insider risk management
• eDiscovery (Premium)
• Adaptive policy scopes for retention

The pattern is consistent. Business Premium gives you the ability to do the thing manually and for a person to configure it. E5 gives you the ability to do it automatically, at scale, and to keep the evidence longer.

What a smaller business can do about it

Moving an entire organization to E5 to satisfy one clause in one contract is rarely proportionate. There are three routes that usually are.

Buy the add-on rather than the tier. Microsoft sells Purview capability as add-ons that sit on top of a Business Premium base, described in the service description as Microsoft Purview Suite for Business Premium and Microsoft Defender + Purview Suite for Business Premium. They require a Business Premium base license and are capped at 300 seats in total. For a company under that ceiling, this is usually the shortest path to Audit (Premium) and the wider Purview set without changing the underlying plan.

License by role rather than by headcount. Several of these capabilities are licensed per user who benefits from the service. If the regulated work is done by 12 people in quality and regulatory affairs, the licensing conversation can start there rather than at the whole company. The rules on who counts as benefiting are specific and worth checking per capability, because for some solutions the affected population is broader than the team operating the tool.

Solve some of it outside the license. Audit records can be exported programmatically into a system where you already keep long-term data. That trades a licensing cost for an engineering and operating cost, which is sometimes the right trade. It is worth pricing both.

None of these are shortcuts around a requirement. They are ways of scoping the purchase to the obligation.

The Business Associate Agreement for HIPAA

If HIPAA applies to you, this part is more straightforward than expected.

Microsoft offers a HIPAA Business Associate Agreement to its covered entity and business associate customers, and it is available through the Microsoft Online Services Data Protection Addendum by default. It covers the standard commercial cloud, not only a government or specialized environment, and the in-scope services list is long: Azure, Microsoft 365 and Office 365, Dynamics 365, Microsoft Intune, Windows 365, Power Apps, Power Automate, and Power BI among them.

Three things to know. Microsoft will not sign your organization's own Business Associate Agreement template, because the service is standardized across all customers. Microsoft's Business Associate Agreement document is published and can be reviewed by your counsel. And, as Microsoft states in its own frequently asked questions, having the agreement does not make your organization HIPAA compliant. It establishes what Microsoft is responsible for.

The government cloud decision for defense work

If your work touches Department of Defense contracts, one architectural decision has to be made early, because reversing it is genuinely difficult.

Microsoft operates the commercial cloud, a Government Community Cloud (GCC), and a Government Community Cloud High (GCC High). These are different environments, not different price tiers of the same thing.

According to Microsoft's own service description and CMMC guidance:

• Commercial supports CMMC Level 1 requirements, and Microsoft describes Federal Risk and Authorization Management Program (FedRAMP) High authorization for some services.
• GCC provides compliance with the Defense Federal Acquisition Regulation Supplement (DFARS) and the relevant federal cloud requirements, with customer content stored in the United States and access restricted to screened Microsoft personnel.
• GCC High supports CMMC Level 2 and Level 3 requirements when configured appropriately, along with DFARS and the International Traffic in Arms Regulations (ITAR).

The dividing line Microsoft draws is specific: GCC is not suitable to hold what is called CUI Specified, which includes export-controlled categories such as ITAR data, and Microsoft states that it will only agree to ITAR contract language for the GCC High environment. The determining factor is the category of controlled information in your contracts, not a general sense of how careful you would like to be.

Two consequences follow, and both are commercial.

Cost and functionality differ significantly. The government environments cost more than commercial and do not have feature parity with it. Microsoft's own guidance acknowledges the parity gap and argues some of it is deliberate. Features arrive later, and some do not arrive at all. That is an operating constraint for the whole business, not only for the regulated team.

Migrating later is a project, not a setting. Microsoft's own guidance advises allocating at least three months for the migration phase, and the process resembles migrating from any other cloud rather than flipping a switch. Mailboxes, files, identities, and integrations all move. Choosing commercial now and GCC High in 18 months means doing the work twice.

There is a middle path. Some organizations put only the regulated work in GCC High, as a data enclave, and leave everything else in commercial. Microsoft's guidance is even-handed on this: an enclave can reduce cost compared with moving everyone, but it notes that the most common way controlled data leaves the boundary is through personal storage and email, which sit outside the enclave. If you go that route, the boundary needs to be designed rather than assumed.

Where the CMMC program stands as of July 2026

This is a moving target, and anything written about CMMC ages quickly. As of this writing:

Phase 1 began on November 10, 2025, requiring CMMC Level 1 and Level 2 self-assessments on applicable contracts. Phase 2, which would have made third-party certification mandatory from November 10, 2026, was suspended with immediate effect on July 13, 2026, along with the later phases, and a reform task force reporting to the department's Chief Information Officer was asked to review the program and report back within about 60 days. This was reported by Federal News Network and analyzed by government contracts counsel.

What has not changed is more important than what has. DFARS 252.204-7012 remains in effect, and with it the requirement to implement the 110 security controls in NIST Special Publication 800-171 for covered defense information, plus cyber incident reporting. The Federal Acquisition Regulation (FAR) basic safeguarding requirements at 52.204-21 remain. Level 1 and Level 2 self-assessments and annual affirmations remain.

The practical reading for a business owner: the certification appointment has been postponed, and the underlying security requirements have not. Work done now against NIST Special Publication 800-171 is not wasted. Waiting for the program to settle before starting the control work is a bet on a timeline nobody currently controls. If certification timing affects a specific bid, confirm the current position against the contract language in front of you rather than against anything written earlier, including this.

Documentation Microsoft publishes that you can hand an auditor

You do not have to build evidence about Microsoft's own controls. Microsoft has it audited and publishes it on the Service Trust Portal: independently audited compliance reports, including SOC 1 and SOC 2 Type 2 reports, ISO certifications, and related documentation your auditors can compare against your own requirements. Access requires an existing subscription or free trial account, a condition set by the accounting profession rather than by Microsoft. Azure customers can also retrieve Azure certificates and audit reports from within the Azure portal.

Two details that make these reports more useful:

• Microsoft commissions a full SOC 1 and SOC 2 Type 2 examination annually, covering a rolling 12-month window that runs October 1 to September 30. Reports are issued a few months after the period closes.
• For the gap between the end of an audited period and the next report, Microsoft issues quarterly bridge letters, which are self-attestations covering the intervening months. If your auditor asks for coverage of a period that the latest report does not reach, the bridge letter is the answer.

Microsoft also publishes Purview Compliance Manager, with assessment templates for HIPAA, CMMC, FDA 21 CFR Part 11, and many others. It is a useful scoping and tracking tool. It is not an attestation, and no score inside it means anything to an auditor on its own.

Gotchas that catch non-technical buyers

• Audit log retention only surfaces during an incident. Audit (Standard) retains records for 180 days. If you discover in month eight that something happened in month two, the record may be gone, and no purchase made afterward brings it back. Longer retention is an Audit (Premium) capability, and the 10-year retention option requires a separate per-user add-on that is explicitly not retroactive. This is the licensing decision people most regret making late.
• Retention on top of Audit (Premium) is not uniform. Microsoft Entra ID, Exchange, OneDrive, and SharePoint get one year by default. Other services default to 180 days unless someone creates a retention policy.
• "We have E5" is not the same as "the licenses are assigned." Several of these capabilities apply per user with the appropriate license assigned. A tenant-wide purchase with unassigned licenses produces gaps that only appear when you go looking for the record.
• Turning a capability on is not the same as configuring it. Data loss prevention with no policies, or insider risk management with no scenarios, is a line item, not a control. Auditors ask what the policy says and who reviews the alerts.
• The government cloud decision is effectively one-way. Choose the environment based on the categories of controlled information in your contracts, and make the decision before you migrate, not after.
• A partner and an auditor are different roles. Wired CIO can design, implement, document, and operate the controls, and prepare the evidence you hand over. We do not issue attestations, certify compliance, or provide legal advice, and no IT partner can. The assessor's independence is part of what makes the assessment worth anything, so the two roles are kept separate by design.

Where to start

The productive first conversation is rarely about licenses. It is about the specific obligation: the clause in the contract, the question on the questionnaire, or the finding from the last assessment. From there the mapping is usually quick, because most of it comes down to which records you must be able to produce, how far back, and who has to be prevented from doing what.

If you have a customer questionnaire open on your desk, or a contract that just added a clause you have not seen before, bring us the document. Wired CIO works as a fully managed or co-managed IT partner, and we will walk through what your current licensing covers, what it does not, and what the gap costs to close.

She framed it well. The team's whole model depended on the current file format flowing into downstream tax software, so the safe move was to layer intelligence on top rather than rebuild underneath. But whether it would pay off depended on things nobody could answer from a sales call: how clean the source data was, which documents were genuinely worth automating, and where a human had to stay in the loop. That is what Phase 0 is for.

What Phase 0 is here

Phase 0 for an AI or automation project is the same idea as the design phase we run ahead of a platform build, pointed at a different outcome. It is a standalone engagement with a fixed fee and a stopping point at the end, and nothing production gets built inside it.

The output is a documented design: which use cases are worth pursuing, what data feeds them and in what condition, where the automation makes decisions and where a person reviews, and what governance has to be in place first. That comes with a fixed-fee proposal for the build, priced against scope we have confirmed, and the documentation is written to stand on its own so any qualified Microsoft partner could execute from it.

If you proceed with the build within three months of Phase 0 closing out, we credit 100% of the fee toward it. The discovery is work we would do at the start of the project anyway, so it shouldn't be paid for twice.

Why the build can't be quoted first

With AI especially, the answer to "what will this cost" is usually "let's find out whether it works." For a build like document extraction, that means a proof of concept: a short, time-boxed exercise, a week or two, run against real historical data with no production rewiring, to see whether the model clears the bar you set. If it takes much longer than that to prove the concept, it has stopped being a proof of concept and started being the project.

The gate is whether the payback justifies the build. A process running millions of documents a season against a tight turnaround, with hundreds of seasonal reviewers hired to hit it, clears that bar easily. A once-a-quarter task that takes someone an afternoon does not. Phase 0 is where you decide which is which before committing budget.

What AI discovery inventories that a process or infrastructure one doesn't

• Data readiness. Where the data lives, and whether it is good enough to act on. If the source capture never recorded a field, no model conjures it back. As the operations lead above put it when we walked through her documents, if the data isn't there, it isn't there, and that is the right answer to hear early rather than late.
• Permissions and oversharing. Microsoft 365 Copilot answers from whatever a user can already open. Turn it on over a SharePoint where sharing has sprawled for years, and it will surface things quietly and confidently. So a permissions and oversharing review comes before you provision a single license, not after someone gets an answer they shouldn't have.
• Which processes are worth automating. Not every manual step earns a build. Discovery ranks candidates by volume, error rate, and return, and is willing to conclude that some of them should stay manual.
• Confidence and human-in-the-loop design. The useful question is rarely "can the machine do this," it is "where do we trust it and where does a person check." A good design scores each output and routes it: pass the high-confidence cases through, send the low-confidence ones to review. That is how a review team shrinks without anyone losing sleep over what slipped past.
• Governance. For regulated data, this is the part that has to exist before the AI does: a Business Associate Agreement (BAA) where health data is involved, Data Loss Prevention (DLP) and sensitivity labels, audit logging of AI interactions, and a decision about which public AI tools are allowed at all.

What discovery tends to turn up

At a residential-care nonprofit handling Protected Health Information (PHI), the real finding came before any Copilot rollout: staff were already pasting case notes into public AI tools to save time. Education alone was not going to hold that line reliably. The design put a governed Copilot in front of them so the data stayed in the tenant, but only after tightening permissions and standing up DLP first, so the tool would not surface protected information the moment it turned on.

A second pattern shows up often enough to name: licenses that sit unused. Hand a team Copilot with no playbook and it mostly stays on the desktop. Discovery is where the actual use cases get written down, role by role, with the specific tasks people will hand to it, because adoption is a design problem, not a licensing one.

When you don't need one

A single, well-understood flow, a Power Automate approval, a form that routes to the right person, with clean data and a clear owner, does not need a design phase in front of it. Bring us the specific automation and we will build it.

Phase 0 earns its place when the use cases are still a wish list, when nobody can vouch for the data or the permissions the AI would rely on, when the process touches regulated data, or when you want a fixed fee on a build whose feasibility hasn't been proven yet.

If you are somewhere in that territory and want to work out whether an AI idea is ready to build or still needs proving, bring us the process you would most like to stop doing by hand. That is the right place to start.

That gap, between knowing you need to comply and knowing exactly what the framework requires of your systems, is what a compliance Phase 0 closes. And until it closes, nobody can put a real fixed fee on the remediation.

What Phase 0 is here

Phase 0 for a compliance project is a fixed-fee gap assessment and roadmap. The worked example throughout this piece is the Cybersecurity Maturity Model Certification (CMMC) and the NIST SP 800-171 controls it is built on, because that is where most of this work lands, but the same discipline applies to HIPAA, SOC 2, and FDA 21 CFR Part 11.

The reason it is a standalone engagement is simple: you cannot quote remediation against controls you have not yet mapped, in a boundary you have not yet drawn. The assessment produces the map. Its output is a documented gap list rated by severity, a remediation roadmap sequenced by risk and effort, and the core compliance documentation, so the follow-on project can be quoted against confirmed scope rather than guessed at.

If you proceed with remediation within three months of the assessment closing out, we credit 100% of the fee toward it. The assessment is groundwork the remediation would have to cover anyway.

What a gap assessment inventories that other Phase 0s don't

• A control-by-control mapping against the framework, tagged by owner. Every control lands in one of three buckets: inherited from Microsoft's platform, operationalized by your IT partner, or requiring your own evidence and procedures. That shared-responsibility split is the difference between a checklist and a plan, and it is what a remediation quote prices against.
• The boundary. Where does the controlled data live, and what is in scope versus out. For controlled defense information this is the enclave design; for health data it is wherever Protected Health Information (PHI) flows. Scoping is not a preliminary step to the findings, it usually is the largest finding.
• The documentation package. A System Security Plan (SSP), a Plan of Action and Milestones (POA&M) for the gaps you can't close immediately, and the supporting policies and procedures.
• Technical versus administrative controls. Some gaps are a configuration change; many are a written policy, an assigned owner, and evidence that the policy is followed. The assessment separates them, because they get remediated by different people.
• Whether the tenant can even support the controls. Sometimes the finding is that the environment isn't ready to be remediated yet: a consumer-grade tenant that can't enforce device management, or a commercial tenant where controlled data really needs to sit in a separate Government Community Cloud High (GCC High) tenant.

Note what stays out of scope: the formal certification. A gap assessment is pre-audit readiness. When a Certified Third-Party Assessor Organization (C3PAO) is involved, that engagement is separate, and the assessment is designed to get you ready for it, not to replace it.

What discovery tends to turn up

The most common surprise is that the boundary is fuzzier than anyone assumed, exactly the distributor above, whose plan hinged on a wall he had not yet defined. Pinning that down is where most of the value is.

The second is that a framework everyone assumed applied doesn't touch the system in question. One aerospace-services company came to us flagging four regimes at once. Discovery deflated two of them: its health-data obligation ran through the benefits and human resources relationship, not any patient records, and nothing in its ERP met the definition of controlled defense information, which was almost all engineering data. Two of the four fell away, and the remediation got materially smaller and cheaper. The assessment's first job is often to establish which frameworks reach which systems.

The third is an organization that believed it was close and wasn't. A small research contractor expecting funded defense work was still running on a consumer-grade tenant that couldn't enforce basic device management, which surfaced the day a departing employee kept a laptop nobody could wipe. In that case the roadmap started earlier and moved slower, because the groundwork had to come before the controls.

And sometimes the answer is to live in two worlds at once. A mid-size science and engineering contractor with several hundred people had only a few dozen people handling controlled data, so the design stood up a separate GCC High tenant alongside the existing commercial one rather than dragging the whole company into the stricter environment.

When you don't need one

If you already have a current control mapping, a defined boundary, and your System Security Plan and Plan of Action and Milestones in hand, you don't need someone to produce them. Bring us the remediation project.

The assessment earns its place when the boundary is undefined, when you are not certain which framework touches which system, when you need a fixed fee on remediation, or when a customer requirement, an audit, or an insurer's questionnaire is forcing the question on a timeline.

If that is roughly where you are, bring us the requirement you are being held to and we will walk through what a gap assessment would cover for your environment, and what it would leave for the remediation that follows.

She wasn't asking for a price. She was asking for an architecture decision, and she told us she hadn't been able to get a clear answer from anyone yet. That's a reasonable place for her to be. The answer depends on how many trading partners she'll be running in three years, how her brands are structured legally, and which parts of her process have to survive contact with a co-packer. None of that fits inside a sales call.

That gap is what Phase 0 exists to close.

What Phase 0 is

Phase 0 is the discovery and design work that sits at the front of any serious Dynamics 365 implementation, carved out into a standalone engagement with a fixed fee and a stopping point at the end.

Nothing gets configured. The output is a documented design: how your business runs today, how it will run on the new platform, what data moves and in what condition, who can see what, and what the build involves. Then everyone pauses and decides what to do next.

Two things come out of it. The first is a documentation set detailed enough that you can hand it to any qualified Microsoft partner and get a fixed-fee quote back without much fuss. That's deliberate. The design is written to stand on its own, including the platform recommendation, so it doesn't quietly lock you into one product or one partner. The second is our own fixed-fee proposal for the implementation, priced against a scope we've confirmed rather than one we've estimated around.

If you sign the implementation with us within three months of Phase 0 closing out, we credit 100% of the Phase 0 fee toward the project. The intent is that you don't pay twice for the same work.

Why a fixed fee comes after discovery rather than before

We've pulled our own fixed-fee option off the table before. On one project we had priced a marketplace connection as a routine custom integration, which is a common pattern and not a heavy lift on its own. Reading the client's requirements workbook more carefully surfaced enough additional trading partners that the right answer was probably middleware, not a set of one-off connections. Three or four of those changes the shape of the whole build.

We could have priced around that uncertainty. What that produces is a number padded with contingency, followed by a project that runs on in-scope and out-of-scope conversations nobody enjoys having. Phase 0 is the mechanism that earns a fixed fee instead of guessing at one.

What four to six weeks look like

Phase 0 runs as a series of structured workshops, organized by business workstream rather than by software module. A recent engagement for a multi-entity operations business ran 10 workshops and logged 47 confirmed design decisions:

The time commitment lands on your people, and it's worth planning for. On a comparable engagement it worked out to roughly four to six hours each for most function leads, and eight to 10 hours for the internal IT lead, who tends to carry the heaviest load because they're the one who knows where the systems are.

What you walk away with

Six documents, and all of them are yours:

• Solution Design Document. Current-state assessment, systems inventory, pain points, data quality findings, and the future-state design for every workstream, including integration architecture, environment strategy, and data migration approach.
• Data Dictionary and Entity Relationship Diagram guide. Field-level detail for every core entity, the relationships between them, status models, and master data standards. This is the piece that makes the package portable to another partner.
• Security Role Matrix. Role-by-role access across the platform, with segregation of duties controls and license mapping.
• Project Plan and RAID log. The Phase 1 schedule, milestones, and the running register of risks, assumptions, issues, and decisions.
• Executive Summary presentation. A short leadership-facing readout for sign-off.
• Implementation proposal. Fixed fee, defined scope, timeline, and resourcing.

What discovery tends to turn up

The findings are rarely dramatic, and they're almost always expensive if you meet them mid-build instead.

On one recent engagement, roughly 30% of the client's asset records were missing serial numbers, installation dates, or location assignments. Customer records were duplicated across the legacy CRM and the accounting system. The chart of accounts differed across all three legal entities and had to be harmonized before Microsoft Dynamics 365 Business Central setup could start. Discovery also turned up a customer-facing storefront, a custom internal portal, and a shipping platform that weren't in the original picture at all. Every one of those became a client action item with an owner and a due date, resolved before Phase 1 started rather than during it.

On another, two people at the same company answered the same discovery questionnaire and described two different companies. One described two legal entities. The other asked for three product brands, each carrying a full profit and loss statement and balance sheet. Whether those brands become separate Business Central companies or dimensions inside one company is the single largest driver of finance configuration effort in the project, and it's a question the client hadn't yet resolved internally.

When you don't need one

Plenty of projects go straight from a ballpark to a proposal, and they should. A single-workstream build, one legal entity, few integrations, and requirements the team can already articulate doesn't need a design phase bolted on the front.

Phase 0 earns its place when the platform question is still open, when the integration count is high enough that the architecture pattern itself is undecided, when the legal or brand structure hasn't been settled, or when you want a fixed fee on the build and someone has to do the work to make one meaningful.

If you're somewhere in that territory and want to talk through whether a design phase would help or just add a step, bring us the messy version. That's the useful one.

He said as much about the limits of anything he could tell us. "I maybe don't know everything that's going on everywhere else in the company," he said, "so a lot of this probably needs to be a broader discussion with the people who are running these things. This is just what I'm seeing from my side."

That sentence is the reason an IT Phase 0 exists, and it's why the engagement looks nothing like the design phase we run ahead of a Dynamics 365 build.

Discovering the environment, not the process

Ahead of an ERP or CRM implementation, discovery is about how work moves through the business. We sit in facilitated workshops with finance, sales, and operations and document the process.

An IT assessment asks a blunter question, which is what the company owns, who administers it, and what condition it's in. The method is inventory and audit rather than workshops, and the unknowns are different in kind:

That last row matters more than it looks. An assessment doesn't change anything. Beyond a handful of low-risk configuration fixes made with your approval as we find them, it's a read-only exercise, which is what makes it safe to run while the business keeps operating normally.

The questions nobody inside can answer

The retail operator runs about 150 employees against 65 Microsoft 365 licenses, because most store staff don't need a mailbox. He had a reasonable working knowledge of the tenant and a specific list of things he couldn't answer:

• Whether SharePoint content was being backed up at all. His words: "I know it lives in the cloud, but…"
• Whether the file structure his operations lead had built was laid out sensibly, or whether most shared documents had simply ended up in individual OneDrive accounts.
• Which users were sharing what externally, and whether the right people could see the right documents.
• Why the company was paying for 10 or 12 seats of a desktop conferencing product nobody used, when the same capability was already in the Microsoft licensing. Nobody knew the renewal date either, which meant nobody could time the drawdown.
• How much of the network hardware had passed end of support, and which consumer-grade equipment was still quietly passing traffic.

None of that is unusual, and none of it reflects badly on him. Those answers live in a tenant, in a license portal, and in a switch configuration, not in anyone's head.

A different engagement showed the same shape at the other end of the technical spectrum. A nonprofit running a large online training platform had operated its own infrastructure since the 1990s: three production servers in a single data center, a custom application, and a network administrator retiring at the end of the quarter. The technical lead had 26 years of institutional knowledge and was completely clear about the limits of it.

"I've only done on-prem, so I think of the infrastructure. I don't know if platform as a service may work for us. I don't even know. And I don't know what the cost would be. I don't even know how to estimate it."

Why a questionnaire doesn't close the gap

We send a technical questionnaire before an engagement like this. It's useful, and it isn't sufficient.

On that same nonprofit engagement, the questionnaire came back listing peak concurrent users at 1,200. We drafted a sizing model and a cloud spend forecast against that number. On the review call, the technical lead read it and corrected us on the spot: peak is closer to 86,000, on a handful of mandated training days a year. As he put it, 1,200 "wouldn't even be one county."

That single correction changed the compute design from fixed servers to an auto-scaling model, moved the monthly cloud forecast into a different bracket entirely, and would have changed the migration quote by a wide margin. It surfaced because a senior architect walked a decision maker through a draft, line by line, and asked follow-up questions. A form doesn't do that.

The same engagement's questionnaire also came back with two sections blank: the inventory of intranet applications, and the record of existing cloud subscriptions and licensing agreements. Both went onto the assessment scope as named items to close. Discovery has kept turning up more since: a second web server nobody had mentioned, a storage array with 36 TB allocated and 2 TB in use, a test environment larger than production, a database failover process that is a manual address swap, a 30-minute recovery point objective with no recovery time objective defined at all, and an undocumented site-to-site link to a partner network that has been in place for decades.

We also struck an assumption from our own draft. An early version stated that no regulatory frameworks applied. Nobody had established that, so it came out and became a discovery item instead: identify the applicable state security policy series, the sponsoring agency's requirements, and the correct data classification for training records. An assessment that assumes a compliance posture isn't an assessment.

What comes out of it, and why it's phased

The deliverable is a prioritized findings report, an identity and security baseline, documentation and administrative access recorded in a form that isn't proprietary to us, and a remediation roadmap with the work sequenced. The roadmap is the point. An inventory that doesn't tell you what to do first is a filing exercise.

Two principles shape it. The first is that we work through what your existing Microsoft licensing already covers before adding anything on top, because most organizations are paying for capability they haven't turned on. The second is portability: the tooling and documentation should lift out cleanly and be adoptable by any IT partner, because the goal is an internal capability that belongs to you.

Sequencing is deliberate, and things get held back on purpose. On the retail engagement we pushed backup deployment, file governance, the conferencing consolidation, and the network refresh out of the assessment and into the roadmap, each for a stated reason: the backup design should follow the findings rather than assume them, the voice migration should line up with a renewal date, and the hardware refresh should be something leadership can put out for competing bids. That also matches how the money works. Phased, digestible spend is easier to approve than one large commitment, and leadership gets to prioritize the findings rather than inherit our ordering.

If you engage us for the follow-on work within three months of the assessment completing, we credit 100% of the assessment fee toward it. Much of that work would be part of onboarding anyway, so it shouldn't be paid for twice.

When it's the wrong step

If you have a current asset and license inventory, a clean identity model, one directory, documented backups, and a list of the applications in use with named owners, you don't need someone to produce those things for you. Bring us the specific project instead.

An assessment earns its place when the environment has grown faster than the documentation, when responsibility for systems is spread across people who have moved on or are about to, or when you're being asked to approve a roadmap that was written before anyone looked. In the first of these engagements, the client proposed the sequence himself before we did: audit where everything is today, find the gaps, then decide. Nothing was on fire. That's usually the best time to do it.

If that's roughly where you are, we're glad to walk through what an assessment would cover for your environment and, as importantly, what it wouldn't.

A stale standard is a setup choice, not a system flaw

Standard cost means you set an expected cost per item once, and every transaction posts against that figure. Anything the market does differently shows up as a variance. That's useful when you want to measure manufacturing performance against a plan. It's painful when your raw material price swings and you only reset the standard once a year, because the whole year's difference piles up into one number nobody can explain later.

Business Central doesn't force one costing method on the whole company. You choose a costing method per item, on the item card, and you can mix them. That flexibility is the part most shops in this position don't realize they have.

A common split: average on raw, standard on finished

For a job shop that buys volatile raw material and builds it into finished goods, one pattern shows up often:

• Purchased raw material on average cost, so the cost tracks what you actually paid as the market moves, without an annual revaluation exercise.
• Finished goods on standard cost, where you genuinely want to see a manufacturing variance against a plan.

That way the market-driven price movement on steel flows through as a real cost instead of a year-end surprise, and the variance you do report is the one that tells you something about how the shop ran.

COSTING METHODS

Business Central supports several costing methods per item, including Average, Standard, FIFO, and Specific. The right choice depends on how volatile the item's cost is and whether you want to measure a variance against a plan.

Decide before go-live, not after

You can change an item's costing method later, but it isn't a casual switch. Once an item has posted transactions, changing the method means running a revaluation and having a conversation with your auditors about whether the numbers are comparable across the change. That's a real project on its own.

It's far cheaper to get this right during design. This is why we spend real time on costing when we plan an implementation instead of treating it as a configuration detail to sort out later. The item card decision follows you for years.

Talk it through

If your standards are stale and your material prices move, it's worth mapping which items should carry a variance and which should just track the market before you commit to a design. We're happy to walk through your item list with you and think it through together.

Her words for it were "chasing chickens." Sales would hand her a closed deal, she'd spin up work in a project tool, chase five consultants to log their hours in a separate time app, and then get on a two-hour call at month-end just to confirm everything had been captured before invoicing. That's a lot of effort spent moving information by hand, and it's where errors creep in.

The real cost isn't the license fee

When people add up tool sprawl, they usually count the subscriptions. Those matter, and in this case one project tool alone was running several thousand dollars a year. But the bigger cost is the human glue holding the tools together. Someone has to copy data from the quote into the project plan, remind people to move their task cards, reconcile time before an invoice goes out, and re-enter the same schedule into two views because the Gantt chart doesn't sync with the task board.

None of that shows up on an invoice. It shows up as late invoicing, hours that never get billed, and a project manager who can't see where anything stands without switching between screens.

It should not take a two-hour phone call to make sure we've invoiced everything for the month.

What consolidation looks like for project-based work

For a firm that sells engagements (quote, deliver, revise, invoice), the goal is a single view where a project carries its tasks, its assigned people, its due dates, and the time logged against each task. When that lives in one system, the project manager can see status and hours together, and month-end stops being a scavenger hunt.

There's one rule that makes or breaks this. Time tracking has to happen in the same system that runs the projects. We've had conversations where a firm wants to run projects in one platform but keep logging hours somewhere else, and that defeats the point. The value comes from time, tasks, and status sitting in the same place.

A NICE SIDE BENEFIT

Once time is captured against tasks, you can look back at what a similar engagement cost you and quote the next one more accurately. "We quoted this much and went over" becomes data you can act on instead of a gut feeling.

Where accounting fits

You don't have to consolidate everything at once. Plenty of firms start with the project and time side and keep QuickBooks as the general ledger, with an integration that passes billing information over on whatever cadence they need. Others decide to replace QuickBooks with Business Central later, especially if they're acquiring other companies and want one financial system across them. It's reasonable to scope both and let leadership decide which pieces to do first.

A sane way to phase it

For a firm that plans in monthly blocks, a phased rollout tends to work better than a flip of the switch. Roughly: one month to bring existing projects and time history into the new system and confirm it's set up right, a second month to run it in parallel and catch anything that gets missed, and a third month to retire the old tools once everyone trusts the new one. Timelines vary with how clean your data is, but the pattern holds.

If this sounds familiar

If your quotes, hours, and project plans live in three different tools and someone is stitching them together by hand every month, we're happy to talk it through and map out what a single system would cover and what it would leave in place. No pressure, just a clearer picture of your options.

Two different sharing models, two different prices

When people think about Power BI cost, they usually think about Pro licenses: a per-user monthly fee for the people who build and view reports inside the organization. That model works when everyone who touches a report has an account in your tenant. It's predictable, and for a nonprofit it's often heavily discounted or free through the Microsoft nonprofit entitlement.

Publishing to the public is a separate story. When you want an unknown number of anonymous visitors to view a report on your website, you can't hand each of them a Pro license. Instead you're looking at capacity-based licensing, where you pay for the horsepower that serves the reports rather than for named users. That's typically Power BI Embedded or Microsoft Fabric capacity, and it's billed by the hour or month based on the capacity size you reserve.

THE SHIFT

Internal viewers are priced per person. Public, anonymous viewers are priced by capacity. The second model exists precisely because you can't count or license the audience.

Why a yearly number is hard to pin down

The nonprofit's real frustration was getting a firm annual cost. That's genuinely hard with capacity, because you pay for a running resource, and the annual figure depends on the capacity tier you pick and whether you pause it when it's not in use. It's less like buying a fixed number of seats and more like renting a machine that has to stay on to serve your website. That's the source of the confusion, and it's a fair thing to be confused about.

Sometimes simpler tooling is the better fit

Here's the part worth sitting with before you commit. This team's data was small, lived in Excel, and updated about once a year. It wasn't a large, fast-moving warehouse. When the data is that light and the goal is a few interactive charts on a website, standing up capacity for public embedding can be more machinery than the job needs. A set of well-built static or lightly interactive web charts, refreshed when the annual data lands, can deliver the same visitor experience for a fraction of the cost and complexity.

None of that is a knock on Power BI or on the tool they were already using. Both are strong for reporting, especially when the underlying data is large, changes often, or connects to other systems. The point is to match the tool to the actual workload. If you're on Microsoft already and your reporting audience is internal, Power BI Pro is an easy call. If your audience is the open internet and your dataset is small, it's worth pricing the lighter option too before you reserve capacity.

If you're weighing this yourself

Nonprofits should start in their own admin center, on the products page, where Power BI Pro and Fabric pricing shows up with the nonprofit discount already applied. That's the path of least resistance for licensing. The harder call is the architecture: internal versus public, and whether the data volume justifies capacity at all.

If you're trying to figure out where your reporting fits between a few Pro seats, public embedding, and something lighter, we're happy to talk it through and help you avoid paying for machinery you don't need.

It's a good question, and it trips up a lot of businesses that start with finance and later bring in the shop floor. Here's how the licensing actually shakes out.

Essentials versus Premium is an all-or-nothing choice

Business Central full users come in two tiers, Essentials and Premium. Essentials covers finance, sales, purchasing, inventory, and project management. Premium adds manufacturing and service management on top of everything in Essentials.

The part people miss: you can't mix and match those two across your users. Once your organization needs the manufacturing module, your full users move to Premium across the board. So if you scope finance only at first and price around Essentials, then decide to pull manufacturing forward, expect the per-user cost on your full users to step up to the Premium rate.

WHY IT MATTERS

If you know manufacturing is coming, it's worth pricing the Premium tier from the start so the budget doesn't shift on you mid-project.

Not everyone needs a full user license

The full Premium license is for the people living in the system day to day: accounting, purchasing, planners. But plenty of your headcount doesn't need that.

• Team Member licenses are inexpensive and cover light use like reading data, running reports, and approvals.
• The device license is for shop floor stations. You license the device rather than a named person, so whoever is standing at that station uses it. Think of it like a shared kiosk.
• A full named user license is only needed if that same person also works from a desktop inside the system, outside of the shared device.

So for a warehouse worker who only scans inventory or logs hours against a job at a shared station, the device license usually does the job. No named user license required on top of it.

The shop floor and warehouse pieces need an add-on

One more thing that surprises people: Business Central does not ship with a full manufacturing execution system or a warehouse management system for barcode scanning, picks, and putaways from a mobile device. If you want that handheld experience on the floor, it comes from an independent software vendor (ISV) add-on that plugs into Business Central.

There are a couple of well-known options for the manufacturing execution piece, and separate tools for the warehouse side. Which one fits depends on how your floor and warehouse actually operate, which is worth mapping out before you commit to a specific product.

A simple way to think about it

If you're weighing Business Central and trying to get a real headcount and cost picture before you sign anything, we're happy to walk through your user mix and shop floor setup and help you figure out where each person lands. No pressure, just a clearer number.