("status", "success"));
```
Counters, gauges, histograms; emitted to backend.
## Semantic conventions
OpenTelemetry defines standards:
- HTTP attributes — method, URL, status.
- Database attributes — system, statement.
- Messaging attributes — destination, operation.
Consistent attribute names enable cross-service analysis.
**Migration from existing observability.**
- **Application Insights SDK** — Microsoft-specific; replace with OpenTelemetry + AppInsights exporter.
- **Custom logging** — gradually replace.
Coexistence possible; full migration over time.
**Performance overhead.**
- Modest; well-designed for production.
- Sampling reduces cost.
- Don't instrument hot loops.
Production-ready performance.
**Trace context in messaging.**
- Service Bus messages carry trace context in properties.
- Event Grid similarly.
- Consumers continue the trace.
Async patterns preserve correlation.
**Trace context in Dataverse.**
- Plug-in receives operation; what's the trace context?
- Custom header passed via HTTP integrations.
- For Dynamics-internal events, requires plug-in pattern.
Capturing context across Dataverse plug-in boundary is the integration point.
**Visualisation.**
- **App Insights end-to-end transaction details** — trace flame graph.
- **Jaeger UI** — open-source.
- **Custom dashboards** — tailored.
Visualisation reveals system behaviour patterns.
**Use cases.**
- **Performance investigation** — where did time go in a slow request?
- **Error correlation** — find related errors across services.
- **Dependency mapping** — what calls what.
- **Capacity planning** — bottleneck identification.
**Common pitfalls.**
- **Over-instrumentation.** Performance degraded; cost explodes.
- **Under-instrumentation.** Gaps in visibility.
- **No context propagation.** Traces broken; can't follow request.
- **Sensitive data in attributes.** Compliance issue.
- **Sampling too aggressive.** Important traces missed.
- **Single backend lock-in.** Defeats OpenTelemetry's purpose.
**Best practices.**
- **Start with auto-instrumentation** for common libraries.
- **Add custom spans** for business operations.
- **Use semantic conventions.**
- **Configure sampling** for cost / visibility balance.
- **Propagate context** through messaging.
- **Document trace topology.**
## Strategic positioning
OpenTelemetry is the modern observability standard. Dynamics 365 integrations using OpenTelemetry get vendor-neutral instrumentation that exports to current and future backends. The investment is modest — replace existing libraries with OpenTelemetry, configure exporters — and pays back in flexibility and depth of visibility.
For architects:
- Default to OpenTelemetry for new code.
- Migrate existing instrumentation gradually.
- Standardise span / metric naming.
- Build dashboards on the foundation.
For organisations on App Insights, OpenTelemetry coexists seamlessly. For others or those wanting vendor flexibility, OpenTelemetry is the path. Either way, it's the direction the observability industry is moving; aligning early reduces future migration burden.
---
# Opportunity stages in Dynamics 365 Sales
How opportunity stages structure sales process in Dynamics 365 Sales — business process flows, stage definitions, win/loss tracking.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-sales-opportunity-stages
Section: Customer Engagement / Sales
Published: 2026-05-01
An opportunity in Dynamics 365 Sales has stages — Qualify → Develop → Propose → Close. Each stage represents a milestone in the sales process. The structure imposes discipline; the discipline produces reliable pipeline forecasts and useful sales analytics. Designing the right stages for your business is one of the most important sales operations decisions.
## The standard process
Out-of-box business process flow for opportunities:
- **Qualify** — early; determine if real opportunity.
- **Develop** — discovery, requirements, solution shaping.
- **Propose** — solution presented, pricing discussed.
- **Close** — final negotiation, signature, won or lost.
Each stage has required fields and exit criteria.
**Customising the stages.**
- Add stages specific to your sales motion.
- Reorder.
- Modify required fields.
- Different processes per opportunity type.
Most organisations customise the standard process to match their reality.
**Common stage variations.**
- **Discovery → Qualification → Value Proposition → ID Decision Makers → Perception Analysis → Proposal → Negotiation → Closed Won/Lost** — Miller Heiman style.
- **Lead → MQL → SQL → Opportunity → Closed** — SaaS funnel.
- **Discovery → Demo → Proposal → Contract → Won** — software sales.
Choose the stages reflecting your actual process; force-fitting an unfamiliar model produces noisy data.
**Stage entry / exit criteria.**
- Each stage has required fields completed before exit.
- Verifiable evidence — meeting notes, signed NDA, signed proposal.
- Approval workflows for advancing stages.
Without criteria, reps advance opportunities by feel — inflated pipeline.
## Probability per stage
Each stage has a default probability:
- Qualify — 10%.
- Develop — 30%.
- Propose — 60%.
- Close — 90%.
Probability × deal value = weighted pipeline; forecasting tool.
## Probability per opportunity
Rep can override default for specific opportunity:
- "This one's almost certain — set 85%."
- "Customer pushing back — drop to 40%."
Manual probability is judgement; over time, calibration improves.
## Forecast categories
Beyond probability:
- **Pipeline** — early; not committed.
- **Best Case** — could win.
- **Commit** — confident.
- **Closed Won** — done.
- **Omitted** — excluded from forecast.
Categories drive forecast roll-up; rep updates as deal evolves.
## Time in stage
A diagnostic metric:
- How long does opportunity typically spend in each stage?
- An opportunity stalled in Develop for 90 days needs attention.
- "Stale opportunity" reports highlight these.
Stage velocity is a leading indicator of pipeline health.
**Win/loss tracking.**
- When closing as Won — record won amount.
- When closing as Lost — record reason (price, competitor, no decision).
- Loss reasons drive coaching and product strategy.
Loss reason data is gold; insist on capture.
**Reopening opportunities.**
- Lost deal sometimes comes back.
- Reopen the opportunity vs create new?
- Best practice: new opportunity, link to original for history.
Maintains forecast clarity; original lost reason remains in record.
## Multiple processes
Different opportunity types may need different stages:
- **New business** — full discovery to close.
- **Renewals** — shorter process; pricing focus.
- **Upsell** — existing customer; relationship-driven.
Multiple business process flows; opportunity type determines which applies.
**Power Apps / model-driven UX.**
- Business process flow visualised across top of opportunity form.
- Click stage to navigate.
- Required fields collapse / expand.
- Visual progress indicator.
This UX makes the process tangible to reps.
**Stage gates and approvals.**
- Some stages require approval to advance.
- "Pricing exception" approval for non-standard discounts.
- "Deal review" before contract.
Stage gates enforce governance.
**Reporting on stages.**
- **Pipeline by stage** — coverage analysis.
- **Conversion rate stage to stage** — bottleneck identification.
- **Average days per stage.**
- **Per-rep stage distribution.**
Pipeline analytics decompose by stages.
**Common pitfalls.**
- **Stages too granular.** 12 stages; reps don't know which they're in.
- **Stages too coarse.** 3 stages; no insight into where deals stall.
- **Required fields ignored.** Reps skip fields; data thin.
- **No stage discipline.** Opportunities advance by inertia; not by criteria met.
- **Probability defaults trusted.** Real probability ignored; forecast wrong.
- **Stale opportunities.** Long-stalled deals clogging pipeline.
**Best practices.**
- **5-7 stages typically.** Enough granularity, not overwhelming.
- **Clear, verifiable exit criteria** per stage.
- **Mandatory loss reason** on lost deals.
- **Periodic pipeline hygiene** — close out stale.
- **Manager review of stages** — coaching opportunity.
**Pipeline hygiene rituals.**
- **Weekly** — pipeline review meetings.
- **Monthly** — stale opportunity cleanup.
- **Quarterly** — process flow refinement.
The rituals are where pipeline value materialises.
## Strategic positioning
Opportunity stages are the operational language of sales. They structure rep activity, enable forecasting, drive coaching, and inform strategy. The setup is one-time; the operational discipline is daily. Mature sales organisations have process flows that match real sales motion, exit criteria that hold, and clean pipeline data they trust. Without these, the system holds opportunities but reveals little useful — pipeline becomes a graveyard rather than a forecast.
---
# Organisation hierarchies in Dynamics 365 Finance and SCM
How organisation hierarchies work in Dynamics 365 Finance and SCM — legal entities, operating units, departments, and the security and reporting they enable.
Source: https://www.solvingdynamics365.com/guides/organization-hierarchies-in-f-and-o
Section: Finance & SCM / Finance
Published: 2026-05-01
The **organisation hierarchy** in Dynamics 365 Finance and Supply Chain Management is the structural backbone of how the system understands the customer's company structure. Security, financial dimensions, intercompany, reporting, workflow routing, and budgeting all hang off it. Getting it right at implementation pays back forever.
**The building blocks.**
- **Legal entity** — the unit of statutory accounting. One legal entity = one set of statutory books, one tax ID, one set of GL postings. A multinational with subsidiaries in five countries has at least five legal entities.
- **Operating unit** — a non-legal-entity organisation unit used for management and operational segmentation: cost centre, value stream, business unit, department, team. Operating units don't have their own GL; they're an analytical / operational layer.
- **Department** — a specific type of operating unit, commonly used as a default financial dimension.
- **Cost centre** — another operating unit type, used for cost accumulation.
- **Worker** — F&O's HR concept of an employee; workers map into operating units through positions.
## Hierarchies
Organisations are connected through **hierarchies** — defined trees that express the relationship between organisation units. F&O supports **multiple parallel hierarchies** for different purposes:
- **Legal hierarchy** — legal-entity ownership structure (parent owns subsidiary). Used for consolidation and intercompany.
- **Reporting hierarchy** — management reporting structure (e.g. global → region → country → operating unit). May differ from the legal structure.
- **Manager hierarchy** — HR-style management reporting structure (people report to people). Used for workflow assignment.
- **Cost centre hierarchy** — budget and cost roll-up structure.
The same operating unit can appear in multiple hierarchies with different parents.
## Why parallel hierarchies matter
Legal structure (who owns what) is rarely the same as management structure (who is responsible for what), which is rarely the same as cost centre structure (where spend is tracked). Forcing all three into one tree creates compromise; parallel hierarchies let each view be honest.
## Effective dates
Hierarchies are *time-aware*: an org unit can move between parents on a specific date, and historical reporting respects the structure at the historical date. Reorgs don't destroy history.
## Security through hierarchies
Security roles can be scoped to specific org units in a hierarchy — "Cost Centre Manager for Operating Unit X and its descendants". The hierarchy is what makes scope feasible without listing every entity manually.
## Workflow assignment
Approval routing uses the manager hierarchy to walk up the chain until an approver with sufficient authority is found. Configure the hierarchy realistically; gaps create routing failures.
## Financial dimensions and hierarchies
Most customers configure key org units (departments, cost centres) as **entity-backed financial dimensions** — so transactions automatically tag the relevant org unit, and the hierarchy can roll up reporting.
## Consolidation
Consolidation companies in F&O reference the legal hierarchy to determine subsidiary inclusion, ownership percentages, and currency translation.
**Common design pitfalls.**
- **Too few hierarchies.** Forcing legal, reporting, and cost views into one tree compromises all three.
- **Too many hierarchies.** Beyond five or six, complexity overtakes value.
- **Reorgs not handled with effective dates.** Just renaming or re-parenting in place destroys historical comparability.
- **Department dimension not aligned with hierarchy.** Reporting roll-ups break when the dimension's parent doesn't match the hierarchy's structure.
## Maintenance
Org hierarchies need maintenance as the business changes — quarterly review keeps them aligned.
---
# Owner teams vs access teams in Dataverse
How Dataverse's two team types differ — owner teams own records and have security roles, access teams grant ad-hoc record-level access — and when to use which.
Source: https://www.solvingdynamics365.com/guides/owner-teams-vs-access-teams-in-dataverse
Section: Customer Engagement / Dataverse platform
Published: 2026-07-04
Dataverse supports two distinct team concepts — **owner teams** and **access teams** — that look similar but solve different problems. Understanding the distinction is essential for designing security cleanly.
**Owner teams.**
An **owner team** is a group of users that can own records and have security roles assigned. Owner teams behave like users in many ways:
- A record can be **owned by an owner team** (the Owner field references the team, not a user).
- The team has **security roles** assigned; team members inherit those roles when the team owns the record.
- All team members get the same access — equal members.
- Records owned by the team are queryable as "team-owned" in views and reports.
Use cases:
- A regional sales team collectively owns regional accounts and opportunities. Records routed to the team; any team member can work them.
- A customer-service queue is owned by the queue team; members process from the shared queue.
- A project team owns project-related records during the engagement; deactivated on project end.
Owner team membership is stable — you add and remove members through team administration. Changes affect all team-owned records' visibility for added / removed members.
**Access teams.**
An **access team** is a lightweight, dynamic group used for **ad-hoc record-level access**. Unlike owner teams:
- Access teams **can't own records** directly.
- Access teams are typically **created per record** dynamically.
- Access teams grant **specific record-level privileges** (read, write, append, share) without granting broader access.
- Access teams are managed through **access team templates** that define what privileges members get.
The classic use case: a sales rep adding ad-hoc collaborators to a specific opportunity. The rep adds three colleagues to the opportunity's access team; those three get read / append access just to that opportunity for the duration. When the opportunity closes or members leave the team, access is removed.
## Auto-created access teams
Access teams are commonly **auto-created** when a record's "team" subgrid is populated:
1. On the opportunity form, a "Sales Team" subgrid lists users with access.
2. Adding a user to the subgrid (with an access role: "Account Manager", "Technical Specialist", "Executive Sponsor") triggers:
- The access team for that opportunity is created (if not already).
- The user is added with the appropriate role's privileges.
3. The user gains record-level access to that specific opportunity.
The user doesn't need a broad security role granting access to all opportunities — they have access to just this one through the access team.
**Comparison.**
| Aspect | Owner team | Access team |
|---|---|---|
| Owns records | Yes | No |
| Security roles | Yes (assigned to team) | No (roles per template) |
| Visibility | Records owned by team are team-visible | Records shared via access team are member-visible |
| Membership stability | Stable | Often dynamic per record |
| Use case | Shared ownership of many records | Ad-hoc per-record collaboration |
**Choosing.**
- **Owner team** when a group of users collectively owns a collection of records (regional teams, service queues, project teams).
- **Access team** when an individual record needs additional access beyond its primary owner (deal team, case escalation, project consultant).
Both can be used in the same environment for different scenarios.
## Microsoft 365 group integration
Owner teams can be linked to **Microsoft 365 groups** — sync membership from M365 group to Dataverse owner team. Useful when team composition is already managed in M365 (Teams, SharePoint, Exchange group structures).
## Manager and position hierarchies
Owner teams don't replace hierarchical security; they coexist. A user might have:
- Security role X (granting BU-scoped access).
- Owner team Y membership (granting team-scoped access).
- Hierarchical security depth 2 (granting access to direct and indirect reports' records).
The user's effective access is the union of all three.
**Limits.**
- **Access team templates** are bound to a specific table — you can't share one template across many tables.
- **Auto-created access teams** can produce many small access teams over time; Dataverse cleans up automatically but heavy use creates schema clutter.
- **Owner teams' members can't easily be drilled out** for record-by-record access — it's all-or-nothing.
**Common pitfalls.**
- **Using owner teams for ad-hoc collaboration** — produces many narrow owner teams; admin nightmare. Use access teams.
- **Using access teams for systematic ownership** — auto-creation overhead, no central security-role assignment. Use owner teams.
- **Manager hierarchy plus owner team** — overlapping access can be confusing; users see the same record via multiple paths.
## Operational reality
Modern Dynamics 365 implementations use both: owner teams for systematic ownership patterns, access teams for ad-hoc per-record collaboration. The two together enable rich security models without forcing every user into restrictive global roles.
### Frequently asked questions
**What is the difference between an owner team and an access team?**
An owner team can own records and carries security roles that its members inherit — stable membership, systematic ownership. An access team cannot own records; it grants specific privileges on one record to a dynamic set of collaborators through an access team template.
**When should I use an access team?**
For ad-hoc per-record collaboration — a deal team on an opportunity, an escalation on a case. Members get read, write, or append on that record only, without a broad security role granting access to every opportunity.
**How are access teams created automatically?**
Through a team subgrid on the form backed by an access team template. Adding a user to the subgrid creates the record's access team if needed and grants that user the template's privileges.
**Can owner teams sync with Microsoft 365 groups?**
Yes. An owner team can be linked to a Microsoft 365 group so membership managed in Teams, SharePoint, or Exchange flows into Dataverse.
**Do teams replace hierarchical security?**
No. A user's effective access is the union of security roles, owner team membership, access team grants, and hierarchical security depth — they coexist.
---
# Page personalization in Business Central
How Business Central users personalize pages — column choices, layouts, FactBox visibility, and the line between personalization, customization, and extension.
Source: https://www.solvingdynamics365.com/guides/business-central-page-personalization
Section: Business Central / Admin & ops
Published: 2026-05-01
Updated: 2026-08-25
Business Central users can reshape the pages they work with daily — hiding columns they don't need, moving FactBoxes, adjusting layouts, all without admin or developer involvement. This **personalization** is per-user, persistent, and one of the underrated productivity features in BC.
**What's personalizable.**
- **Column visibility and order** in list pages.
- **Field visibility** on card pages.
- **FactBox visibility** on the right pane.
- **FastTabs collapse / expand** default state.
- **Action visibility** in the ribbon.
A user removing 10 unused columns from the Sales Orders list page sees only what they care about.
**How to personalize.**
1. **Settings → Personalize** (or top-right gear icon).
2. The page enters personalization mode — controls highlight.
3. Click on items to hide / show / move.
4. **Clear personalization** to revert.
5. Personalization saved per user, per page, per role.
**Personalization vs customization vs extension.**
- **Personalization** — per-user; the user's own view.
- **Customization** — per-role / per-company; visible to all users with that role.
- **Extension** — per-tenant or app-source level; modifies the application.
Three layers, three audiences, three lifecycles.
## Customizing for a role
Admins can:
- Use **Customize** mode to change defaults for a role centre.
- The customization applies to all users with that role.
- Users can still personalize on top of customizations.
The layering: extension defines defaults → role customization overrides → user personalization further overrides.
**Profile management.**
- Each user assigned a **Profile** (Role Center).
- Profiles can be customized for the company.
- New users get the profile's customized state as their default.
For organisations with distinct roles (warehouse worker vs finance manager), profile-based customization standardises starting state per role.
**Configuring page parts visibility.**
- Some FactBoxes are always heavy (related entries with summary). Hiding them improves page load.
- Some users prefer wider main area, less side content.
Personalization gives each user control without affecting peers.
**Clearing all personalization.**
- **Clear personalization** action removes user's per-page personalizations.
- Useful when a user has accidentally hidden critical fields.
- Admins can clear personalizations for any user.
## Reset application area
Application areas are a related concept:
- **Basic** — minimal feature set.
- **Essential** — standard.
- **Premium** — all features.
Set on the **Company Information** page; affects which fields and pages appear. Different from personalization but conceptually similar — controls what's visible.
## Personalization in mobile apps
The BC mobile app has more limited personalization:
- Some column visibility.
- Less rearrangement.
- Reflects desktop personalization where possible.
**Common pitfalls.**
- **Critical fields hidden.** User can't find them; thinks system is broken.
- **Personalization across role changes.** User moves to new role; their personalizations from old role linger.
- **No reset training.** Users don't know they can clear; suffer broken layouts.
- **Mistaking personalization for customization.** Changes apply only to one user; others ask why their view differs.
## Audit considerations
Personalization changes aren't typically audit-tracked — it's user UI state. For regulated environments, customizations and extensions are tracked; personalization isn't.
## Strategic positioning
Personalization is a quiet productivity feature. Mature BC deployments train users to use it deliberately — making the system feel tailored to each role without admin overhead. The investment is brief training; the payback is daily productivity. Underused in most deployments; worth surfacing as part of onboarding and ongoing tips.
---
# Parallel currencies in Dynamics 365 Finance
How Dynamics 365 Finance handles parallel reporting currencies — accounting currency, reporting currency, and tax currency, with the consolidation implications.
Source: https://www.solvingdynamics365.com/guides/parallel-currencies-in-finance-and-operations
Section: Finance & SCM / Finance
Published: 2026-05-01
Dynamics 365 Finance handles multi-currency natively, and where Business Central supports an additional reporting currency, F&O takes it further with up to four parallel currencies on every transaction. Understanding which currency is which prevents many of the most embarrassing reporting errors at consolidation.
**The currency dimensions of a transaction.**
- **Transaction currency** — the currency the transaction itself was conducted in. A purchase invoice from a German supplier is in EUR.
- **Accounting currency** — the legal entity's primary statutory currency. The Spanish subsidiary's accounting currency is EUR; the US subsidiary's is USD; the Swedish subsidiary's is SEK. Every GL posting in the entity is stored in accounting currency.
- **Reporting currency** — a second parallel currency to accounting currency, typically the parent group's currency. Configured per legal entity. Every GL posting is also stored in reporting currency at the same time, using rates from the configured exchange-rate type. The result: a Spanish subsidiary's GL can produce reports in both EUR (statutory) and USD (group reporting) without consolidation FX translation.
- **Tax currency** — for some country localizations, statutory reporting requires a third currency layer (e.g. local-tax-authority currency in a foreign-currency-economy country). Configured per legal entity.
## Exchange-rate types
Different transactions can use different rates. F&O has multiple **exchange rate types** — Spot, Average, Period-end, Budget, etc. Each transaction type can be configured to use a specific rate type for accounting-currency conversion and a different rate type for reporting-currency conversion.
## The exchange-rate table
Rates are maintained per rate type, per currency pair, per starting date. Manual entry, file import, or service-based feeds (Microsoft ships connectors for some central banks, partner ISVs publish more). Rates have starting dates so historical postings re-translate consistently.
## Revaluation
Period-end revaluation runs separately for accounting-currency open balances (e.g. open AR/AP in foreign currency converted at period-end rate to accounting-currency) and for reporting-currency revaluation (the same balances re-translated to reporting currency at the new rate).
## Realised FX
When a foreign-currency invoice is settled at a different rate, realised FX gain/loss posts. F&O posts it in both accounting and reporting currency, with the correct calculation in each.
## Consolidation
When the parent consolidates subsidiaries, two options:
- **Consolidation in F&O.** Source companies feed their trial balances (in their accounting currency, often *plus* their reporting currency for the parent's view) into a designated consolidation company. F&O applies currency translation at consolidation-rate types (current rate, historical rate, average rate as configured), eliminations, and adjustments to produce group financials.
- **Consolidation outside F&O.** Larger groups feed F&O data into a dedicated consolidation tool (OneStream, Workiva, Hyperion, SAP BPC) for sophisticated consolidation logic. F&O acts as the source.
## Subsidiaries with parent reporting currency in operating data
A common pattern: every subsidiary's reporting currency is set to the parent's group currency. Each subsidiary's GL is queryable directly in group currency without consolidation. Operational dashboards in Power BI work across the group without complex transformations.
**Common pitfalls.**
- **Setting reporting currency only at the end of year 1.** Now reporting currency starts from year 2, leaving year 1 with no historical group-currency baseline. Set reporting currency from go-live.
- **Inconsistent exchange-rate types.** Different rate types on different transactions produce non-reconcilable totals. Standardise.
- **Manual rate maintenance.** Forgotten rate updates cause posting failures or wrong rates. Use automated rate feeds.
---
# Patient engagement with Customer Insights – Journeys in healthcare
How healthcare organisations use Dynamics 365 Customer Insights – Journeys for patient outreach.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-for-healthcare-patient-engagement
Section: Industries / Healthcare & life sciences
Published: 2026-09-02
Hospitals and health systems already send appointment reminders from their electronic health record. So the first question for a patient-engagement project on Dynamics 365 **Customer Insights – Journeys** is not "can it send reminders" but "what should it do that the EHR does not". Answered well, Journeys becomes the outreach layer for population health, care-gap closure, service-line growth, and post-discharge follow-up. Answered badly, it duplicates the EHR's reminders with a second consent problem. This guide covers the use cases that justify the product in healthcare, and the constraints that PHI imposes on how it is used.
## Use cases that earn their place
- **Preventive care and care-gap outreach.** Patients due for a screening, a vaccination, or a chronic-condition check, identified from claims or EHR data, receive a sequence of messages with a scheduling link. The EHR can generate the list; it is poor at multi-step, multi-channel sequences with response handling.
- **Post-discharge and post-procedure follow-up.** A journey triggered by a discharge event sends instructions, checks in at intervals, and escalates a concerning response to a care coordinator's queue in Customer Service.
- **Service-line and access marketing.** New clinic openings, telehealth availability, and health-education content to consenting community members — closer to conventional marketing, and where the healthcare-specific rules bite hardest.
- **Referral and provider engagement.** Outreach to referring physicians is a B2B journey with none of the PHI constraints, and often the fastest win.
- **Patient experience follow-up.** Surveys after visits through Customer Voice, feeding a satisfaction measure and an alert on low scores. This is not a substitute for regulated patient-experience surveys such as CAHPS, which have their own vendors and rules.
Appointment reminders belong in the EHR unless the organisation has a specific reason — multi-channel preference handling, integrated rescheduling in Customer Service — to move them.
## The Cloud for Healthcare layer
Microsoft's **Cloud for Healthcare** includes a patient-outreach capability built on Customer Insights – Journeys and the healthcare data model, plus the connectors that bring FHIR data into Dataverse through Azure Health Data Services. It adds patient, encounter, and condition tables with their healthcare semantics, and templates for common journeys. It is worth adopting for the data model alone, because it prevents each project inventing its own patient table. The [Cloud for Healthcare](https://www.solvingdynamics365.com/guides/microsoft-cloud-for-healthcare) guide covers what it adds and what it costs.
## Consent is not a checkbox
HIPAA's marketing rules and state laws distinguish treatment and care-coordination communications (permitted without authorisation) from marketing (generally requiring authorisation, with narrow exceptions). The TCPA governs automated SMS and calls separately. Journeys' **consent centre** models consent by purpose and topic per contact point, which maps well onto this if the purposes are defined properly:
- A **treatment and care communications** purpose, defaulted on for patients, covering follow-up and care-gap outreach.
- A **health and wellness marketing** purpose, opt-in only, for service-line and education content.
- **Channel-level consent** for SMS separate from email, with the SMS keyword opt-out handled by the platform.
Compliance and legal decide which journeys fall under which purpose; the marketing team should not be making that call at journey-design time. Encode the decision as a required field on the journey's approval.
## PHI in messages, segments, and triggers
The presence of a diagnosis in a message, a segment name, or a trigger payload makes it PHI, and the organisation should treat the whole Journeys environment as a PHI system under its business associate agreement.
- **Messages** reference the action, not the condition. "You are due for your annual eye check" is better than a message naming the reason.
- **Segment names and descriptions** are visible to every marketer in the environment. A segment called by its clinical criteria has just disclosed those criteria to everyone with access. Name by campaign, keep criteria in a governed field.
- **Custom triggers** carry attributes into the journey. Send identifiers and the minimum needed to branch, and keep clinical detail in the source system.
- **Dynamic content** from patient records is a common leak: a personalised block that pulls a condition field into an email body is PHI in transit through the email provider.
- **Attachments and links** should point to the patient portal, where authentication protects the content, rather than embedding results or documents.
The [HIPAA-aware Customer Service](https://www.solvingdynamics365.com/guides/dynamics-365-for-healthcare-hipaa-customer-service) guide covers the security roles, auditing, and retention that apply to the same environment.
## Channels and triggers
Email and SMS are the working channels. SMS in Journeys runs through supported providers — Azure Communication Services and third-party carriers — and the organisation needs a compliant sender registration in its country. Push notifications require a mobile app. Voice is not a Journeys channel; outbound calls are Customer Service or a contact-centre product.
Triggers come from Dataverse events (a discharge record created, a care-gap record updated) or from custom triggers raised by integration — a FHIR subscription on the EHR firing an Azure Function that raises the trigger. Batch-based journeys from segments refreshed on a schedule are simpler and usually good enough for care-gap outreach; event-based journeys are for the follow-up scenarios where timing matters.
## Measurement
Journeys reports opens, clicks, and goal attainment. For healthcare the goal is downstream: the screening booked, the follow-up completed, the readmission avoided. Closing that loop means the outcome event flowing back — an appointment created in the EHR, a care-gap closed — either into Dataverse for the journey's goal or into Power BI joined on patient identifier. Without it, the programme reports engagement rates to a clinical leadership that does not care about engagement rates.
## What stays with partners and the EHR
Patient portals, appointment self-scheduling, and clinical messaging are EHR functions or specialist products; Journeys links to them. Identity verification for patients accessing content is a portal or Entra External ID problem. Consent capture at registration usually happens in the EHR and flows into Journeys, which means an integration that keeps consent in sync in both directions — the part of these projects most often left until last and most often the cause of the first complaint.
---
# Payment journals deep dive in Business Central
How the payment journal works in Business Central — suggesting vendor payments, applying entries, payment proposals, payment methods.
Source: https://www.solvingdynamics365.com/guides/payment-journals-deep-dive-in-bc
Section: Business Central / Finance & accounting
Published: 2026-05-01
The **payment journal** is the workhorse of AP cash outflow in Business Central. It batches vendor payments into a single review-and-post cycle, applies them against open invoices, generates payment files for the bank, and writes the bank ledger entries that flow into reconciliation. Most BC finance teams run it once or twice a week.
## Where it lives
Navigation: `Finance → Payment Journals` or via search. The page shows lines like a journal — each line is one payment (one vendor, one amount, one bank account, one application). The template `PAYMENT` and a batch (often `WEEKLY` or `DAILY`) determine the posting setup.
## Suggesting payments
The `Suggest Vendor Payments` action pre-fills the journal with proposed payments. Parameters:
- **Last Payment Date** — only invoices due on or before this date.
- **Find Payment Discounts** — include payment-discount lines for invoices within the discount window.
- **Available Amount (LCY)** — cap by cash available.
- **Posting Date** — the payment date.
- **Starting Document No.** — the number series start for posted payments.
- **Bank Payment Type** — Manual, Computer Check, Electronic Payment, etc.
- **Bal. Account No.** — the bank account to draw from.
- **Summarise per Vendor** — one line per vendor totalling invoices, vs. one line per invoice.
The action populates the journal with a draft batch the finance team then reviews and adjusts.
## Application
Each payment line carries `Applies-to Doc. Type` and `Applies-to Doc. No.` — pointing to the invoice being paid. Summarised lines use `Applies-to ID`, with multiple invoices flagged. Without an application, the payment posts as an unapplied vendor payment that has to be reconciled later.
## Payment methods
The vendor card's **Payment Method Code** drives default behaviour:
- **CHECK** — a printed check; posts via Check Printing.
- **BANK** — an electronic bank transfer (ACH, BACS, SEPA, depending on locale).
- **CASH** — manual.
Payment methods also drive which bank account format applies and whether the export goes through SEPA, NACHA, EFT files.
## Bank Payment Type
A second axis on the line:
- **Manual Check** — physical check, no printing through BC.
- **Computer Check** — BC prints the check.
- **Electronic Payment** — generates an electronic export file.
- **Electronic Payment-IAT** — international ACH.
## Generating bank files
With `Bank Payment Type = Electronic Payment`, the `Export` action on the payment journal calls a **Data Exchange Definition** specific to the bank account's payment export format and produces the file. SEPA Credit Transfer (Europe), NACHA (US), BACS (UK) are the common ones; per-country localisations add others. The file is uploaded to the bank portal or exchanged via a bank connector.
## Voiding before posting
Until the journal posts, lines are mutable. If a vendor calls to dispute an invoice mid-cycle, the line can be deleted. After posting, the cycle is to void/reverse the payment (creates a counter entry).
**After posting.**
- **Bank Account Ledger Entry** is written reducing cash.
- **Vendor Ledger Entry** is written (negative — paying down balance).
- **Detailed Vendor Ledger Entry** records the application.
- **G/L Entry** captures the journal effect: debit AP, credit Bank.
- **Posted Payment Reconciliation Lines** seed the bank reconciliation.
## Payment discounts
When an invoice carries a payment discount and the payment lands within the discount window, the payment journal calculates the discount as a separate line (vendor discount G/L account). Vendors get a small `Pmt. Disc. Tolerance Date` field for grace. Done well, payment discounts often outweigh interest cost on the cash; mature AP automates the analysis.
**Common pitfalls.**
- **Unapplied payments.** Forgetting to apply leaves a credit on the vendor account; reconciliation gets messy.
- **Wrong posting date.** A payment dated in a closed period either fails or posts into the next; closing schedule must lead AP.
- **Bank file rejected.** Bank returns the file; need to void posted payments, fix bank info, re-run. Test bank exports with a real (small) payment before launching electronic payments.
- **Currency mismatch.** Payment in EUR against an invoice in USD with no FX setup → posting fails. Always set up cross-currency posting groups.
- **Tolerances misconfigured.** Payment discount tolerances allow partial discounts on slightly late payments. Set them once, document them.
## Operational rhythm
A high-volume AP shop runs the payment journal twice weekly. Mature teams run a "dry run" earlier to identify problems (missing approvals, blocked vendors, currency issues) and fix them before the production run.
---
# Payment terms and methods in Business Central
How Business Central models payment terms, payment methods, payment discounts, and the integration with bank file generation.
Source: https://www.solvingdynamics365.com/guides/payment-terms-and-methods-in-business-central
Section: Business Central / Finance & accounting
Published: 2026-05-01
Two pieces of master data govern how Business Central handles customer and vendor payments: **payment terms** (when payment is due and what discount applies for early payment) and **payment methods** (how the payment is made). Configured well, the two collapse what would otherwise be manual reasoning into automatic calculation on every transaction.
## Payment terms
A **payment term** carries:
- **Due Date Calculation** — a formula like `30D` (30 days), `1M` (one month), `CM` (current month-end), `1M+10D` (month-end plus 10 days). Applied to the document date to compute the due date.
- **Discount Date Calculation** — formula for the *early payment* discount cutoff date.
- **Discount %** — the percentage discount earned if paid by the discount date.
- **Calculate Pmt. Disc. on Cr. Memos** — whether the discount applies to credit memos as well as invoices.
Common payment terms:
- **Net 30** (`30D`, 0%) — pay within 30 days, no discount.
- **2/10 Net 30** (`30D`, 2%, discount date `10D`) — pay within 10 days for 2% off, otherwise 30 days net.
- **End of Month + 30** (`CM+30D`) — pay 30 days after the month-end of the invoice date.
- **Cash on Delivery** (`0D`) — payment with delivery.
Customers and vendors carry a default payment term that flows onto each document; users can override at the line.
## Payment methods
A **payment method** carries:
- **Code and Description** — Bank Transfer, Cash, Cheque, Direct Debit, Credit Card, Bank File.
- **Balancing Account** — the GL account where the offset posts when a sales invoice with this method is posted. For "Cash" payment, the invoice posts both the AR and the cash GL account in one step; for "Bank Transfer", AR remains open until the bank receipt is recorded separately.
- **Bal. Account Type** — GL Account or Bank Account.
- **Direct Debit-related** properties — pre-authorisation, mandate references.
- **Payment Export properties** — controlling which bank file format applies.
## Combined effect
A sales invoice posted with payment term "Net 30" and payment method "Cash" creates the AR ledger entry and immediately posts the cash receipt. The same invoice with payment method "Bank Transfer" creates only the AR entry; the receipt comes later when the bank statement is reconciled or the payment journal posts.
## Payment journals
Vendor payments are typically processed through the **payment journal** — a batch of payment lines selected from open vendor invoices, filtered by due date or payment method, generating a bank file (SEPA, ACH, BACS, Norwegian KID, Swedish SUS, etc.) for upload to the bank. The journal posts the payment, applying it to the original invoices and updating bank balances.
## Suggest Vendor Payments
A built-in routine reviews open vendor invoices and proposes which to pay, based on filters: payment method, due date, available cash. The user reviews and adjusts before posting.
## Customer Direct Debit
A separate process for **customer direct debits** generates pre-authorised bank-debit files for customers on direct-debit payment methods.
## Configuration discipline
Standardise payment terms — a tenant rarely needs more than 8–12 distinct terms. Same for payment methods — bank transfer, direct debit, credit card, cash, and a few exceptions cover most operations. Resist proliferation.
---
# PCF controls in Power Apps
What Power Apps Component Framework (PCF) controls are, when to use them, and the developer toolchain to build, package, and deploy.
Source: https://www.solvingdynamics365.com/guides/pcf-controls-in-power-apps
Section: Power Platform / Power Apps
Published: 2026-05-01
The **Power Apps Component Framework (PCF)** lets developers build custom UI controls in TypeScript and ship them as reusable components inside model-driven apps and canvas apps. They're how you cross the boundary between Power Apps's built-in controls and pixel-perfect custom UI, without leaving the platform.
## What PCF is
A PCF control is a self-contained TypeScript bundle (HTML + CSS + TS, optionally with React inside) that the Power Apps runtime hosts inside a form, view, or canvas screen. The control exposes input parameters (bound to Dataverse columns or canvas variables), receives a `context` object with data and APIs, renders UI, and writes back via the platform's APIs. To the user, the control feels native; to the platform, the control is a packaged solution component.
**When to use a PCF control.**
- **Model-driven app forms** where the default field controls don't fit: a slider, a colour picker, a custom rating widget, a map embedding, a barcode scanner, a Gantt chart, a kanban board.
- **Model-driven views** where the standard grid isn't enough: a custom card view, a calendar view, an editable spreadsheet view.
- **Canvas apps** where the built-in controls don't deliver a needed UX pattern.
- **Reusable across many apps and customers** — author once, package once, install many times.
## When not to use PCF
Simple display tweaks belong in form configuration. Complex business logic belongs in JavaScript event handlers, Power Automate, or Dataverse plug-ins. PCF is specifically for *UI components* that present and capture data in non-standard ways.
**The toolchain.**
- **Power Platform CLI (`pac`)** — the command-line tool for scaffolding, building, packaging, and pushing PCF projects.
- **Visual Studio Code** — the editor of choice, with TypeScript and React extensions.
- **Node.js** — required for the build.
- **TypeScript** — the language. Microsoft provides type definitions for the PCF API.
## Project structure
A PCF project contains:
- `ControlManifest.Input.xml` — the manifest declaring the control's name, input parameters, output events, and metadata.
- `index.ts` — the entry point implementing `IInputs`/`IOutputs` interfaces with `init`, `updateView`, `getOutputs`, `destroy` methods.
- React or vanilla DOM code rendering the actual UI.
- CSS for styling.
## Packaging and deployment
`pac pcf init` scaffolds a project; `pac pcf push` builds and pushes to a Dataverse environment for testing; `pac solution add-reference` adds the PCF project to a solution; the solution exports as managed and installs into target environments. Source control lives in Git.
## Performance
PCF controls run client-side in the user's browser. Heavy rendering or large data fetches degrade the form load time. Use virtualisation for long lists, lazy-load images, batch Dataverse Web API calls. Profile in Chrome DevTools.
## Distribution
PCF controls can be shipped as part of an ISV's AppSource solution, made internal to one customer through a custom solution, or open-sourced (the **PCF Gallery** at pcf.gallery is a community-maintained catalogue of free PCF controls).
**Limits.**
- PCF controls don't have access to all Dataverse SDK methods; the `context.webAPI` is the standard data path.
- Some browser APIs (clipboard, geolocation) need permissions.
- Authoring PCF requires developer skill — this is genuine code, not low-code.
## Operational reality
A small PCF library — 5 to 15 controls — covers most customers' bespoke UI needs without ever requiring more.
---
# Per-tenant extensions vs AppSource
When to ship a Business Central extension as a per-tenant (PTE) vs publishing to AppSource — distribution, validation, and lifecycle differences.
Source: https://www.solvingdynamics365.com/guides/per-tenant-extensions-vs-appsource
Section: Business Central / AL & development
Published: 2026-05-01
Business Central extensions ship via two paths: a **per-tenant extension (PTE)** delivered directly to one customer's tenant, or a **published app on AppSource** delivered to the broader market. The same AL source can produce either; what differs is the lifecycle, validation, and economics around it.
## Per-tenant extensions
A PTE is uploaded to one specific BC environment from the admin centre. The owner can be the customer's internal team or a partner working for that customer. PTEs are great for organisation-specific customisations — bespoke fields, custom integrations, unique workflows — that aren't reusable across multiple customers. They don't go through Microsoft's marketplace validation, so they ship as fast as you build them. They're invisible to other tenants.
## Trade-offs of PTE
Speed, freedom from marketplace rules, and full ownership. But: you carry every upgrade burden yourself. Each Business Central release wave can break a PTE; the partner has to recompile it against the new platform and republish. Microsoft does not pre-test PTEs before the update window.
## AppSource apps
An AppSource app is submitted to Microsoft for **validation** (technical, security, performance, and content review), then published in the marketplace, where any BC customer can install it. AppSource is the only way to *sell* a packaged Business Central extension to multiple customers.
## The economics
Microsoft makes AppSource apps **transactable** — billed through Microsoft's commerce platform, with revenue share. ISVs can also use *contact me* listings for sales handled offline. The economics work because the cost of validation and the platform fee are amortised across many tenants.
## The lifecycle
AppSource apps get **early access to preview builds** and Microsoft pre-tests them against upcoming release waves, flagging breaking changes well before customers update. That ongoing certification is the biggest operational reason to publish to AppSource even if you only have one initial customer.
## Choosing
Build as a PTE when the code is genuinely one-customer-only. Build for AppSource when you expect to deliver the same functionality across multiple tenants, when the code is generic enough to package, or when you want Microsoft's compatibility safety net.
## Hybrid
Many customer projects combine a small PTE for bespoke needs with several AppSource apps from ISVs for localizations, integrations, and vertical features. This is the normal shape of a Business Central solution.
### Frequently asked questions
**What is a per-tenant extension?**
An AL extension uploaded to one specific Business Central environment from the admin centre — for customer-specific fields, integrations, and workflows. It skips Microsoft's marketplace validation, ships as fast as you build it, and is invisible to other tenants.
**What does AppSource validation give me?**
Microsoft pre-tests AppSource apps against upcoming release waves and gives ISVs early access to preview builds, so breaking changes surface before customers update. Per-tenant extensions get no such safety net — you recompile and republish yourself each wave.
**Can I sell a Business Central extension without AppSource?**
Not as a packaged product to multiple customers. AppSource is the only marketplace route; Microsoft makes apps transactable with revenue share or lets ISVs use contact-me listings for offline sales.
**What does a typical customer solution look like?**
A small per-tenant extension for bespoke needs plus several AppSource apps from ISVs for localisations, integrations, and vertical features. That hybrid is the normal shape of a Business Central solution.
---
# Performance management in Dynamics 365 Human Resources
How D365 HR supports performance reviews — goals, journals, reviews, calibration, and the integration with development planning.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-hr-performance-management
Section: Customer Engagement / Human Resources
Published: 2026-05-01
Performance management is one of HR's most strategically important functions and one of its most disliked. **D365 Human Resources** provides goal tracking, performance journals, review workflows, and calibration tools. The tooling is reasonable; the value depends on how leadership wires it into ongoing management cadence rather than treating reviews as annual paperwork.
**Performance entities.**
- **Goal** — what the employee aims to accomplish in a period.
- **Performance journal** — ongoing notes by employee or manager (positive feedback, areas for improvement, evidence).
- **Performance review** — periodic assessment (annual, semi-annual, quarterly).
- **Calibration** — leadership-level comparison across employees to standardise ratings.
- **Development plan** — tied actions for career growth.
## Goals
Two perspectives:
- **Individual goals** — specific to the employee.
- **Cascade from organisational goals** — strategic initiatives broken into team and individual contributions.
Goals have:
- **Objective statement.**
- **Measurable outcome** — quantitative if possible.
- **Due date.**
- **Status** — Not Started, In Progress, At Risk, Completed.
- **Weight** — % of overall performance attributed.
- **Linked org goal** — for cascade traceability.
OKR-style frameworks fit naturally in this model — each goal is an Objective with measurable Key Results.
**Goal cadence.**
- **Annual goal setting** — at start of performance year.
- **Quarterly check-ins** — review progress, adjust if conditions changed.
- **Year-end review** — assess outcomes.
Goals that don't change after being set are usually unrealistic. Mid-year reassessment is healthy.
## Performance journal
A timestamped log of evidence:
- Employee adds entries reflecting accomplishments.
- Manager adds entries with observations.
- Peer feedback gathered (optional).
- Customer feedback (if applicable).
The journal is the antidote to "recency bias" in annual reviews — without journaling, only the last 6 weeks are remembered.
**Review cycles.**
- **Self-assessment** — employee fills out review form.
- **Manager assessment** — manager fills out review form.
- **Discussion meeting** — review conversation.
- **Sign-off** — both parties acknowledge.
- **HR submission** — final record submitted.
Variations: skip-level review (manager's manager input), 360-degree (peers, direct reports).
## Rating scales
Common patterns:
- **5-point scale** — Below Expectations / Meets / Exceeds / Far Exceeds / Outstanding.
- **3-point** — Below / Meets / Exceeds.
- **No rating** — narrative-only.
Configuration determines the scale and the labels.
## Calibration
A practice where leadership reviews proposed ratings across the team:
- **Spread the ratings** — ensure not everyone is "Exceeds."
- **Compare across managers** — one manager's 4 is another's 3.
- **Justify outliers** — top 10% and bottom 10% specifically discussed.
- **Adjust pre-conversation** — calibrated ratings used in the actual review.
Calibration is a process, not a system feature, but D365 HR can capture pre- and post-calibration ratings for audit.
## Compensation linkage
Performance often drives:
- **Merit increases** — base salary adjustments by performance.
- **Bonus payouts** — bonus tied to performance score.
- **Promotion eligibility** — sustained high performance.
Configurable rules link rating tiers to comp outcomes; HR reviews and approves.
## Development plans
Beyond rating, what the employee should work on:
- **Skills to develop** — specific competencies.
- **Learning resources** — courses, mentoring, projects.
- **Stretch goals** — assignments outside normal scope.
- **Career path** — roles toward which the employee is developing.
Linked to LinkedIn Learning, Microsoft Learn, internal LMS for content access.
## Continuous feedback
Modern practice moves beyond annual reviews:
- **Weekly 1:1s** — manager and employee check in.
- **Monthly mini-reviews** — light touch on goals.
- **Real-time recognition** — peer-to-peer kudos.
D365 HR supports lightweight continuous feedback through performance journal entries and Microsoft Viva integration.
## Microsoft Viva integration
Viva Goals, Viva Learning, Viva Insights complement D365 HR:
- **Viva Goals** — modern OKR platform; can sync with D365 HR goals.
- **Viva Learning** — content delivery; tracks completions linked to development plans.
- **Viva Insights** — productivity insights; private to employee.
The Viva ecosystem is Microsoft's broader employee experience play; D365 HR is the system of record for HR data.
**Reporting.**
- **Review completion rate** — % of employees with reviews completed on time.
- **Rating distribution** — across departments, managers.
- **Goal achievement rate** — % of goals met.
- **High-potential pool** — employees identified for growth.
- **At-risk** — performance trending down.
**Common pitfalls.**
- **Goals set once, never revisited.** Forgotten until year-end.
- **No journaling.** Year-end review based on recent memory only.
- **Ratings inflation.** Everyone rated "exceeds"; calibration absent; signal lost.
- **Review fatigue.** Quarterly reviews become checkbox; quality drops.
- **Comp disconnected.** Performance ratings don't flow to comp decisions; demotivates.
- **No development action.** Review identifies development needs; nothing happens; same problems next year.
## Operational rhythm
Goal setting at year start; quarterly check-ins; mid-year informal review; annual formal review; comp decisions tied to outcomes. The rhythm is human — the system supports it, doesn't drive it. Effective performance management is a leadership behaviour, not a software feature.
## Strategic positioning
Performance management is where employee development, retention, and organisational capability meet. Done well, it's the engine of growth; done badly, it's a demoralising bureaucratic exercise. D365 HR provides the framework; the work of making it valuable belongs to leaders and HR business partners. The system can't substitute for the conversations.
---
# Periodic processes in Dynamics 365 Finance and SCM
The recurring routines that drive month-end, year-end, and ongoing operations in F&O — period close, posting flushes.
Source: https://www.solvingdynamics365.com/guides/periodic-processes-in-f-and-o
Section: Finance & SCM / Finance
Published: 2026-05-01
Dynamics 365 Finance and SCM runs a substantial library of **periodic processes** — batch routines that handle period close, post pending transactions, recalculate balances, generate statutory reports, and maintain operational data. Knowing which to run when separates well-operated tenants from chaotic ones.
## The four cadences
Most periodic processes fall into one of four cadences:
- **Daily** — operational continuity routines.
- **Weekly** — operational hygiene and lighter reconciliations.
- **Monthly** — period close.
- **Quarterly / Annually** — statutory and long-cycle.
**Daily processes.**
- **Master planning runs** — depending on the operation, planning runs nightly to refresh supply against demand.
- **Cost recalculation (incremental)** — keep inventory costs current.
- **Currency exchange rate import** — fetch the day's rates.
- **Sales / purchase order picking and shipping** — ongoing operations.
- **Bank statement imports** — for tenants with bank feeds.
- **Job queue health checks** — review failed batches.
**Weekly processes.**
- **Customer / vendor balance reconciliation** — verify sub-ledger to GL match.
- **Bank reconciliation** — for tenants without daily feeds.
- **Production order closures** — close finished production orders for cost realisation.
- **Project WIP recalculation** — keep project cost accruals current.
- **Reservations review** — clean up stale reservations on cancelled orders.
## Monthly processes — the period close
The full month-end sequence:
1. **Cut-off and accrual posting** — record accruals for goods received but not invoiced, services consumed but not billed, payroll provisions.
2. **AP / AR reconciliation** — sub-ledger to GL match.
3. **Bank reconciliation** — all active bank accounts.
4. **Foreign currency revaluation** — period-end rate revaluation of open foreign-currency balances.
5. **Fixed asset depreciation** — calculate and post period depreciation.
6. **Inventory closing or recalculation** — reconcile inventory costs.
7. **Project recognition** — post project revenue and cost recognition per the configured rules (percentage-of-completion, milestones).
8. **Cost accounting allocation** — run primary, secondary, tertiary allocations.
9. **VAT / sales tax settlement** — calculate and post period VAT.
10. **Intercompany reconciliation** — verify intercompany balances match across legal entities.
11. **Period-end reporting** — financial reports, management dashboards.
12. **Period closure** — lock the period for posting.
**Quarterly / annual processes.**
- **Statutory reporting** — country-specific VAT returns, intrastat, SAF-T, electronic invoicing summaries.
- **Year-end close** — roll P&L to retained earnings, close fiscal year, open new year.
- **Annual cost roll** — refresh standard costs for the new year.
- **Audit data exports** — auditor data dumps.
- **Asset book reconciliation** — verify FA register against GL.
- **Inventory full physical count** — for organisations not running cycle counting.
## Batch framework
Most periodic processes run through F&O's **batch framework** — configurable jobs with start times, recurrence, parallel batch groups, and retry policies. The batch framework is the F&O equivalent of BC's job queue, with finer granularity for high-volume tenants.
## Monitoring
**System administration** workspace shows batch history, failed jobs, queued work, and execution time trends. Configure alerts on:
- Jobs that fail repeatedly.
- Jobs that exceed expected duration substantially.
- Queue depth growing unboundedly.
**Common pitfalls.**
- **Process documentation gaps** — when the controller leaves, nobody knows the close sequence. Document the runbook.
- **Failed jobs not investigated** — batch errors silently accumulate. Daily check.
- **Out-of-sequence runs** — running inventory closing before WIP recognition produces wrong cost. Honour dependencies.
- **Missing year-end tasks** — first-year operations miss year-end steps that the team learns the hard way.
## Operational reality
Period close is the test of operational maturity. A tenant that closes cleanly in 3 working days has well-tuned periodic processes; a tenant that takes 10 days has work to do.
---
# Permissions and security in Business Central
How Business Central security really works — permission sets, user groups, security filters, and the data residency boundaries you should know about.
Source: https://www.solvingdynamics365.com/guides/business-central-permissions-and-security
Section: Business Central / Admin & ops
Published: 2026-05-01
Updated: 2026-08-25
Business Central's security model is built around **permission sets** that grant *read, insert, modify, delete, and execute* (RIMDX) rights on individual database objects — tables, pages, codeunits, reports, queries. Users get effective permissions by being assigned one or more permission sets, optionally bundled into **user groups** for easier administration.
## Permission sets
Microsoft ships a long list of built-in permission sets — SUPER, BASIC, SETUP, sales-related, finance-related, manufacturing-related — and extensions add their own. Built-in sets are read-only; to customise, you copy one and edit the copy, or write a new permission set in AL. Permission sets are versioned and can be assigned via **plans** automatically based on the user's licence type (Essentials, Premium, Team Member), preventing over-privileging.
## User groups
A **user group** is a named collection of permission sets, assignable in one step. Most customers organise security around job roles — "AP Clerk", "Sales Manager", "Warehouse Operator" — each as a user group bundling the right sets.
## Security filters
A permission set can include **security filters** — row-level filters that constrain a user's access to a subset of a table (e.g. only one location's items, or only one dimension value's GL entries). Filters are powerful but harder to test; use sparingly.
## Direct vs indirect permissions
Reading a customer record via the customer card needs *direct* read on Customer. Posting a sales invoice writes to many tables via *indirect* permission, granted through codeunit execution rights rather than direct table rights. Indirect is the modern pattern; using direct write rights on transactional tables is usually a misconfiguration.
## Effective permissions tool
From any user card, the **Effective Permissions** page shows exactly what RIMDX rights the user has on any object, and which permission set granted them. Use it to debug permission errors.
## Identity and SSO
All BC SaaS users sign in with **Microsoft Entra ID**. Multi-factor authentication, conditional access, named locations, and lifecycle automation are configured in Entra, not in BC. Service-to-service API calls authenticate via Entra app registrations with **application permissions**.
## Data residency
BC SaaS data lives in the Microsoft data centre region selected at tenant creation and never leaves it. Moving between regions requires a tenant migration.
## Audit
Built-in change-log for sensitive tables, plus integration with **Microsoft Purview** for tenant-wide audit retention.
## Where to go next
Audit on top of permissions is [the change log and audit trail](https://www.solvingdynamics365.com/guides/change-log-and-audit-trail-in-business-central); identity controls live in Entra, covered in [conditional access](https://www.solvingdynamics365.com/guides/dynamics-365-and-conditional-access). The permission errors users and integrations hit are decoded in [AL runtime errors](https://www.solvingdynamics365.com/guides/al-runtime-errors-in-business-central) and [Business Central API errors](https://www.solvingdynamics365.com/guides/business-central-api-errors). Environments carry their own access model — see [Business Central environments](https://www.solvingdynamics365.com/guides/business-central-environments).
### Frequently asked questions
**What is a permission set in Business Central?**
A named set of read, insert, modify, delete, and execute rights on tables, pages, codeunits, reports, and queries. Built-in sets are read-only; customise by copying one or writing a new set in AL, and bundle sets into user groups per job role.
**What is the difference between direct and indirect permissions?**
Direct permission lets a user read or write a table from its page; indirect permission lets a codeunit write to tables on the user's behalf during posting. Indirect is the modern pattern — direct write rights on transactional tables are usually a misconfiguration.
**How do I debug a permission error?**
Open the Effective Permissions page from the user card. It shows exactly which rights the user has on any object and which permission set granted them.
**Where are MFA and conditional access configured?**
In Microsoft Entra ID, not Business Central. All SaaS users sign in through Entra, and service-to-service API calls use app registrations with application permissions.
---
# Personalization tokens in Customer Insights — Journeys
How personalization tokens insert profile data into messages — token syntax, fallback values, dynamic content.
Source: https://www.solvingdynamics365.com/guides/customer-insights-journeys-personalization-tokens
Section: Customer Engagement / Customer Insights / Marketing
Published: 2026-05-01
A marketing email addressed "Dear Customer" feels generic; one addressed "Hi Alex, your last order shipped to 123 Main Street" feels relevant. **Personalization tokens** in Customer Insights — Journeys insert profile and behavioural data into messages at send time, scaling personal touches across millions of recipients.
## Token syntax
Tokens reference data fields:
```
Hello {{contact.firstname}},
Your last order on {{order.purchaseDate}} totalled {{order.amount}}.
```
At send, tokens replaced with actual values for each recipient.
**Token sources.**
- **Contact** profile fields — name, email, custom attributes.
- **Account** fields — company name, industry.
- **Customer Insights unified profile** — enriched attributes.
- **Triggering event data** — the event that started the journey.
- **Custom data** — Power Automate-supplied at send time.
The richer the available data, the more personal the messages.
## Fallback values
When a field is empty:
```
Hi {{contact.firstname | default: "there"}}
```
Without fallback, empty tokens result in awkward gaps. Always specify defaults.
## Conditional content
Beyond simple substitution:
```
{% if contact.loyaltyTier == "Gold" %}
Enjoy your exclusive Gold member preview.
{% else %}
Sign up for our loyalty program.
{% endif %}
```
Liquid-style conditionals enable per-recipient content variations.
**Dynamic content blocks.**
- Pre-configured content options.
- One block per recipient based on attributes.
- Variations: by segment, by region, by past purchase, etc.
A single email can serve different content to different audiences without managing multiple email assets.
## Token testing
Critical:
- **Preview** with sample data.
- **Test send** to internal addresses; verify tokens replaced correctly.
- **A/B test** different token configurations.
Bad tokens producing "Hello {{firstname}}" in production emails is mortifying.
**Where personalization tokens work.**
- **Email subject lines.**
- **Email body** content.
- **SMS messages.**
- **Push notifications.**
- **In-app messages.**
- **Landing page content** (where supported).
Cross-channel personalisation reinforces the personal feel.
**Personalization tokens for URLs.**
```
Click here: https://portal.example.com/account?id={{contact.contactid}}
```
Pre-populates portal URLs with contact identity; user lands on their content without re-authenticating.
**Real-time vs batch.**
- **Real-time** — tokens resolved at send time; latest data.
- **Batch** — tokens resolved when send queue built; data may be hours old.
For real-time triggers (order confirmation), real-time matters.
## Identity-based personalization
Beyond fields, behavioural:
- "You browsed product X" — captured from web behaviour.
- "You haven't logged in for 30 days" — re-engagement message.
- "Your subscription renews in 7 days" — lifecycle.
Customer Insights — Data feeds these signals.
**A/B testing tokens.**
- **Subject A** — "Alex, your order has shipped"
- **Subject B** — "Your order is on the way"
Token-driven personalization can be the test variable; measure which performs better.
**GDPR / privacy considerations.**
- Personalization tokens use personal data.
- Consent for the use required.
- Right to erasure — tokens stop working after data deletion.
Ensure personalization patterns respect privacy regulations.
## Localisation
Tokens combined with language detection:
```
{% if contact.preferredLanguage == "fr" %}
Bonjour {{contact.firstname}}
{% else %}
Hello {{contact.firstname}}
{% endif %}
```
Or different email assets per language; tokens consistent across.
## Performance
Token resolution adds processing time:
- Large recipient lists with complex tokens take longer to send.
- Heavy conditional logic slows sending.
- Generally acceptable for marketing volumes.
**Common pitfalls.**
- **No fallback.** Empty fields produce broken text in production.
- **Wrong field reference.** Token doesn't resolve; literal "{{name}}" in email.
- **Sensitive data in tokens.** Inadvertently include data that shouldn't be in email.
- **Over-personalisation.** Creepy effect; recipients uncomfortable.
- **Test data leaks.** Test sends to production lists; embarrassing.
- **Conditional logic complex.** Hard to maintain; bugs.
**Best practices.**
- **Always fallback** — never assume data present.
- **Preview before send** — verify with sample data.
- **Test sends** to internal addresses.
- **Audit token usage** — what data being used where.
- **Consent compliance** — verify before personalization patterns deploy.
## Strategic positioning
Personalization is table stakes for modern marketing. Tokens are the mechanism in Customer Insights — Journeys; the data quality and segmentation work feeding them is where competitive advantage emerges. Mature programs invest in unified customer profiles (Customer Insights — Data), thoughtful trigger design, and continuous testing of personalization effectiveness. The tokens themselves are easy; the underlying data discipline is the hard part. Get that right, and personalization scales authenticity beyond what was previously possible.
---
# Phased vs big-bang go-live
When to phase a Dynamics 365 go-live and when to go big-bang — the trade-offs across complexity, risk, integration burden, and organisational change.
Source: https://www.solvingdynamics365.com/guides/phased-vs-big-bang-go-live
Section: Implementation / Methodology
Published: 2026-05-01
For any Dynamics 365 implementation beyond the smallest, one of the earliest strategic decisions is whether to roll out **all at once** (big-bang) or **incrementally** (phased). Both have credentials and both have failure modes; the right choice depends on the specific shape of the project.
## Big-bang
A single cutover: on one date, every legacy system stops accepting new transactions and Dynamics 365 takes over. Common for SMB Business Central implementations and for single-entity F&O rollouts. The advantages: one cutover weekend, no parallel-running maintenance, clean break, single training and change-management push.
The risks: every defect surfaces simultaneously, all to the same support team. If something breaks badly, there's no fallback short of rollback. Pressure on hypercare is enormous. The legacy system is decommissioned (or frozen read-only); recovery options shrink.
## Phased by module
Roll out finance first, then operations, then sales, etc. Each phase is its own mini-go-live. Common when the customer is moving from a single legacy ERP and can keep the legacy running for non-migrated modules. The advantages: each go-live is smaller and lower-risk; the team learns between phases; failures contained.
The risks: prolonged dual-running (legacy + Dynamics 365) requires integrations that work both ways during the transition. Period-end close becomes a multi-system exercise. Total elapsed time is longer.
## Phased by site or entity
Roll out site A or legal entity 1 first, then expand. Common for multi-site manufacturers or multi-entity groups. The pilot site is the laboratory; lessons feed expansion. The advantages: real-world validation before scaling, lower blast radius, opportunity to refine training and support before expansion.
The risks: until the last site is live, the project isn't finished. Inter-site integrations have to work across both old and new during the rollout. Some scope creep often happens between phases as later sites demand "the same as Site A *plus*".
## Phased by geography
A geographic variant of site phasing, common for global rollouts. Country-specific localizations, languages, holidays, and currencies all become per-phase scope. The most complex variant; only undertaken by mature programs with multi-year horizons.
## Choosing
Big-bang for: small-to-medium SMB ERP, time-sensitive contracts, single-site operations, clean replacement of obsolete systems. Phased by module for: large enterprise complexity with mature legacy. Phased by site/geo for: multi-site/global with risk concentration.
## Hybrid
Many programs phase the *finance* go-live (big-bang for the back office) and then phase the *operations and CRM* rollouts site-by-site. This combines fast core stabilisation with gradual operational coverage.
## The discipline
Whichever path, write the rollback plan before you commit. Big-bang rollback is hard but possible; phased rollback is easier but more frequent — both need procedures.
## Where to go next
Whichever shape you choose, the mechanics are in [cutover planning](https://www.solvingdynamics365.com/guides/cutover-planning-for-dynamics-365) and the weeks after in [hypercare](https://www.solvingdynamics365.com/guides/hypercare-after-go-live). Phasing decisions are driven by [data migration strategy](https://www.solvingdynamics365.com/guides/data-migration-strategy-for-dynamics-365) and [change management](https://www.solvingdynamics365.com/guides/change-management-for-dynamics-365), and the risks of each path belong in [the risk register](https://www.solvingdynamics365.com/guides/risk-management-on-dynamics-365-projects).
### Frequently asked questions
**When is a big-bang go-live the right choice?**
Small-to-medium ERP implementations, single-site operations, time-sensitive contracts, and clean replacement of an obsolete system — the common shape for Business Central and single-entity F&O rollouts. One cutover weekend, one training push, no dual-running.
**What are the ways to phase a rollout?**
By module (finance first, then operations, then sales), by site or legal entity (a pilot site as the laboratory), or by geography (country-specific localisations and languages per phase — the most complex variant).
**What is the main cost of phasing?**
Dual-running. Legacy and Dynamics 365 must integrate both ways during the transition, period-end close becomes a multi-system exercise, and total elapsed time is longer. Scope creep between phases is common.
**Is there a hybrid approach?**
Yes, and it is common: big-bang the finance go-live to stabilise the back office quickly, then phase operations and CRM rollouts site by site. Whichever path, write the rollback plan before committing.
---
# Physical inventory orders in Business Central
How to run a physical inventory count in Business Central — counting periods, physical inventory journals, count discrepancies.
Source: https://www.solvingdynamics365.com/guides/business-central-physical-inventory-orders
Section: Business Central / Inventory & warehouse
Published: 2026-05-01
Updated: 2026-08-25
Even with strict cycle counting and disciplined warehouse processes, physical and system stock balances diverge. The annual or quarterly **physical inventory count** is the reconciliation event — count what's physically there, compare to system, post adjustments. Business Central supports physical inventory counts through several mechanisms; understanding the choices matters for accuracy and audit defence.
**Why physical inventory matters.**
- **Financial accuracy** — balance sheet inventory value must reflect reality.
- **Audit compliance** — auditors test inventory; large variances trigger findings.
- **Operational accuracy** — picking and planning rely on correct on-hand.
- **Shrinkage detection** — theft, damage, mis-counts surface.
**The three mechanisms in BC.**
- **Physical Inventory Journal** — basic mechanism; manual entry of counted quantities.
- **Counting Period + Cycle Counting** — recurring counts on a schedule per item.
- **Physical Inventory Orders / Counting** (in some warehouse extensions) — more structured workflows.
## Physical Inventory Journal
The foundation:
1. Create a Physical Inventory Journal.
2. **Calculate Inventory** action — populates lines with current system quantity per item.
3. Operator counts physical stock and enters counted quantity.
4. System computes variance.
5. **Post Journal** — adjusts inventory ledger entries to match counted.
The journal is straightforward; works for small-medium inventory counts.
## Counting periods
Items can be assigned a **Counting Period** code:
- **Annual** — counted once a year.
- **Quarterly** — four times a year.
- **Monthly** — twelve times.
- **Custom periods** — specific intervals.
The system tracks when each item was last counted; **Calculate Counting Period** action generates the journal for items due.
## Cycle counting
Continuous counting rather than periodic full counts:
- A subset of items counted each day or week.
- Over time, all items get counted.
- Mature operations cycle-count daily.
Cycle counting integrates with item counting period; daily routine becomes the count.
**The count process at scale.**
For a warehouse with 10,000 SKUs:
1. **Plan the count** — period, scope, teams.
2. **Generate count sheets** — items to count, ideally per location/bin.
3. **Freeze the warehouse** if doing full count (no movement during count) or have controls if not.
4. **Count physical** — operators count and record.
5. **Capture counts** — into BC via UI, mobile app, or import.
6. **Compare and investigate** variances — significant variances require recount.
7. **Post adjustments** — final variances written to inventory.
8. **Unfreeze warehouse** if applicable.
## Warehouse-mode considerations
In an advanced warehouse:
- Bin-level counts.
- Warehouse Physical Inventory Journal.
- Counts compared at bin level, not just item level.
## Lot/serial considerations
For tracked items:
- Each lot/serial counted separately.
- Variances tracked per lot.
- Lost serials investigated.
**Variance investigation.**
- **Material variances** — recount; investigate cause.
- **Bin location errors** — item miscoded; correct master data.
- **System lag** — recent transactions not yet posted.
- **Shrinkage** — accept as loss after investigation.
Mature operations have variance thresholds — within 1%, accept; above, investigate.
## Mobile counting
Hand-held scanners + mobile app:
- Operator scans item barcode → enters count.
- Faster than paper-based.
- Less error-prone.
- Real-time capture into BC.
Third-party warehouse mobile extensions (Tasklet, Insight Works) provide rich mobile counting.
**Inventory close vs physical inventory.**
- **Inventory close (F&O)** — period-end cost adjustment routine; not physical counting.
- **Physical inventory** — actual count of stock.
Different concepts; both needed periodically.
**Common pitfalls.**
- **No frozen window.** Movements during count; variances impossible to investigate.
- **Manual data entry slow.** 10,000 items × manual keying = days of work; mobile saves.
- **Variance tolerance too loose.** Material variances accepted without investigation; shrinkage hidden.
- **Counting periods stale.** Items with periods set 5 years ago; no longer reflect reality.
- **Post without review.** Adjustments posted without management approval; large hits to P&L.
## Approval workflow
For large variances:
- Threshold-based approval routing.
- Operations manager reviews top variances.
- Finance approves before posting if material.
Without controls, posting authority extends too widely.
## Audit considerations
Auditors look for:
- Evidence of the count (count sheets, system records).
- Variance investigation documentation.
- Approval of significant adjustments.
- Year-over-year consistency in shrinkage rates.
Document the count process; retain records for at least the audit retention period.
**Operational rhythm.**
- **Daily** — cycle count subset.
- **Quarterly** — review variances and counting periods.
- **Annual** — full physical (depending on company policy).
- **Pre-fiscal-year-end** — count and reconcile.
## Strategic positioning
Physical inventory is the moment of truth for inventory accounting. Investing in mobile-driven counting, clear process, variance investigation, and audit-quality documentation pays back in audit defence and operational accuracy. Skipping it or doing it poorly leads to balance sheet surprises and audit findings. For most operations, cycle counting daily plus a periodic structured count provides the right balance of effort and accuracy.
---
# Planning Optimization in Dynamics 365 Supply Chain
How Planning Optimization replaced the legacy MRP engine — in-memory architecture, scalability, scope, and migration considerations.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-planning-optimization
Section: Finance & SCM / Supply chain & inventory
Published: 2026-05-01
**Planning Optimization** is the modern master-planning engine in Dynamics 365 Supply Chain Management. It replaced the legacy AX-era MRP engine that struggled with large data volumes and long-running planning runs. The new engine is in-memory, parallelised, and dramatically faster — but it has scope differences worth knowing.
## Architecture
Planning Optimization runs as a separate Microsoft-managed Azure service, not in the F&O application tier. F&O streams the planning-relevant data (items, BOMs, routings, on-hand, open orders, forecasts, parameters) to the service; the service computes; the results flow back as planned orders, action messages, and reschedules. Because the engine is in-memory and runs in parallel, it can process plans for hundreds of sites and millions of items in minutes rather than hours.
## Net change and regenerative
The service supports both **net change** plans (only items affected by a recent transaction are replanned) and **regenerative** plans (everything from scratch). Net change makes near-real-time MRP feasible for very large catalogues.
## Filtering
Plans can be filtered by site, product, or any combination — useful for running a fast plan on a single site while keeping the global plan unchanged.
## Forecast consumption
Forecast plans feed Planning Optimization through forecast time fences and consumption rules. The engine honours both global and per-coverage-group parameters.
## Action messages
Output mirrors the legacy engine: *New*, *Increase*, *Decrease*, *Reschedule earlier*, *Reschedule later*, *Cancel*. Planners review and accept through the planning workbench in F&O.
## What's not yet covered
Planning Optimization has parity for *most* AX MRP scenarios, but some specialised features remain on the legacy engine in some implementations: certain co-product / by-product configurations, intercompany advanced features, and some country-specific localizations. Microsoft publishes a feature-parity matrix; check before assuming everything ports cleanly.
## Co-existence
During migration, customers can run **both engines** in parallel against the same data, compare results, and switch once parity is confirmed. This is the standard transition pattern from legacy MRP to Planning Optimization.
## Manufacturing scheduling
Planning Optimization handles infinite-capacity material plans. **Finite capacity scheduling** (gantt-style scheduling on constrained work centres) remains a separate concern — typically run with the *Scheduling* engine or a partner scheduling product on top of the material plan.
## Net result
A four-hour overnight MRP becomes a fifteen-minute job. Planning frequency goes from nightly to multiple times a day, and planners spend less time waiting and more time analysing.
---
# Playbooks in Dynamics 365
How playbooks codify repeatable business processes in Dynamics 365 — activities, automation, and when playbooks beat sequences.
Source: https://www.solvingdynamics365.com/guides/playbooks-in-dynamics-365
Section: Customer Engagement / Customer Service
Published: 2026-05-01
**Playbooks** in Dynamics 365 are reusable, structured response patterns for situations that need consistent handling — kicking off a major-account onboarding, responding to a competitor entering a deal, handling a customer escalation, executing a contract-renewal motion. Where a *sequence* is a cadence of seller activities over time, a *playbook* is a coordinated set of tasks, activities, and automations triggered by an event.
## The model
A **playbook template** defines:
- **Trigger** — the type of record and condition that fires the playbook (manual launch, automated trigger on opportunity stage change, case priority escalation).
- **Activities** — the items the playbook creates: tasks, appointments, phone calls, emails. Each with assignee, due date offset, description.
- **Automation** — calls to Power Automate flows, field updates on the source record, notifications.
A **playbook instance** is the running execution of a template against a specific source record. When triggered, the system creates the activities, assigns them, and tracks completion.
**Example playbooks.**
- **Major-deal-detected playbook.** Triggered when an opportunity exceeds 500k EUR. Creates tasks for the sales VP to review, the legal team to prepare contracts, the executive sponsor to schedule a customer call, the deal-desk team to validate pricing.
- **Competitor-in-deal playbook.** Triggered when a competitor field is filled on an opportunity. Creates tasks for competitive-intelligence brief, customer-reference outreach, and pricing-strategy review.
- **Customer-escalation playbook.** Triggered when a case is escalated to Tier 2. Creates tasks for the account manager to call the customer, the engineering team to investigate, the executive sponsor to acknowledge.
- **New-customer-onboarding playbook.** Triggered when an opportunity closes won. Creates tasks for implementation kickoff, account-manager introduction, success-plan creation, and quarterly business review scheduling.
## Why playbooks
They codify the institutional knowledge of "what we do when X happens" so it doesn't depend on individual memory or seniority. New team members get the right activities created automatically; experienced team members don't forget steps.
**Sequences vs playbooks.**
- **Sequence** — *time-based cadence* for one seller working one record over weeks (the prospecting motion).
- **Playbook** — *event-triggered orchestration* across multiple people, kicking off all at once or with relative timing offsets (the response).
A complex sales motion might use both: a sequence runs the prospecting cadence; once the opportunity reaches a key stage, a playbook fires to onboard the wider deal team.
## Configuration
Playbooks are configured in the maker portal. Required permission to launch a playbook is configurable; some are seller-launched, some auto-fire on conditions.
## Reporting
Playbook execution data is queryable — which playbooks fire most, completion rates, time to complete, outcome correlation. Use it to identify playbooks that aren't being executed (might need redesign) or playbooks that consistently drive better outcomes (might justify expanded scope).
**Limits.**
- Playbooks are linear lists of activities, not workflows with branching logic. For conditional logic, use Power Automate flows triggered by playbook events.
- Long-running multi-month playbooks are awkward; break into stages or use a business process flow with playbooks per stage.
- The playbook concept is most mature in CRM-side apps; F&O has its own workflow tools instead.
## Operational discipline
Don't over-template. Build playbooks for situations that genuinely repeat and where consistent response matters. 10–15 well-designed playbooks for the team's most consequential moments beats 50 trivial templates that nobody invokes.
---
# Polling vs push patterns for Dynamics 365 integrations
How to choose between polling and push integration patterns for Dynamics 365 — trade-offs, performance, freshness, and when each fits.
Source: https://www.solvingdynamics365.com/guides/polling-vs-push-patterns-for-dynamics-365
Section: Integrations / Architecture patterns
Published: 2026-05-01
Integrating Dynamics 365 with another system requires choosing how data flows: **polling** (consumer asks periodically) or **push** (source notifies on change). Each pattern has different trade-offs in freshness, complexity, and resource consumption. Most production architectures use both for different scenarios.
**Polling pattern.**
- Consumer periodically queries source.
- "Has anything new since last check?"
- Source returns delta or nothing.
- Consumer processes any new data.
Simple to implement; well-understood; works with any data source.
**Push pattern.**
- Source notifies consumer on event.
- Consumer processes immediately.
- No periodic queries.
More efficient at scale; requires source support for notifications.
**Polling characteristics.**
- **Simple** — basic HTTP/SQL queries.
- **Predictable load** on source — fixed query frequency.
- **Latency** — bounded by poll interval.
- **Self-healing** — if consumer down, catches up on resumption.
- **No source coupling** — consumer's choice.
**Push characteristics.**
- **Lower latency** — near-instant.
- **Lower overhead** — no wasted polls when nothing changed.
- **Source coupling** — source must support notification.
- **Recovery complex** — if consumer down, missed events need replay.
- **Burst-y load** — high spikes at busy times.
**When polling wins.**
- **Source doesn't push** — no notification API.
- **Latency tolerance** — minutes acceptable.
- **Simple integration** — minimise complexity.
- **Batch processing** — process accumulated data efficiently.
- **Predictable resource usage** preferred.
**When push wins.**
- **Real-time needs** — seconds matter.
- **High volume with low change rate** — polling wastes resources.
- **Source supports webhooks / events.**
- **Pubsub patterns** — multiple consumers.
**Polling implementations for Dynamics.**
- **OData with modifiedon filter** — `$filter=modifiedon gt '2026-11-01T...'`.
- **Change tracking** — Dynamics's incremental change endpoint.
- **Custom delta endpoint** — implementation in plug-in.
- **Database polling** — direct SQL queries (sometimes for F&O).
**Push implementations for Dynamics.**
- **Webhooks** — Dataverse webhook step.
- **Service Bus** — Dataverse → Service Bus → consumer.
- **Event Grid** — Dataverse → Event Grid → consumers.
- **Power Automate** — flow triggered on Dataverse change.
- **Business events** — F&O business events.
**Polling parameters.**
- **Frequency** — how often to query.
- **Batch size** — records per poll.
- **Filter** — what to retrieve.
- **Retry on failure.**
Frequency vs freshness trade-off. Faster polling = more current but more load.
## Adaptive polling
Smarter polling:
- **High activity** — poll more frequently.
- **Low activity** — back off.
Reduces wasted polls during quiet periods.
## Long polling
Hybrid:
- Consumer makes request.
- Source holds the connection.
- Source responds when data available or timeout.
- Consumer immediately requests again.
Combines polling simplicity with push-like latency.
## Webhooks
A push pattern:
- Source sends HTTP POST to consumer on event.
- Consumer accepts; processes.
- Source typically expects 200 quickly; further processing async on consumer side.
**Webhook reliability.**
- **Retries on failure** — limited.
- **No replay** typically — lost events lost.
- **Dead letter** if used (Service Bus / Event Grid).
For critical events, webhook-only is risky; broker-mediated push (Service Bus) is more reliable.
**Hybrid approaches.**
- **Push for real-time** — immediate.
- **Polling for catch-up** — periodic reconciliation.
- **Both for redundancy** — robust against either failing.
Belt-and-suspenders; common for mission-critical integrations.
## Reconciliation polling
Combined pattern:
- Push for normal flow.
- Periodic polling to catch any missed events.
- Reconcile differences.
This pattern handles webhook reliability gaps.
**Performance considerations.**
- **Polling load** — depends on frequency and source efficiency.
- **Push load** — depends on event volume.
For high-change-rate systems, push usually more efficient. For low-change-rate, polling can be cheaper.
**Throttling and limits.**
- **Dynamics APIs** — rate-limited.
- **Polling too frequently** — hits throttling.
- **Push** — limits at broker level.
Respect throttling; honour Retry-After headers.
**Monitoring.**
- **Polling** — track query frequency, returned counts.
- **Push** — track events emitted vs received.
- **End-to-end latency** — both patterns.
- **Lag / backlog** — accumulation.
Visibility regardless of pattern.
**Choosing in practice.**
- **Real-time integration?** → push.
- **Source pushes available?** → push.
- **Batch-acceptable latency?** → polling.
- **Mission-critical reliability?** → hybrid.
- **Simple integration?** → polling.
- **High volume?** → push usually.
**Common pitfalls.**
- **Polling too frequently** — throttled; expensive.
- **Polling too rarely** — stale data.
- **No idempotency** — duplicates from retries.
- **Webhook without retry strategy** — events lost.
- **No monitoring** — pattern silently failing.
- **Hard-coded URLs** — webhook URLs change; integration breaks.
**Migration patterns.**
- **Polling → push** when source adds notification support.
- **Push → polling** when broker overhead exceeds benefit.
Architecture not religious; adapt as systems evolve.
## Strategic positioning
Polling vs push is a core integration architecture decision. Both have valid use; understand trade-offs per integration. Default to push for real-time and high-volume scenarios; polling for simpler, batch-acceptable cases; hybrid for critical reliability.
For architects:
- Make conscious choice per integration.
- Document the rationale.
- Build observability for chosen pattern.
- Re-evaluate as systems evolve.
The pattern choice affects user experience, infrastructure cost, and operational complexity. Choose with care; don't default to one without consideration.
### Frequently asked questions
**When should I poll instead of push?**
When the source has no notification support, minutes of latency are acceptable, batch processing is efficient, or predictable load and simplicity matter more than freshness. Polling also self-heals: a consumer that was down catches up on its next poll.
**How do I poll Dataverse efficiently?**
Use change tracking for incremental deltas, or an OData filter on modifiedon with explicit paging. Respect throttling and Retry-After headers — polling too often is the classic way to get rate-limited.
**What push options exist for Dynamics 365?**
Dataverse webhooks, Service Bus or Event Grid service endpoints, Power Automate flows triggered on Dataverse changes, and business events in Finance and Operations.
**What is reconciliation polling?**
A hybrid: push for the normal real-time flow plus a periodic poll that catches anything the push path missed and reconciles differences. It is the standard belt-and-braces pattern for mission-critical integrations.
---
# Positive pay files in Dynamics 365 Finance
How F&O generates positive pay files for bank fraud prevention — file formats, daily transmission, reconciliation, and the typical bank-specific variations.
Source: https://www.solvingdynamics365.com/guides/positive-pay-files-in-f-and-o
Section: Finance & SCM / Finance
Published: 2026-05-01
**Positive pay** is a bank fraud-prevention service: each day, the company sends the bank a list of legitimately issued checks; the bank rejects any check presented that's not on the list. For US companies with check-based AP, positive pay is the standard control. F&O supports positive pay file generation through configurable data exchanges.
**The threat being mitigated.**
- **Check fraud** — stolen checks, altered amounts, counterfeit checks presented for payment.
- **Without positive pay** — bank pays anything that looks like a valid check.
- **With positive pay** — bank validates against the issuer's daily list.
For companies issuing thousands of checks monthly, positive pay is essential.
## Positive pay file contents
Typical fields per record:
- Account number.
- Check number.
- Check amount.
- Issue date.
- Payee name.
- Void status (for cancelled checks).
The bank validates each presented check against the file.
**Configuration in F&O.**
- **Bank account** flagged for positive pay.
- **Bank file format** configured (data exchange definition).
- **Positive pay record** generated on check issuance.
When a check is printed, a positive pay record is created. End-of-day, the records flow to a file.
## Generating the file
**Generate positive pay file** action:
1. Selects records since last submission.
2. Formats per bank's specification.
3. Outputs file (CSV, fixed-width, XML, etc. depending on bank).
4. Marks records as submitted.
## Bank-specific formats
Every bank has its own format:
- **Chase** — specific layout.
- **Bank of America** — different.
- **Wells Fargo** — different again.
- **JPMorgan** — different.
F&O ships with templates for major banks; customisation needed for others. The configuration is a data exchange definition mapping F&O records to bank's expected fields.
**Transmission methods.**
- **Bank portal upload** — manual; operator uploads daily.
- **FTP/SFTP** — automated transmission to bank's SFTP server.
- **Bank API** — modern; programmatic.
- **EDI** — for some banks.
Automation reduces operational burden; without it, daily manual upload is a chore.
## Exceptions
When the bank receives a check not on the list:
- **Exception alert** to the company.
- **Hold for review** — company decides accept or reject.
- **Timeout default** — if no response, bank's default (often reject).
The company reviews exceptions daily; legitimate checks (rare misses) get authorised, fraudulent ones rejected.
## Stop payments
When a check is voided:
- Stop payment record sent to bank.
- Bank rejects if presented.
- Positive pay file may include void instructions.
**Reverse positive pay vs payee positive pay.**
- **Standard positive pay** — match on account, check number, amount.
- **Payee positive pay** — also match payee name; harder to defeat.
Many banks offer both tiers; payee positive pay is stronger but requires accurate payee name capture.
## Daily transmission rhythm
Critical:
- Send positive pay file BEFORE any check could be presented.
- Banks typically require file by 8 AM or so for that day's presentments.
- Late files = checks presented before listing = potential acceptance of fraudulent items.
The cutoff is bank-specific; verify and respect.
## Reconciliation against bank
Beyond positive pay:
- Bank statement received daily / monthly.
- Match cleared checks against F&O bank ledger.
- Investigate items not matching.
Positive pay catches fraudulent checks at presentment; bank reconciliation catches issues post-clearing.
## ACH positive pay
Beyond checks, ACH transactions can also use positive pay:
- ACH originators authorised.
- Unauthorised ACH debits blocked.
F&O supports ACH positive pay configuration similarly.
**Implementation considerations.**
- **Bank partnership** — bank must support positive pay (most do).
- **File format provisioned** — bank's specification implemented in F&O.
- **Transmission method** — FTP / API setup.
- **Exception handling process** — who reviews exceptions, how quickly.
**Common pitfalls.**
- **File late.** Daily transmission missed; window of fraud opportunity.
- **Format errors.** File rejected by bank; checks not validated; revert to manual.
- **Stop payment not transmitted.** Voided check reaches bank; pays out as positive pay-listed.
- **Payee name mismatch.** "John Smith" vs "Smith, John"; payee positive pay flags legitimate checks.
- **No exception review.** Bank rejects valid checks; vendor calls; AP scrambles.
- **Manual override drift.** Operator approves exceptions routinely without analysis.
**Operational rhythm.**
- **Daily** — file transmission, exception review, monitoring.
- **Weekly** — process audit; missed file investigations.
- **Monthly** — reconcile bank's records of presented vs our records of issued.
## Strategic positioning
Positive pay is a high-leverage fraud control — relatively cheap to set up, dramatically reduces check fraud risk. For any US company issuing checks at scale, it's a standard expectation. F&O supports it natively with appropriate bank format configuration; the operational discipline of timely transmission and exception review is what makes it effective. The decision to NOT use positive pay rarely makes sense for check-issuing companies; the implementation is small, the protection material.
---
# Posting groups in Business Central
How Business Central uses posting groups to translate sub-ledger transactions to GL accounts — general, specific, and inventory posting groups.
Source: https://www.solvingdynamics365.com/guides/posting-groups-in-business-central
Section: Business Central / Finance & accounting
Published: 2026-05-01
**Posting groups** are how Business Central decides which GL accounts a transaction should hit. Every customer, vendor, item, bank, and resource carries one or more posting groups, and the intersection of those groups defines the GL accounts the system uses at posting. Get them right and the GL builds itself; get them wrong and the trial balance gets uncorrectable noise.
## General business posting groups
Tag the *type of trading partner* — Domestic, EU, Export, Intercompany. Attached to customers and vendors.
## General product posting groups
Tag the *type of product or service* — Goods, Services, Subscription, Reverse-Charge Service. Attached to items, resources, and GL accounts.
## VAT posting groups
A parallel pair (VAT business + VAT product) drives VAT calculation and reporting. Often mirrors the general posting groups but separate so VAT can be configured independently for special cases.
## General posting setup
The matrix that combines *General Business × General Product* into accounts: Sales Account, Sales Credit Memo Account, Sales Line Discount Account, Purchase Account, Purchase Credit Memo Account, COGS Account, Direct Cost Applied Account, Inventory Adjustment Account. Every revenue and expense path that touches the GL is mapped here.
## Customer / vendor posting groups
A *specific* posting group tagging the *role of the trading partner* — Domestic, Foreign, Employee, Intercompany. Maps to balance-sheet control accounts: Receivables Account, Payment Discount Debit Account, Invoice Rounding Account, etc. Attached to each customer / vendor card.
## Inventory posting groups
Tag the *type of inventory* — Raw Material, Finished Goods, WIP, Resale. Combined with the location into an **inventory posting setup** matrix that maps each item-at-each-location to balance-sheet accounts: Inventory Account, Inventory Account (Interim), WIP Account, etc.
## Bank account posting groups
Tag the role of the bank account, mapping to GL bank accounts and currency-specific accounts.
## Job / project posting groups
Map job ledger entries to WIP, recognised costs, accrued costs, recognised sales, and invoiced sales GL accounts.
## FA posting groups
Map fixed-asset events (acquisition, depreciation, write-down, disposal) to GL accounts per asset class.
## The discipline
Define posting groups around real *accounting differentiations*, not around customer or product hierarchy that already exists elsewhere. Five customer posting groups (Domestic, Foreign, Group, Public, Employee) is healthy; fifty is a sign that someone's reaching for a sub-account taxonomy where they should have used dimensions instead.
## Default and override
Items, customers, and vendors default posting groups from templates or item categories. Don't override at the record level unless there's a real, defensible reason — overrides scatter configuration and frustrate audit.
---
# Posting profiles in Dynamics 365 Finance
The posting-profile mechanism in Dynamics 365 Finance — how transactions translate into GL entries, and why getting them right matters.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-posting-profiles
Section: Finance & SCM / Finance
Published: 2026-05-01
A **posting profile** in Dynamics 365 Finance is a configuration object that tells the system which GL accounts to use when a sub-ledger transaction posts. Sub-ledgers (customers, vendors, fixed assets, inventory, sales tax, banks, projects) all have posting profiles. They're how F&O bridges the operational world of invoices, receipts, and shipments to the accounting world of double-entry GL.
## The pattern
Each sub-ledger has a default posting profile, plus the ability to attach more specific profiles to *groups* or *individual records*. For customers, for example, you might have a default profile pointing AR control to GL 1500-Receivables, an export-customer profile pointing AR control to 1510-Export Receivables, and an inter-company profile pointing AR control to 1520-IC Receivables. F&O picks the most specific match at posting time.
## What's in a profile
A vendor posting profile names the GL accounts for:
- Summary account (AP control)
- Settlement account (where settlements net)
- Liability for discount
- Arrival account (goods received not invoiced)
- Charges accounts
- And more, depending on the modules in use.
## Why it matters
Posting profiles are the single biggest source of GL posting errors after dimensions. A miscoded posting profile sends thousands of transactions to the wrong account, often only discovered at period-end when the trial balance won't reconcile. Mass-correcting requires either reversing and reposting transactions or running a reclassification journal — both are heavy operations.
## Group versus specific
Posting profiles default at the *group* level (Customer Group, Vendor Group, Item Group, Bank Group). Resist the urge to override at the individual record level — it scatters configuration and makes auditing nearly impossible. Define groups for every meaningful classification, attach profiles at the group, and override at the record only when there's an explicit, defensible reason.
## Currency and dimensions
Profiles can vary by currency (e.g. AR for EUR customers vs SEK customers) and can carry default dimension values that propagate to posted entries.
## Audit
Every GL transaction stores a reference back to the source document, so auditors can trace from a GL line to the originating sub-ledger transaction and to the profile that mapped them. Reverse drill is one of the most-used troubleshooting tools.
## Design discipline
Map out the posting profile design as part of CoA design, not as an afterthought. Two days early saves two weeks late.
---
# Power Apps canvas app errors explained
The canvas app errors makers hit most — delegation warnings, 'The specified column does not exist', Patch type errors, network error when using Patch, data source not found, permission denied, connection consent, premium licence prompts — with fixes.
Source: https://www.solvingdynamics365.com/guides/power-apps-canvas-app-errors-explained
Section: Power Platform / Troubleshooting
Published: 2026-09-03
Canvas app errors show up in three places: the formula bar (red underlines and delegation warnings while authoring), the running app (banners and dialogs), and the Monitor tool (the network calls behind them). Most user-facing failures are one of a dozen patterns, and this reference covers them with the fix. For what canvas apps are and when to use them, see [canvas apps vs model-driven apps](https://www.solvingdynamics365.com/guides/canvas-apps-vs-model-driven-apps); for making a slow app fast, [Power Apps performance tuning](https://www.solvingdynamics365.com/guides/power-apps-performance-tuning).
## Authoring-time warnings that become runtime bugs
### Delegation warning: "The 'Filter' part of this formula might not work correctly on large data sets"
**Symptom.** A yellow triangle on a formula; the app works in testing; in production users cannot find records they know exist.
**Cause.** A non-delegable function or operator — `Search` on a Dataverse column that does not support it, `in` on some sources, `Sum` over a filtered SharePoint list, string functions like `Left` inside `Filter`, or comparing to a variable of the wrong type. The source returns the first 500 rows (2,000 with the app setting), and the rest of the formula runs on that subset.
**Fix.** Use delegable functions for the source (`Filter`, `LookUp`, `StartsWith`, `=`, `<`, `>`, `And`/`Or` on indexed columns for Dataverse), push logic into a Dataverse view and filter on that, or pre-aggregate with a rollup column. For SharePoint, index the columns and avoid complex expressions.
**Prevention.** Treat every delegation warning as an error before the app leaves development; test against a copy of production-sized data.
### "Invalid argument type. Expecting a Record value instead." / "Expecting a Text value"
**Symptom.** A red underline on `Patch`, `Set`, or a control property.
**Cause.** Type mismatch. Dataverse lookups need a record from the related table (`LookUp(Accounts, 'Account' = …)`), choices need the choice value (`'Status (Orders)'.Active`), dates need a date, and a text box's `.Text` is text even when it contains a number.
**Fix.** Convert explicitly: `Value()`, `DateValue()`, `Text()`; pass lookup records and choice values in their own types.
### "Name isn't valid. 'X' isn't recognized" after renaming or importing
**Cause.** A control, variable, collection, or data source was renamed or removed and the formula still references it; or the app was imported into an environment where the data source name differs.
**Fix.** Use the App checker's formula errors list to find every reference; re-add the data source with the expected name.
## Runtime data errors
### "The requested operation is invalid. Server Response: X failed: The specified column 'Y' does not exist. The column with the most similar name is 'Z'."
**Symptom.** A `Patch` or `Collect` to Dataverse fails with this text.
**Cause.** The record literal uses a display name (`Status`) or wrong case (`New_Status`) where Dataverse wants the logical name (`new_status`), or a column that exists on a different table.
**Fix.** Use the name the error suggests; check the table's Columns view for logical names.
**Prevention.** Let IntelliSense in the formula bar supply column names; do not type them from memory.
### "Network error when using Patch function: The server returned an error" / "Bad Request"
**Symptom.** The write fails; the message has little detail.
**Cause.** The data source rejected the write. Dataverse: a business-required column not supplied, a business rule, a real-time workflow or plug-in error, a duplicate detection rule, an alternate key violation, or a missing privilege (Create, Write, Append, AppendTo). SharePoint: a column validation, a lookup value not in the target list, a required column.
**Fix.** Open Monitor (from the app's Advanced tools), reproduce, and read the server response body — it contains the Dataverse or SharePoint message and code. Decode Dataverse codes with [Dataverse Web API errors](https://www.solvingdynamics365.com/guides/dataverse-web-api-errors-explained).
**Prevention.** Wrap writes in `IfError(Patch(...), Notify(FirstError.Message, NotificationType.Error))` so users see the real message.
### "An entry is required" / the form will not submit
**Cause.** A required field in the form's data source has no card, or the card's `Update` property is blank; on Dataverse, business-required columns; on SharePoint, required columns.
**Fix.** Add the card or set `Update` to a value; check the form's `Error` and `ErrorKind` properties in `OnFailure`.
### "Data source not found: X" / "The data source 'X' has been removed" / "Getting your data" forever
**Symptom.** The app opens but data does not load, or shows an error banner.
**Cause.** After import into another environment the data source (a Dataverse table, a SharePoint list by URL, a SQL connection) is missing or points at a different environment; or the connection behind it needs consent (see below); or the user has no access to the source.
**Fix.** Remove and re-add the data source in the target environment; for SharePoint and SQL, use environment variables for the site URL and connection so imports rebind automatically. See [connection references and environment variables](https://www.solvingdynamics365.com/guides/connection-references-and-environment-variables).
### Only some records show / a gallery is missing rows
**Cause.** Delegation (above), or a Dataverse security role scope (user-level read shows only the user's own rows), or a SharePoint list over the 5,000-item view threshold with a non-indexed filter.
**Fix.** Check the delegation warnings first; then the user's read scope on the table; then SharePoint indexing.
## Permissions, sharing, and connections
### "You don't have permission to view this data" / "Access to Dataverse denied"
**Cause.** The app is shared but the user lacks a security role with read on the table, or is not in the environment's security group. On SharePoint, the user lacks permission on the list.
**Fix.** Assign a security role when sharing the app (the share dialog offers it for Dataverse apps), or through the admin centre; grant list permissions in SharePoint.
**Prevention.** One custom role per app that grants exactly the tables and privileges the app uses; [Dataverse security model](https://www.solvingdynamics365.com/guides/dataverse-security-model) explains scopes.
### "You need to allow connections" / consent dialog on first open
**Cause.** The app uses connections the user has not consented to. Each user is asked once per connector.
**Fix.** Expected behaviour. To remove the prompt for connections that do not need per-user consent, an admin can bypass it with `Set-AdminPowerAppApisToBypassConsent` in the Power Apps PowerShell module — appropriate for Dataverse and other tenant-managed connectors, not for connectors that act as the user.
### "This app requires a Power Apps Premium licence" / "You need a licence to run this app"
**Cause.** The app uses a premium connector (Dataverse outside a Dynamics 365 context, SQL, HTTP, custom connectors) and the user's licence does not cover it — Microsoft 365 users, or Dynamics 365 Team Member users on an app that touches non-Dynamics tables or premium connectors.
**Fix.** Assign Power Apps Premium or pay-as-you-go, or redesign the app to use only connectors the user's licence covers. The [Power Apps pricing page](https://www.solvingdynamics365.com/pricing/power-apps) covers what Dynamics 365 licences include.
**Prevention.** Decide the licence position for every app before it is shared; [Power Apps vs Dynamics 365 CRM](https://www.solvingdynamics365.com/guides/power-apps-vs-dynamics-365-crm) covers where the boundary sits.
### "The connection is not valid" / flows run from the app fail
**Cause.** A connection embedded in a flow the app calls belongs to a user who left or whose token expired; or the flow is not shared with the app's users (run-only permissions).
**Fix.** Rebind the flow's connections to a service account and share the flow with the app users as run-only; see [Power Automate flow failures](https://www.solvingdynamics365.com/guides/power-automate-flow-failures-explained).
### App opens for the maker but not for others
**Cause.** Not shared, or shared without the underlying data source access, or the environment's security group excludes them.
**Fix.** Share the app, assign the role, check the security group.
## Performance and platform
### Slow start, "Loading" for many seconds
**Cause.** `OnStart` loads whole tables into collections, sequentially; many data sources; large images embedded; formulas that recalculate on every screen.
**Fix.** Load only what the first screen needs, use `Concurrent()` for independent loads, defer the rest to screen `OnVisible`, use named formulas for derived values. [Power Apps performance tuning](https://www.solvingdynamics365.com/guides/power-apps-performance-tuning) has the full list.
### "There's a problem with your app. Please try again later." / app checker errors after a platform update
**Cause.** A control or formula that a platform update changed behaviour for — the app has not been republished against the new version — or an experimental feature that was retired.
**Fix.** Open the app in the studio, resolve App checker errors, republish.
**Prevention.** Republish apps at least once per release wave; keep experimental features out of production apps.
### Mobile: "App not available offline" / stale data on mobile
**Cause.** Offline is not enabled or the offline profile does not include the tables; the app relies on data loaded in `OnStart` that is not refreshed.
**Fix.** Configure the offline profile for the tables needed; see [canvas app offline mode](https://www.solvingdynamics365.com/guides/canvas-app-offline-mode).
## Finding the cause quickly
Three tools answer nearly every canvas app error. The App checker lists formula errors and delegation warnings with the control and property. Monitor shows every network call the app makes with request and response, including the server's real error text behind a "network error". And `IfError` with `FirstError.Message` in `OnFailure` and around `Patch` puts that text in front of the user instead of a generic banner. Once the message is visible, it is usually one of the Dataverse or SharePoint errors above.
### Frequently asked questions
**What does the delegation warning actually mean?**
The formula includes a function or operator the data source cannot evaluate server-side, so Power Apps fetches only the first 500 rows (up to 2,000 with the setting) and applies the rest locally. On a small table nothing is wrong; on a large one, results are silently incomplete. Rewrite with delegable functions and columns, or filter server-side through a view.
**Why does Patch fail with 'The specified column X does not exist'?**
The record you pass to Patch uses a display name or a wrong-case name where the data source expects the logical name — for Dataverse, the lowercase schema name such as new_status. The error usually suggests the most similar column; use that.
**What is 'Network error when using Patch function: The server returned an error'?**
The data source rejected the write. On Dataverse it is usually a business-required column missing, a business rule, a plug-in error, or a security privilege; on SharePoint a validation or a lookup mismatch. The details after the message, or the Monitor tool, show the server's actual response.
**Why do users see 'You don't have permission to view this data'?**
Either the app is not shared with them, or they lack a Dataverse security role with read on the table (or a SharePoint permission on the list). Sharing the app does not grant data access; assign the security role when sharing, or through the admin centre.
---
# Power Apps Component Framework (PCF) control development
How to build custom controls with the Power Apps Component Framework — the dev environment, lifecycle, manifest, packaging.
Source: https://www.solvingdynamics365.com/guides/power-apps-pcf-control-development
Section: Power Platform / Power Apps
Published: 2026-05-01
When Power Apps's standard controls don't suffice — you need a specialised data visualisation, a custom interaction, a third-party widget integrated — the **Power Apps Component Framework (PCF)** lets developers build custom controls in TypeScript that integrate natively with model-driven and canvas apps. The capability is powerful; the development discipline is meaningful.
**What PCF enables.**
- Custom UI controls for fields, datasets, and sub-grids.
- Full TypeScript / JavaScript / HTML / CSS implementation.
- Native integration with Dataverse data binding.
- Reusable across apps and environments.
- Solution-aware deployment.
**Development environment.**
- **Node.js + npm** for tooling.
- **Power Platform CLI (pac)** for project scaffolding.
- **Visual Studio Code** as editor.
- **TypeScript / React** common stack.
Setup is non-trivial; budget a few hours for first-time setup.
**Project structure.**
```
ControlProject/
ControlManifest.Input.xml - control definition
index.ts - main entry
index.css - styling
components/ - sub-components
package.json
tsconfig.json
```
## ControlManifest
The contract:
- **Properties** — fields the control consumes.
- **DataSet** — for dataset controls binding to views.
- **Resources** — referenced files.
- **Required features** — platform features needed.
Manifest defines what host app sees when configuring the control.
**Control lifecycle.**
- `init(context, notifyOutputChanged, state, container)` — called once on initialisation.
- `updateView(context)` — called on context change (data update).
- `getOutputs()` — returns values to push back to the host.
- `destroy()` — cleanup.
These four methods are the contract; understanding their flow is essential.
## The `context` object
Provides:
- Current property values.
- Data set (for dataset controls).
- Device info — screen size, orientation.
- User info.
- Mode — read-only, disabled.
- Resources — fetched files.
The control reads context and renders accordingly.
## Two-way binding
For fields:
- Field value flows in via context.
- User interaction in control updates state.
- Call `notifyOutputChanged()` to push updates.
- Power Apps re-renders to reflect.
**Building.**
```bash
npm install
npm run build
```
Produces a built control ready for packaging.
**Packaging as solution.**
```bash
pac solution init --publisher-name MyPub --publisher-prefix my
pac solution add-reference --path /path/to/control
msbuild /p:Configuration=Release
```
The MSBuild output is a solution ZIP containing the control.
**Deploying.**
- Import solution to environment.
- Add control to model-driven form, view, or canvas app.
- Bind to appropriate field or dataset.
- Test.
## React-based PCFs
Most modern PCFs use React:
- React rendered inside the PCF container.
- Hooks for state.
- React libraries (Fluent UI, Material UI) integrate.
**Common PCF patterns.**
- **Custom field renderers** — image picker, date range, address autocomplete.
- **Dataset visualisations** — grids with custom rendering, kanban boards, calendars.
- **Composite forms** — multi-field input as one control.
- **External library integration** — Chart.js, Mapbox, video players.
**Theming.**
- PCF can access host theme via context.
- Apply theme to match host app's branding.
- Important for visual consistency.
**Accessibility.**
- ARIA attributes mandatory.
- Keyboard navigation must work.
- Focus management.
- High contrast support.
Microsoft accessibility requirements apply; ship-blocking if missing.
**Performance considerations.**
- **Initial load** — keep bundle small; lazy load if possible.
- **Re-renders** — only update what changed.
- **External resource loading** — async; show loading state.
PCFs that block the form's render slow the whole experience.
**Testing.**
- Unit tests for logic.
- Manual testing in app.
- Test framework integration evolving.
**Versioning.**
- Manifest specifies version.
- Solution updates carry new version.
- Apps can lock to specific version or auto-update.
**Common pitfalls.**
- **Bundle size huge.** Include only what's needed; tree-shake.
- **No accessibility.** Fails accessibility audit.
- **External library security.** Vulnerable libraries shipped; security incident.
- **Theme not respected.** Looks out of place in host app.
- **Two-way binding broken.** Updates not propagating.
- **No error handling.** Errors propagate; form crashes.
- **Hardcoded URLs / strings.** Should be configuration.
**ALM considerations.**
- PCFs ship in solutions; same ALM as other components.
- Source control the PCF project.
- CI builds on commit.
- Deploy through standard pipeline.
## Strategic positioning
PCFs are the answer for custom UI needs beyond standard controls. The developer commitment is real — TypeScript, React patterns, manifest discipline, accessibility, performance. For partners maintaining PCFs across customer deployments, treating them as products (versioned, tested, documented) is essential. For one-off needs, sometimes a Canvas Power Apps component is simpler. Use PCFs when the requirements clearly demand them and the team can invest in production-grade development.
---
# Power Apps modern controls
How the modern control set in canvas apps differs from classic controls — Fluent UI styling, accessibility defaults, theming, and migration considerations.
Source: https://www.solvingdynamics365.com/guides/power-apps-modern-controls
Section: Power Platform / Power Apps
Published: 2026-05-01
For years, canvas app controls looked like a 2015 web UI — functional but visually dated. The **modern controls** set, generally available since 2023 and expanding through 2024–2026, replaces the classic controls with Fluent UI–based components that match the look and feel of Microsoft 365. They're not just prettier; they have stricter accessibility defaults, better theming support, and a more constrained API surface.
## The dual control sets
Both classic and modern controls coexist in the editor. Picking between them per control:
- **Modern controls** appear in the "Modern" toolbox section.
- **Classic controls** remain available for backwards compatibility.
A canvas app can mix both — but uniformity is preferable for UX coherence.
**What's available in modern.**
- **Modern Button** — primary, default, accent styles.
- **Modern Text** — typography levels (Title, Subtitle, Body, Caption).
- **Modern Text Input** — single-line, multi-line, password.
- **Modern Dropdown** — replaces the classic dropdown.
- **Modern Combobox** — searchable selection.
- **Modern Date Picker** — calendar-driven date selection.
- **Modern Toggle** — Boolean switch.
- **Modern Slider** — value range.
- **Modern Checkbox / Radio Group.**
- **Modern Spinbutton, Rating, Tab list, Pivot, Persona** — growing list.
The set covers most form scenarios. Less common controls (image, gallery, chart) still use classic.
**Visual differences.**
- **Fluent UI typography and spacing** — matches Office apps.
- **Less skeumorphism, more flat** — clean affordances.
- **Default colour palette tied to theme** — colour follows theme not hard-coded values.
## Theming
Modern controls support **App-level theme**:
- Primary colour, neutral colour, font family.
- Dark/light mode (in development).
- Per-control overrides remain possible but rare.
Setting the theme once cascades through all modern controls. Classic controls don't pick up theme automatically — each control needs explicit colour-binding.
**Accessibility.**
- **Keyboard navigation** out of the box.
- **Screen reader semantics** aligned with WAI-ARIA.
- **Focus rings** visible.
- **Colour contrast** meets WCAG AA defaults.
Classic controls require manual accessibility tuning per control; modern controls bake in baseline accessibility.
## Properties differ
Modern controls have a leaner property set than classic. Some advanced classic properties (font weight, hover colour, micro-positioning) aren't directly exposed — the theming handles them. For makers used to tweaking every property, this is a constraint; for shipping consistent UIs, it's a feature.
## Performance
Modern controls are React-based; the rendering layer is more efficient. Apps with hundreds of controls render measurably faster on modern. The improvement is most visible in galleries and forms with many child controls.
**Migration considerations.**
- **No automatic conversion** — adding a modern control next to an existing classic control means manual property re-binding.
- **Property names may differ** — e.g., `Text` vs `Content`, `OnSelect` vs `OnClick` for some controls.
- **Custom CSS / DOM manipulation** — there isn't any in canvas apps generally, but classic-era hacks via HTML Text controls don't carry over cleanly.
## Mixed apps
Some legacy apps will have classic controls forever. Pattern: build new screens in modern; leave existing screens classic. Don't force a wholesale conversion mid-cycle unless the visual divergence is a problem.
**When classic is still right.**
- **Highly customised visuals** — classic exposes more knobs.
- **Tight backwards compatibility** with existing app patterns.
- **Specific control types** not yet in modern.
**Common pitfalls.**
- **Mixing classic and modern on one screen** — looks visually inconsistent.
- **Custom theming not propagated** — setting per-control colours instead of theme defeats the consistency benefit.
- **Accessibility regressions** — overriding modern defaults to "match" classic loses the accessibility wins.
- **Property mapping errors** — converting an app screen-by-screen and missing event handlers.
## Operational rule
All new canvas apps default to modern controls. App theming set early in development. Existing apps converted to modern when there's a refresh budget — not as forced churn. The visual and accessibility gains compound over the app lifetime; the upfront learning curve is small.
---
# Power Apps monitoring and Application Insights
How to monitor Power Apps in production — App Monitor, Application Insights integration, and the operational patterns for performance and error tracking.
Source: https://www.solvingdynamics365.com/guides/power-apps-monitoring-and-app-insights
Section: Power Platform / Power Apps
Published: 2026-05-01
A Power App in production needs operational visibility — is it slow? Are users hitting errors? Where do they spend time? **App Monitor** provides debugging-focused observation; **Application Insights** integration provides production-grade telemetry. Together, they're the operational toolkit for serious Power Apps deployments.
## App Monitor
Real-time diagnostic tool:
- Launched from Power Apps Studio while user runs the app.
- Streams events as they happen.
- Shows operations: formula evaluations, data calls, errors.
- Replay-style timeline.
For debugging "why does X happen?" in development. Not for production-wide monitoring.
## Application Insights
The Azure Monitor service:
- Long-term telemetry storage.
- Rich querying via KQL.
- Custom dashboards and alerts.
- Correlation across services.
For production observation, this is the path.
**Setup.**
1. Azure subscription with Application Insights instance.
2. Get the **Instrumentation Key** (or Connection String).
3. In Power App, App → Settings → Add Application Insights → enter key.
4. Save and publish.
Telemetry starts flowing.
**What's captured.**
- **Page views** — screens navigated.
- **Events** — explicit Trace() calls.
- **Exceptions** — errors raised.
- **Dependencies** — connector calls (limited).
- **Performance** — operation timing.
- **Custom data** — anything you Trace.
## Trace() function
Manual instrumentation:
```
Trace("UserAction", TraceSeverity.Information, {
action: "Clicked Submit",
formId: SelectedForm.Id
});
```
Add Trace() calls at key points in app logic.
## Querying telemetry
In Application Insights:
```kql
customEvents
| where name == "UserAction"
| where customDimensions.action == "Clicked Submit"
| summarize count() by tostring(customDimensions.formId)
```
KQL is powerful; learn the basics for effective production debugging.
**Custom dashboards.**
- Pin queries to a dashboard.
- Real-time tile updates.
- Different audience-specific dashboards (ops vs business).
**Alerting.**
- Set thresholds (error rate > 5%, response time > 2s).
- Alert via email, Teams, ops tools.
- Action groups for escalation.
Production apps need alerts; without them, issues found by user reports.
**What to trace.**
- **Screen entry / exit** — flow tracking.
- **User actions** — buttons clicked, forms submitted.
- **Errors** — caught exceptions.
- **External calls** — connector results.
- **Performance markers** — long operations.
**What NOT to trace.**
- **Sensitive data** — PII, secrets, financial details.
- **Excessive volume** — per-keystroke events; signal lost in noise.
- **Internal trivia** — info nobody will read.
**Performance metrics.**
- **App load time** — initial render.
- **Screen transition time.**
- **Connector response times.**
- **Total operation duration.**
These align with user-perceived performance; track and optimise.
**Error tracking.**
- Caught errors traced explicitly.
- Uncaught errors auto-captured to App Insights.
- Stack traces (where available).
- User session context.
**User identification.**
- Anonymous by default.
- Add user identity to telemetry for debugging specific user issues.
- Respect privacy — don't trace more than necessary.
**Comparison with App Monitor.**
| Aspect | App Monitor | App Insights |
|---|---|---|
| Use | Dev debugging | Production monitoring |
| Live data | Yes | Near-real-time |
| Historical | No | Yes |
| Query | Limited | KQL |
| Alerting | No | Yes |
| Cost | Free | Azure consumption |
Both have place; use both.
**Cost considerations.**
- App Insights priced per GB ingested.
- High-traffic apps with verbose tracing → meaningful cost.
- Sampling — record only X% of events to reduce cost.
- Daily cap — limit max ingestion.
For production apps with > 1000 daily users, budget App Insights cost.
**Common pitfalls.**
- **No tracing.** Production issues invisible.
- **Over-tracing.** Cost explodes; signal lost.
- **Sensitive data in traces.** Privacy / compliance issue.
- **No alerts.** Issues exist; nobody knows.
- **Dashboards unmaintained.** Built once, never updated, ignored.
- **Cross-app correlation.** Multiple Power Apps with separate App Insights → can't correlate.
**Best practices.**
- **Standard tracing patterns** across apps in the same domain.
- **Centralised App Insights** for portfolio observability.
- **Documented KQL queries** for common diagnostic scenarios.
- **Runbook integration** — alert links to specific queries.
- **Regular review** — what's traced, what's needed, what's noise.
**Power Automate monitoring.**
- Flow run history is the primary visibility.
- Can also emit to App Insights from flows (HTTP action).
- For high-volume flows, App Insights is the long-term store.
## Strategic positioning
Production Power Apps without monitoring are operationally opaque. App Insights closes the visibility gap; the discipline of tracing and querying is what unlocks the value. For any app with significant production usage, treat App Insights as standard equipment. The cost is moderate; the operational benefit is substantial. The teams that take production observability seriously have boring incident reviews; the teams that don't have long, painful ones.
---
# Power Apps performance tuning
How to make Power Apps canvas and model-driven apps fast — startup time, screen render, data fetching, formula optimisation, and the patterns that matter.
Source: https://www.solvingdynamics365.com/guides/power-apps-performance-tuning
Section: Power Platform / Power Apps
Published: 2026-07-20
A Power App that takes 30 seconds to open and 5 seconds per screen transition gets ignored by users. Performance is the difference between adoption and shelfware. The patterns to make canvas apps and model-driven apps fast are well-known but not obvious to first-time makers.
**Canvas app performance.**
**1. Reduce startup time.** Canvas apps run a substantial OnStart sequence loading data, setting variables, initialising. Minimise the OnStart work:
- Move non-critical initialisation to **OnVisible** of the first screen (deferred until needed).
- **Concurrent()** function to run multiple operations in parallel rather than sequence.
- Cache only what's needed for the first screen; load deeper data lazily.
- Avoid huge collections on startup; load on demand.
A well-tuned canvas app opens in 2-3 seconds; a poorly-tuned one takes 15-30.
**2. Minimise data fetched.** Every Dataverse / SharePoint / SQL call has latency. Reduce:
- Use **`Filter()`** with proper delegable filters to push work to the server.
- Select specific columns with `ShowColumns()` rather than fetching all.
- Avoid `LookUp()` in galleries — it queries per row, devastating for large galleries.
- Page large lists; don't load 10,000 records on screen load.
**3. Delegation.** Functions like `Filter()`, `Sort()`, `Lookup()`, `Search()` are **delegable** — they run server-side on the data source. Non-delegable functions force client-side processing limited to ~2000 rows. The maker portal warns about non-delegable expressions; address them:
- Replace non-delegable string operations with delegable equivalents.
- Move complex calculations to Dataverse formula columns or rollup columns.
- Refactor formulas to be delegable.
**4. Limit gallery work.** Each gallery item evaluates its formulas. A gallery of 100 items with complex formulas in each item evaluates 100 times the work:
- Hoist computations out of the gallery to a single Pre-computed variable.
- Use `With()` to compute once and reference repeatedly.
- Limit visible items; lazy-load on scroll.
- Pre-compute formatted strings rather than computing inline.
**5. Image optimisation.** Images can dominate app load:
- Resize images to display size before uploading; don't load 5MB photos to display as thumbnails.
- Use SVG for icons (small, scalable).
- Lazy-load images that aren't immediately visible.
**6. Avoid heavy controls.** Some controls (PDF Viewer, deeply-nested containers, large data tables) are heavyweight. Use them sparingly; consider lighter alternatives.
**Model-driven app performance.**
Model-driven apps are mostly platform-rendered; tuning is different from canvas.
**1. Form load time.** Each form's load triggers:
- Data fetch for the record.
- Related-record fetches for subgrids, quick views, lookups.
- JavaScript handler execution.
- Business rule evaluation.
Tune by:
- **Limit subgrids on the form** — 5–10 is typical; more slows load.
- **Defer non-critical data** — use the *Default state* properties to load tabs lazily.
- **Avoid JavaScript async calls in OnLoad** — they block the form render.
- **Limit business rules** — many overlapping rules slow evaluation.
**2. View performance.** Lists that load slowly:
- **Index the columns** used in default filters and sorts.
- **Limit columns shown** — fewer columns = faster query.
- **Limit default rows** — don't show 10,000 rows by default; let users filter to a manageable subset.
**3. Search performance.** Quick Find and Advanced Find:
- Quick Find indexes only configured columns; verify the relevant ones are configured.
- Dataverse Search (the modern global search) is generally faster than Quick Find for cross-table search.
**4. Plug-in performance.** Plug-ins synchronous to record operations add latency:
- Profile plug-in execution; long-running plug-ins block users.
- Use **asynchronous plug-ins** for non-critical work.
- Cache lookups within a plug-in execution.
**General principles.**
- **Profile before optimising.** Browser dev tools (Network tab), the Power Platform admin centre's analytics, and Application Insights tell you where time is actually spent. Optimise the slow parts, not what you imagine to be slow.
- **Test with real data.** A 50-record dev environment performs differently from a 5-million-record production. Validate at scale.
- **Test on representative devices.** Mobile, low-bandwidth, older browsers — the app needs to be usable for all users, not just admins on fast desktops.
- **Set performance budgets.** "Form must load in under 3 seconds at p95." Measure; fail the budget = refactor.
## Telemetry
App Insights configured at the app level captures user interactions and timings. Build dashboards showing:
- Page load times per app per screen.
- Action durations.
- Error rates.
- User counts per app.
The data drives prioritisation — optimise the screens users actually use.
**Common pitfalls.**
- **OnStart bloat** — accumulating initialisation logic; app start time grows linearly.
- **Non-delegable warnings ignored** — the app works in dev with 100 records; production with 100,000 hits the 2000-row delegation cap and is silently wrong.
- **Subgrid proliferation** — every form has 15 subgrids "in case someone needs them"; loading is glacial.
- **Custom HTML web resources** doing heavy DOM work; degrade form responsiveness.
## Operational reality
Performance is a continuous discipline. Schedule periodic performance reviews; tune as data volume grows; budget refactoring time as part of operations.
---
# Power Apps Portals history and rebranding to Power Pages
From ADXStudio to Dynamics 365 Portals to Power Apps Portals to Power Pages — the product genealogy and what the rebranding means for customers.
Source: https://www.solvingdynamics365.com/guides/power-apps-portals-history-and-rebranding
Section: Power Platform / Power Apps
Published: 2026-05-01
The product now called **Power Pages** has had several names over the past decade. Older documentation, older training materials, and the institutional vocabulary of long-time partners all reflect prior names. Understanding the lineage helps when reading legacy content and explaining the product's trajectory.
## ADXStudio (2002–2015)
The origin:
- Canadian company building portals for Dynamics CRM customers.
- Open-source-ish base; commercial product.
- Liquid templating, table permissions, web roles — concepts still alive today.
- Acquired by Microsoft in 2015.
## Dynamics 365 Portals (2016–2018)
First Microsoft incarnation:
- ADXStudio rebadged.
- Integrated with Dynamics 365.
- Available as add-on to D365 customer subscriptions.
## Power Apps Portals (2019–2022)
Power Platform alignment:
- Renamed Power Apps Portals when Microsoft re-aligned the broader Dataverse / Power Platform story.
- Same product, slight feature evolution.
- Sold as Power Apps capacity-based licensing.
## Power Pages (2022–)
Current branding:
- Renamed Power Pages.
- Modernised authoring experience (Design Studio).
- AI-assisted page creation (Copilot).
- Stronger focus on low-code makers vs developer customisation.
The product underneath has continuity; the surface has been progressively modernised.
**Concepts preserved from ADXStudio.**
- **Liquid templating language** — used throughout.
- **Entity / table permissions** — record-level access control.
- **Web roles** — group users for permissioning.
- **Web templates** — reusable HTML/Liquid templates.
- **Entity forms / entity lists** — Dataverse data rendering.
- **Web files** — static content (images, CSS).
A developer familiar with ADXStudio finds Power Pages's underlying model immediately familiar.
**Modernisation in Power Pages.**
- **Design Studio** — visual page builder.
- **Themes** — modern theming.
- **Copilot** — AI-suggested pages, content, code.
- **Pages tied to Dataverse Pages mode** — newer pattern.
- **Improved performance** — CDN-based content delivery.
The maker experience is faster and more modern than ADX-era.
**Two authoring modes.**
- **Design Studio** — visual, drag-and-drop. For makers.
- **Portal Management app** — table-level editing. For developers/admins.
Most makers use Design Studio; deep customisation uses Portal Management.
## Authentication providers
Evolved over time:
- Initially Microsoft-only.
- Added Azure AD, social providers (Google, Facebook).
- Now: Entra External ID is the canonical B2C identity provider; supports SAML, OIDC, local accounts.
**Use cases.**
- **Customer self-service portals** — case submission, knowledge browsing.
- **Partner portals** — partner enablement.
- **Supplier portals** — vendor self-service for F&O.
- **Community forums.**
- **Public-facing websites** — though typically not pure Power Pages; CMS for content.
- **Industry-specific portals** — healthcare patient, banking customer.
**Licensing evolution.**
- **Pay-per-user** — per authenticated user / login.
- **Pay-per-login** — per session.
- **Capacity-based** — purchased capacity tiers.
Current: capacity-based, with anonymous and authenticated session tiers.
**Comparison with custom-built portals.**
- **Power Pages** — fast to build; Dataverse-integrated; managed by Microsoft.
- **Custom React + Dataverse API** — flexibility; more dev work.
- **SharePoint** — for intranet-style scenarios.
Power Pages wins for Dataverse-centric portals at moderate complexity; custom builds win for highly bespoke UX.
## Migration considerations
From older portal versions to Power Pages:
- Core data and configuration migrate.
- Custom Liquid templates carry over.
- Visual styling may need refresh.
- Authentication providers updated.
Microsoft provides migration guidance per legacy version.
**Common Liquid patterns.**
```liquid
{% assign cases = entities.incident | where: 'customerid', user.contactid %}
{% for case in cases %}
{{ case.title }} — {{ case.statecode }}
{% endfor %}
```
Liquid is the templating language for dynamic content.
## Power Pages Pro Code
For developers extending beyond no-code:
- VS Code with Power Pages extension.
- Edit Liquid, JavaScript, CSS in code.
- Deploy via Power Platform CLI.
This is the developer surface; makers use Design Studio.
**Common pitfalls during transition.**
- **Sticking with old terminology.** Customers say "portal"; product team says "page" — confusion.
- **Migrating without redesign.** Legacy visual style brought forward; outdated UX.
- **Authentication migration overlooked.** Old social providers deprecated; users locked out.
- **Performance regression.** Lift-and-shift without optimisation; pages slow.
## Strategic positioning
Power Pages is the strategic direction for Dynamics 365 customer-facing portals. Power Apps Portals customers should plan to embrace the new branding and capabilities; older Dynamics 365 Portals or ADX customers face a more substantial modernisation. For new portal initiatives, Power Pages is the natural choice — integrated, supported, evolving.
The product underneath has nearly two decades of evolution; the latest branding is the modernised face. Understanding both the lineage and the trajectory helps customers and developers plan appropriately.
---
# Power Apps Test Engine
How the Power Apps Test Engine enables automated UI testing for canvas apps — test definitions, the YAML format, integration with CI/CD.
Source: https://www.solvingdynamics365.com/guides/power-apps-test-engine
Section: Power Platform / Power Apps
Published: 2026-05-01
Canvas apps grew up without good automated testing tooling. Manual testing is slow and unreliable; user-driven testing in production is even worse. The **Power Apps Test Engine** (formerly known by various names) is Microsoft's answer: a declarative test framework for canvas apps integrated with the Power Platform CLI.
**What the Test Engine does.**
- Drives canvas apps programmatically.
- Asserts on app state, control values, screen transitions.
- Records test executions for review.
- Integrates with CI/CD pipelines.
It's like Selenium but specifically designed for canvas Power Apps' rendering model.
## Test format
YAML-based:
```yaml
testSuite:
testSuiteName: My Tests
testSuiteDescription: Tests for the order app
appLogicalName: my-order-app
testCases:
- testCaseName: User can create order
testCaseDescription: ...
testSteps: |
Assert(CountRows(Orders) = 0);
SetProperty(Button1.Visible, true);
Select(Button1);
Assert(CountRows(Orders) = 1);
```
The test steps use Power Fx — the same language as the app itself, making tests readable to makers.
## Test execution
Via Power Platform CLI:
```bash
pac test run --test-plan-file myTests.yaml --tenant-id ... --environment-id ...
```
The CLI launches headless browser, runs the tests, captures results.
**Selection mechanisms.**
- **By control name** — `Select(MyButton)`.
- **By value** — find controls by text content.
- **By position** — for galleries.
The selector model is straightforward; less brittle than CSS-selector-based tools.
**Assertions.**
- `Assert(expression)` — verifies the expression is true.
- Compare values, counts, properties.
- Custom error messages.
Failures are captured with screenshots.
**Setting values.**
- `SetProperty(Control.Property, value)` — directly set a property.
- Simulates user input.
## Test data isolation
A challenge:
- Tests that create data leave residue.
- Subsequent tests may see prior test's data.
- Mitigation: dedicated test environment; cleanup steps in test teardown.
For production CI, tests run against test environment with clean state.
**Integration with CI/CD.**
- GitHub Actions / Azure DevOps task wraps `pac test`.
- Runs on every PR or scheduled.
- Failure flags PR; prevents merge.
This is the discipline that catches regressions before production.
**Limitations.**
- **Canvas apps only** — model-driven app testing requires different tools.
- **Limited connector mocking** — tests run against real connections; can be slow or test-fragile.
- **Browser-based** — same browser quirks affect tests.
- **Authentication setup** — tests need credentials.
**Mocking connectors.**
- Some support for mocking external calls.
- Capabilities expanding per release.
- Test environment with isolated services preferred over mocking.
**Test patterns.**
- **Happy path tests** — primary user flow.
- **Edge case tests** — empty data, max data, boundary values.
- **Negative tests** — invalid input handled.
- **Performance tests** — operation duration within budget.
For meaningful coverage, multiple test types.
## Coverage
Test coverage tooling for Power Apps less mature than for code:
- Manual tracking of which scenarios tested.
- Periodic review of gaps.
**Comparison with manual testing.**
| Aspect | Manual | Test Engine |
|---|---|---|
| Setup time | Low | Higher |
| Per-run time | High | Low |
| Repeatability | Low | High |
| Coverage | Variable | Documented |
| CI integration | None | Native |
| Regression detection | Slow | Immediate |
For any app with significant change rate, Test Engine pays back; for static apps, manual may suffice.
**Common pitfalls.**
- **Flaky tests.** Timing-dependent failures; tests fail randomly.
- **Test data pollution.** Each run leaves residue; subsequent tests see stale data.
- **Brittle selectors.** Control renamed; test breaks.
- **Authentication friction.** Test user credentials handling poorly; CI fails on auth.
- **No teardown.** Test creates data; never cleans up.
- **Test = production.** Tests run against production environment; risky.
**Best practices.**
- **Dedicated test environment.** Isolated; refreshed periodically.
- **Test users with appropriate roles.** Just enough access.
- **Idempotent tests.** Can run repeatedly without different outcomes.
- **Clear test names.** Failure logs are interpretable.
- **Test as code.** YAML files in source control alongside app source.
## Beyond Test Engine
Some teams also use:
- **External tools** — Cypress, Playwright with API integration.
- **Manual exploratory testing** — for UX issues automation can't catch.
- **A/B testing** — production traffic split.
Test Engine is one tool in a broader testing strategy.
**Operational rhythm.**
- **Per commit** — fast tests run.
- **Per PR** — full suite runs.
- **Nightly** — extended suite including long-running tests.
- **Pre-release** — full regression against production-like data.
## Strategic positioning
Automated testing for canvas apps has lagged general software development. Test Engine closes the gap but doesn't eliminate the maturity differential. For apps with significant production traffic, the investment in test automation pays back in confidence and reduced regression rate. For prototype-stage apps, manual testing remains the pragmatic choice. As Test Engine matures and more makers adopt CI/CD practices, automated testing for canvas apps will become standard practice rather than the exception.
---
# Power Apps vs Dynamics 365 CRM
Power Apps vs Dynamics 365 CRM: both run on Dataverse — when to buy the packaged Sales or Service app and when to build a custom model-driven app instead.
Source: https://www.solvingdynamics365.com/guides/power-apps-vs-dynamics-365-crm
Section: Power Platform / Power Apps
Published: 2026-08-27
Updated: 2026-08-27
"Should we build a custom Power App or buy Dynamics 365?" comes up in every Microsoft business-apps conversation, and the honest answer is that they solve overlapping but different problems. Both run on Dataverse. Both use the same tools to extend. But one ships pre-built with sales / service / field-service processes baked in, and the other is a blank canvas.
This guide walks the decision in the shape it takes in real deals.
## What each actually is
**Dynamics 365 CRM** (Sales, Customer Service, Field Service, Marketing, Customer Insights, Project Operations) is a collection of **pre-built model-driven Power Apps on top of Dataverse**. Microsoft configured the tables, the relationships, the security roles, the business process flows, the workflows, the dashboards, and the mobile experiences for the specific business processes each app targets. You buy the app, get a working starting point on day one, and configure or extend it to fit your business.
**Power Apps** is the platform underneath. A custom Power App is a Power App you build yourself — either **canvas** (drag-and-drop pixel-perfect designs with Power Fx formulas) for task-specific workflows, or **model-driven** (data-centric UI generated from Dataverse metadata) for record-heavy processes with security roles and complex forms. You get a blank Dataverse environment and build whatever you want on it.
Architecturally the two are identical below the app layer. Extending Dynamics 365 uses the same tools, the same solutions, the same Dataverse, the same governance as building a custom Power App from scratch.
## When to buy Dynamics 365
Buy Dynamics 365 when the business process you're implementing **matches the shape of a shipped app**:
- **Sales.** B2B pipeline management, opportunity tracking, forecasting, quoting, Copilot for Sales inside Outlook.
- **Customer Service.** Case management, omnichannel, knowledge management, SLAs, entitlements, agent copilot.
- **Field Service.** Work orders, scheduling, mobile technician app, connected assets, IoT.
- **Marketing / Customer Insights - Journeys.** Customer journeys, email marketing, event management.
- **Project Operations.** PSA — opportunity to cash for services firms.
The shipped apps carry decades of learned best practice about how these processes work. Rebuilding an opportunity-to-close pipeline in a custom Power App is possible but wasteful — you spend a year recreating what Sales gives you on day one, and the year of feature investment you'd have needed to keep it competitive with Sales' quarterly Wave updates never happens.
## When to build a custom Power App
Build a custom Power App when the process is **specific to your business and doesn't map to a shipped app**:
- A **field-inspection app** for a specific regulated industry — inspection templates, photo capture, compliance sign-off — that doesn't fit Field Service's work-order model.
- A **manufacturing floor tracking app** for a specific production line — barcode scan, batch attributes, custom quality gates.
- An **internal-approvals app** — travel requests, capex approvals, procurement pre-authorisation — that's uniquely shaped by your policy.
- A **customer-facing portal** on Power Pages that doesn't need Dynamics 365's back-end.
- A **legacy-system-front-end** app that surfaces data from an on-prem system through virtual tables without duplicating it into Dataverse.
The pattern: highly specific to your business, low overlap with any shipped CRM app, and a working prototype in 2-4 weeks with a small team.
## When to do both
The common pattern is **Dynamics 365 for the core CRM process, custom Power App(s) for the adjacent workflows** the CRM doesn't cover naturally.
A field-service business runs **Dynamics 365 Field Service** for work orders, dispatch, and mobile technicians, then adds a **custom Power App** for the pre-work customer-site-audit workflow that Field Service's data model doesn't fit cleanly. Both apps share the same Dataverse, the same Account and Contact records, the same Copilot layer. The custom app is not "instead of" Field Service — it's alongside it.
The custom app benefits from Field Service being there: shared identity, shared master data, shared reporting. Field Service benefits from the custom app being there: the customer's full pre-work data is on the customer timeline for the technician to reference.
## The economics
**Dynamics 365 CRM** is per-user per-month at a real price point. Sales Enterprise is around $95/user/month; Customer Service Enterprise similar. Attach licensing reduces the second-app cost.
**Power Apps** licensing is either **per-app** (approx $5/user/month per app) or **per-user** (approx $20/user/month for unlimited apps). Substantially cheaper per user than Dynamics 365, but you also get less — you're building the app yourself.
For a custom app that would replace Dynamics 365 Sales, add up the build cost (engineering time to build, plus the feature investment you'd need to keep it competitive over five years) against the licence saving (approximately $75/user/month × user count × 60 months). For most sales-org sizes the build cost dwarfs the licence saving.
For a custom app in a workflow Dynamics 365 doesn't cover, the licence saving is real because there's no Dynamics 365 licence to buy in the first place.
## The failure modes
Two common failure modes deserve calling out.
**"Let's build custom because Dynamics 365 is too much."** This is the argument to run away from features you'll wish you had in a year. Sales' forecasting, sequences, sales accelerator, Copilot for Sales — these are years of Microsoft investment. If your process fits Sales, use Sales. The "we'll build a simpler version" instinct almost always ends with the custom app slowly growing to match what Sales already does, at your cost.
**"Let's buy Dynamics 365 because Power Apps is too complicated."** This is the argument that shows up when the actual business process is genuinely unique. Dynamics 365 was configured for the *typical* sales / service / field-service workflow. If your workflow deviates materially — different data model, different lifecycle, different UX — you fight the shape of Dynamics 365 to force it to fit, and every quarter's Wave brings changes that break your customisations. Better to build the custom app that fits the process.
The decision is not "how sophisticated am I" — it is "does my process match the shipped app's shape."
## The short version
Dynamics 365 CRM = pre-built Power Apps for sales / service / field-service. Power Apps = the platform underneath for building your own.
Buy Dynamics 365 when your process matches a shipped app. Build a custom Power App when your process is genuinely specific. Do both when there's a core CRM process alongside adjacent workflows that don't fit the shipped app. Don't build a custom replacement for a shipped app unless you're prepared to fund the feature roadmap yourself.
## Where to go next
The build side starts with [canvas apps vs model-driven apps](https://www.solvingdynamics365.com/guides/canvas-apps-vs-model-driven-apps) on [Dataverse](https://www.solvingdynamics365.com/guides/what-is-microsoft-dataverse); the general principle is [build vs buy in the Dynamics 365 ecosystem](https://www.solvingdynamics365.com/guides/build-vs-buy-in-the-dynamics-365-ecosystem). The economics come from [Dynamics 365 licensing explained](https://www.solvingdynamics365.com/guides/dynamics-365-licensing-explained) and the [Power Apps](https://www.solvingdynamics365.com/pricing/power-apps) and [Sales](https://www.solvingdynamics365.com/pricing/sales) pricing pages.
### Frequently asked questions
**What is the actual relationship between Power Apps and Dynamics 365 CRM?**
Dynamics 365's CRM apps are pre-built model-driven Power Apps on Dataverse. Buying Dynamics 365 buys you Microsoft's configuration of tables, security roles, process flows and dashboards for a specific business process. Building on Power Apps means starting from a blank Dataverse environment.
**How do the license costs compare?**
Dynamics 365 Sales Enterprise is around 95 dollars per user per month; Power Apps is roughly 5 dollars per user per app or 20 dollars per user for unlimited apps. Power Apps is much cheaper per seat, but you are building — and maintaining — the application yourself.
**When is building custom a mistake?**
When your process actually fits a Dynamics 365 app. Forecasting, sequences, the sales accelerator and Copilot for Sales represent years of Microsoft investment; a 'simpler custom version' almost always grows back toward what Sales already does, at your cost.
**When is buying Dynamics 365 the mistake?**
When the workflow deviates materially from the typical sales or service shape — different data model, lifecycle and UX. Then you end up fighting the shape of Dynamics 365, and release waves keep breaking your workarounds. Build the app that fits the process instead.
---
# Power Automate approvals in depth
How the Approvals platform works under Power Automate — connector, approval types, delegation, the unified approval centre.
Source: https://www.solvingdynamics365.com/guides/power-automate-approvals-in-depth
Section: Power Platform / Power Automate
Published: 2026-05-01
Approvals are one of the most common Power Automate scenarios — purchase requests, expense submissions, document reviews, time-off requests. The **Approvals** built-in connector wraps an underlying Dataverse-backed approval engine that's more capable than the simple "yes/no" pattern most flows implement.
**Approval types.**
- **Approve/Reject — First to respond** — the first approver wins.
- **Approve/Reject — Everyone must approve** — all approvers must say yes.
- **Custom Responses — Wait for all responses** — multi-choice responses (Approve, Reject, More info), require all.
- **Custom Responses — Wait for one response** — multi-choice, first response wins.
The right type per scenario:
- **Sequential single approver** — First to respond with one approver.
- **Parallel approval** — First to respond with multiple approvers (escalation).
- **Council/board decisions** — Everyone must approve.
- **Multi-option workflows** — Custom responses with paths per choice.
**Approval lifecycle.**
1. **Create an approval** with type, title, details, approvers.
2. **Wait for approval response** — flow pauses; approvers receive notifications (email, Teams, mobile push).
3. **Response captured** — outcome and comments.
4. **Flow continues** with branching based on outcome.
The flow is *idle* during the wait — no resource cost until response arrives. Approvals can wait for hours, days, or months without timing out.
**Notification channels.**
- **Email** — actionable cards with approve/reject buttons.
- **Teams** — adaptive card; tap-to-approve.
- **Mobile app** — Power Automate mobile sends push notifications.
- **Web** — the Approvals page at make.powerautomate.com.
The approver can use any channel; all sync through the underlying Dataverse table.
## Approval centre
The user's view of pending and historical approvals:
- **Received** — approvals awaiting their action.
- **Sent** — approvals they initiated (created).
- **History** — closed approvals.
For users with high approval volume, the centre is the working surface.
## Adaptive cards
Approval notifications use **Adaptive Cards** — JSON-defined cards that render in Teams, Outlook, and Microsoft Loop. Custom Approvals support rich card content: tables, images, multiple action buttons, dropdowns.
## Delegation
Approvers can delegate:
- **In-product delegation** at the user's M365 settings — "while I'm away, route my approvals to X."
- **Programmatic re-assignment** within a flow — if the original approver hasn't responded in N hours, escalate.
For finance leads, delegation is essential to keep approval cycles moving during PTO.
## Reminders and escalations
Native reminders aren't built into the simple approval pattern. Common implementation:
- Start approval.
- Configure a parallel wait branch with a timeout.
- After timeout, send reminder email or escalate to a different approver.
For more sophisticated escalation, a "child flow" pattern triggers nudges and updates.
## Multi-stage approvals
A typical purchase approval:
1. Manager approves.
2. If approved and amount > $5K, director approves.
3. If approved and amount > $50K, CFO approves.
Build sequentially with branching, or use sub-flows per stage for cleanliness.
## Audit trail
Every approval has a full record:
- Requestor.
- Approvers (assigned, responded, when, comment).
- Status changes.
- Linked documents.
The Dataverse `Approvals` table is queryable. For compliance reporting, a Power BI dashboard over the Approvals table shows median time-to-decision, denial rate, and bottlenecks.
## Approval data structure
Each approval is a row in the `Approval` Dataverse table; responses are rows in `Approval Response`. Standard Dataverse permissions apply — solution-aware, security-roled, exportable.
**Common pitfalls.**
- **Long-stalled approvals.** No reminders, no escalation, sits forever. Always design escalation.
- **Wrong type chosen.** Using "First to respond" when "Everyone must" was intended; bypassed approvals.
- **Sensitive data in approval details.** The details show in emails to potentially unauthorised forwarders; redact sensitive content.
- **Approver list hard-coded.** A flow with John as approver breaks when John leaves. Look up approvers dynamically (manager from M365, role-based from Dataverse).
- **Notifications missed.** Approver on PTO without delegation; flow stalls. Build delegation discipline.
## At scale
A company running thousands of approval flows benefits from:
- **Approval templates** — standardised flows for common patterns; makers reuse.
- **Approval portal** — a custom Power Apps page showing all pending approvals with filtering, useful for execs with high volume.
- **Approval analytics** — Power BI dashboard on Dataverse approval data.
## Operational guidance
The Approvals connector is one of the most reliable, performant parts of Power Automate. Use it generously. The trap is treating each approval flow as a one-off; with templates and consistent patterns, approval flows become a managed asset rather than scattered code.
---
# Power Automate child flows
How child flows decompose Power Automate workflows into reusable pieces — definition, invocation, parameters, and the operational impact on maintainability.
Source: https://www.solvingdynamics365.com/guides/power-automate-child-flows
Section: Power Platform / Power Automate
Published: 2026-07-22
A Power Automate flow with 50 actions, branches, loops, and error handling is unmaintainable. **Child flows** solve this — let one flow invoke another, encapsulating reusable logic in a separate flow that can be developed, tested, and maintained independently.
## What a child flow is
A child flow is a normal Power Automate cloud flow with two characteristics:
- It's triggered by **Power Apps** or **HTTP request** (not by a Dataverse / SharePoint / scheduled trigger).
- It returns a value through a **Response** action (or in the case of HTTP, an HTTP response).
The "trigger by HTTP request" pattern is what enables child flows. A parent flow calls the child by sending an HTTP-style invocation; the child runs; the parent receives the response.
**Why child flows.**
- **Reusability.** A common pattern (e.g. "validate customer credit", "generate a quote PDF", "send a personalised email") used in many places gets implemented once as a child flow; many parent flows call it.
- **Maintainability.** Smaller flows are easier to understand, test, modify. Splitting a 100-action mega-flow into a parent and several child flows produces 5 flows of 20 actions each — substantially more tractable.
- **Versioning.** Child flows version independently; changes to the child flow don't require modifying every parent.
- **Permissions and ownership.** Different teams can own different child flows; integration is clean.
- **Performance** — sometimes. Each child flow invocation has overhead; for small operations the overhead exceeds the encapsulation benefit. Use for substantial logic blocks, not trivial ones.
**Implementing a child flow.**
1. **Create the child flow.** Trigger: "When an HTTP request is received" (or "PowerApps").
2. **Define inputs.** The HTTP trigger has a JSON schema for the request body; structure inputs as JSON properties.
3. **Implement logic.** Standard Power Automate actions.
4. **Return output.** End with a **Response** action returning JSON with the output data.
5. **Save and copy the URL.** The HTTP trigger generates a unique URL when saved; the parent flow uses this URL to call the child.
**Calling a child flow from a parent.**
1. In the parent flow, add an **HTTP** action.
2. Set method to POST.
3. URL to the child flow's invocation URL.
4. Body to the JSON payload matching the child's input schema.
5. Add a **Parse JSON** action to parse the child's response.
6. Use the parsed outputs in subsequent actions.
The pattern is functional but verbose. Microsoft has been improving the experience with native "Run a child flow" actions — but the underlying mechanism is HTTP.
**Error handling.**
- **Child flow errors** — if the child flow fails, the HTTP call returns an error status. The parent must handle.
- **Retry policy** — the HTTP action's retry configuration governs how many times to retry on child failure.
- **Compensation** — if a child flow performs side effects then fails, the parent may need to roll back. Design for it.
**Performance considerations.**
- Each child-flow invocation has HTTP overhead — typically hundreds of milliseconds.
- For high-frequency calls (a parent that calls a child 1000 times), the overhead dominates.
- For substantive child operations (each running for seconds or minutes), the overhead is negligible.
**Limits.**
- **HTTP action requires premium connector** — flows using HTTP need premium Power Automate licences.
- **Loops over child invocations** — Apply to Each calling a child for each record can hit timing / throughput issues at scale. Consider batching.
- **Schema-evolution awareness** — when a child flow's input or output schema changes, all parent flows need updating. Treat as API versioning.
**Patterns and examples.**
- **Authentication helper** — a child flow that, given a token request, returns a Bearer token. Parent flows call it before making external API calls.
- **Audit log helper** — a child flow that records an entry in the audit log Dataverse table. Many parent flows call it to log significant events.
- **PDF generation helper** — a child flow that, given record data, generates and stores a PDF. Many parent flows trigger document generation.
- **Notification orchestrator** — a child flow that handles multi-channel notification (email + SMS + Teams) based on user preferences. Parent flows just say "notify".
## Solution and ALM
Child flows live in solutions like any flow. Reference between solutions:
- **Same solution** — child and parent in the same solution; deploy together.
- **Different solutions** — child flow in a "shared services" solution, parents in different feature solutions. The parent flows reference the child by ID.
For ALM, the parent's HTTP URL is environment-specific; use **environment variables** to abstract the URL.
**Common pitfalls.**
- **Child flow URL hard-coded** — different environments have different URLs; manual update required at each deploy. Use environment variables.
- **Synchronous vs async confusion** — child flow runs synchronously to the HTTP call; if it's long-running, the parent waits. For long operations, consider passing a callback URL for asynchronous notification.
- **Permission propagation** — the child flow runs as its owner's identity, not the parent's. If the child needs the parent's user context, pass relevant context as input.
## Operational reality
For Power Automate work that grows beyond simple flows, child flows are the maintainability lever. Adopt them early; refactor existing complex flows incrementally as opportunities arise.
---
# Power Automate connectors for Dynamics 365
The standard and premium Power Automate connectors for Dynamics 365 — what each one does, the differences, and the licensing implications.
Source: https://www.solvingdynamics365.com/guides/power-automate-connectors-for-dynamics-365
Section: Integrations / API & identity
Published: 2026-05-01
Power Automate connectors are the bridges between flows and other systems. For Dynamics 365 customers, several connectors matter — and the difference between standard and premium connectors is important for licensing and capability.
## Microsoft Dataverse connector
The right connector for any CRM-side D365 app (Sales, Customer Service, Field Service, Project Operations, Customer Insights, Power Apps with Dataverse). Triggers on row created/updated/deleted/added; actions for full CRUD, executing actions, file uploads, and relating records. Supports filtering and column selection. Premium connector — flows using it require a Power Automate per-user or per-flow licence beyond what's included with most Dynamics 365 SKUs.
## Common Data Service (current environment) connector
The older name; functionally equivalent and being phased out in favour of "Microsoft Dataverse". Still appears in older flow templates.
## Dynamics 365 connector (legacy)
An older connector for CRM-side apps, predating Dataverse-native. Microsoft recommends migrating to the Dataverse connector.
## Dynamics 365 Business Central connector
First-party. Triggers and actions for Customer, Vendor, Item, Sales Order, Purchase Order, Sales Invoice, Sales Quote, Journal Lines, Locations, and many more. Standard CRUD and bound actions for posting, releasing, and cancelling documents. Premium.
## Dynamics 365 Finance and Operations (legacy) connector
Targets F&O data entities. Premium.
## Dynamics 365 for Fin & Ops (Recurring Integrations)
A separate connector that targets the recurring integration API for batched data project imports/exports.
## Custom connectors
When the first-party connector doesn't expose what you need, build a **custom connector** from an OpenAPI/Swagger definition. Custom connectors are premium and use the same authentication and policy framework as built-in ones.
## Licensing
This is where teams get caught out. A flow that uses *only* standard connectors (SharePoint, Outlook, Teams, Office 365) can run on the free Power Automate licence bundled with M365. A flow that uses a **premium connector** — Dataverse, Business Central, F&O, SQL Server, HTTP, custom connector — requires a *premium* Power Automate licence on the **flow owner**. Per-user (one user, unlimited flows) or per-flow (one flow, unlimited users) plans are available. Most Dynamics 365 SKUs include limited premium Power Automate rights, often labelled *"Power Automate for Dynamics 365"* — these allow flows that are **directly related to the licensed Dynamics 365 app**, but not arbitrary Power Automate use.
## Throttling
Each connector has request limits per user per 24h, plus shorter spike limits. Bursty flows can hit the limits and produce HTTP 429s. Throttle limits are documented per connector; the most common D365 connector limits are generous but real.
## The pattern
For any non-trivial flow involving Dynamics 365, plan: which premium connectors does it call, who owns it, what licence does the owner have.
---
# Power Automate Desktop and RPA
How Power Automate Desktop automates legacy applications with RPA — attended vs unattended, machine groups, AI Builder integration, and where to use it.
Source: https://www.solvingdynamics365.com/guides/power-automate-desktop-and-rpa
Section: Power Platform / Power Automate
Published: 2026-05-01
**Power Automate Desktop (PAD)** is Microsoft's Robotic Process Automation (RPA) tool — the bit of the Power Automate stack that drives the user interface of *other applications*, including legacy desktop apps, terminal emulators, ancient web apps, and anything else without a usable API. For Dynamics 365 customers, PAD is the bridge to systems that haven't joined the API era yet.
**Attended vs unattended.**
- **Attended RPA** — the bot runs on a user's own desktop while the user is logged in. The user triggers it (or it triggers from a Power Automate cloud flow), watches it work, and can intervene. The right pattern for assistant bots: a salesperson clicks a button, the bot opens a legacy CRM, copies opportunity data, and pastes it into Dynamics 365. Available with most Power Automate paid plans.
- **Unattended RPA** — the bot runs autonomously on a dedicated machine or VM, without a user logged in. Triggered by Power Automate cloud flows on a schedule or event. The right pattern for batch processes: a nightly job logs in to a legacy ERP, extracts a report, and uploads it to Dynamics 365. Requires a Power Automate **unattended RPA add-on** licence per bot, plus dedicated infrastructure.
## Machine groups
For unattended scenarios at scale, **machine groups** pool multiple machines so flows can scale horizontally. Cloud flows queue work, and any available machine in the group picks it up. Microsoft also offers a managed **hosted machines** option where Microsoft provisions and manages the bot VMs.
## Building flows
PAD's flow designer is desktop-based — a Windows application installed on the machine where flows are authored. Actions are drag-and-drop: open browser, click element, send keys, extract text, read Excel, OCR image, call AI Builder model, branch on condition, loop. The designer captures UI elements visually — click on a button in the target app, and PAD records the selector for replay.
## UI selectors
The fragile part of any RPA. PAD selectors can be DOM (for web), UI Automation (for Win32 / WPF / UWP), image-based (last resort), or coordinates (avoid). Changes to the target application's UI break selectors. Robust RPA design uses the most stable selector available and tolerates layout drift where possible.
## AI Builder integration
PAD calls AI Builder models inline — extract text from an image, classify a document, predict a value — combining classic RPA with AI-driven processing.
**Where to use it.**
- Legacy ERP / CRM that has no usable API.
- AS/400 green-screen apps still running in some manufacturing and finance shops.
- Excel-heavy back-office processes that can't be redesigned.
- Bridge during a system migration: temporarily double-key into both old and new systems during cutover.
## Where not to use it
Any time a real API exists. RPA is brittle; integrations through APIs are stable. PAD is the *last resort*, not the first.
## Operating discipline
Build runbooks: what to do when a bot fails. Monitor bot run history daily in early life. Plan for the inevitable target-application UI change that breaks the bot. Budget for ongoing maintenance — RPA without maintenance is failed RPA.
## Licensing reality
Attended is bundled with most paid Power Automate plans; unattended requires a per-bot add-on plus infrastructure (Microsoft-hosted or self-hosted). Costs add up at scale; do the maths against the manual effort being replaced.
---
# Power Automate error handling patterns
How to handle errors robustly in Power Automate flows — try/catch scopes, configure run-after, retry policies, dead-letter handling.
Source: https://www.solvingdynamics365.com/guides/power-automate-error-handling-patterns
Section: Power Platform / Power Automate
Published: 2026-07-24
A Power Automate flow without error handling fails silently — the run shows red, but unless someone watches the run history, nobody notices. Robust flows handle errors explicitly: retry transient issues, route persistent failures to alerting, log context for debugging, and recover gracefully. The patterns aren't complex but they're not obvious to first-time makers.
**The try/catch/finally pattern.**
Power Automate's flow design doesn't have native try/catch syntax, but the equivalent is achieved through **Scope** actions plus the **Configure Run After** option:
1. Wrap the main logic in a **Scope** action — labeled "Try" by convention.
2. Add another Scope after — labeled "Catch".
3. On the Catch scope, configure **Run After** = "has failed", "is skipped", or "has timed out" of the Try scope.
4. Optionally add a third Scope labeled "Finally" — Run After = "is successful", "has failed", "is skipped", "has timed out" of both Try and Catch.
The flow structure:
```
Try (Scope) {
... main logic
}
Catch (Scope) - Run After "has failed" of Try {
... error logging, alerting, compensation
}
Finally (Scope) - Run After all of Try and Catch {
... cleanup, regardless of outcome
}
```
If anything in Try fails, the Try scope fails, Catch runs. If everything in Try succeeds, Catch is skipped, Finally still runs.
**What to do in Catch.**
- **Log the error.** Inside the Catch, retrieve the failed action's output via `actionOutputs('ActionName')` or the workflow's overall error via `result('Try')`. Write to a Dataverse log table, Application Insights, or a notification channel.
- **Notify.** Send a Teams message, email, or alert to operations. Critical failures go to a real distribution list; routine failures might just log.
- **Compensate.** If the failed action had side effects, undo them. If you created a record then a downstream step failed, delete the record.
- **Decide whether to terminate the flow.** Sometimes you log and continue (graceful degradation); sometimes you halt.
**Retry policies.**
Each action has a **retry policy** configurable via the action's settings:
- **None** — fail immediately on error.
- **Default (exponential)** — retry up to 4 times with exponential backoff. Used for transient failures.
- **Fixed** — retry on a fixed schedule.
- **Exponential (configurable)** — custom backoff.
Default retry handles transient HTTP 5xx errors, brief connector outages, throttling. Don't apply retry to non-idempotent operations — a "create record" action retrying could create duplicates.
**Configure Run After granularity.**
Beyond "has failed", Run After supports specific failure conditions:
- **is successful** — only if the previous action succeeded.
- **has failed** — only on failure.
- **is skipped** — when the previous action was skipped (e.g. by a parent failure cascade).
- **has timed out** — specifically when an action exceeded its timeout.
Combinations cover specific recovery scenarios — "retry on timeout but not on auth failure", for example.
**Try/Catch within loops.**
For Apply to Each loops:
- **Default behaviour**: a single iteration's failure aborts the loop.
- **Continue on error**: wrap the loop body in a Try/Catch scope; the Catch logs the failure but doesn't halt the loop. The loop processes remaining items.
This pattern is essential for bulk processing where one failure shouldn't block the rest.
**Dead-letter handling.**
For integrations that can't tolerate event loss, a **dead-letter pattern**:
1. Try the main logic.
2. On persistent failure (after retries exhausted), write the failed item to a "dead letter" table or queue.
3. Operations team monitors the dead-letter table; investigates and reprocesses.
This handles the genuine "we couldn't do it now, but it must be done eventually" pattern.
**Idempotency.**
Retry-friendly flows must be idempotent — running the same action twice produces the same result. Patterns:
- **Check before create** — query for the target record; create only if it doesn't exist.
- **Upsert** — use the Dataverse "Upsert" pattern (insert if not exists, update if exists).
- **Correlation IDs** — track each processing attempt; the downstream system uses the ID to detect duplicates.
Non-idempotent flows that retry create duplicate records, double-charge, or send multiple notifications.
**Monitoring and alerting.**
- **Run history** — visible in the Power Automate maker portal. Manual review.
- **Application Insights** — flows can write to App Insights via the HTTP action; centralised monitoring.
- **Failure notification flows** — a "watcher" flow that scans recent failures and sends consolidated alerts.
- **CoE Starter Kit** — surfaces flow failures across the tenant in dashboards.
**Common pitfalls.**
- **No error handling at all** — flows fail silently.
- **Catch that doesn't log enough** — alert says "flow failed" without context.
- **Retry without idempotency** — duplicates pile up.
- **Continue on error globally** — important failures are silently swallowed.
- **Try/Catch around trivial actions** — the overhead exceeds the benefit.
## Operational reality
Error handling is not optional for production flows. Build it from the start; revisit when failures surface. Failed flows that no one notices undermine confidence in the whole platform.
## Where to go next
The errors these patterns catch are decoded in [flow failures explained](https://www.solvingdynamics365.com/guides/power-automate-flow-failures-explained), and seeing them before users do is [error monitoring](https://www.solvingdynamics365.com/guides/power-automate-error-monitoring). Design-level companions: [flow design patterns](https://www.solvingdynamics365.com/guides/power-automate-flow-design-patterns), [retry policies with Azure services](https://www.solvingdynamics365.com/guides/retry-policies-with-azure-services), and [idempotency in integrations](https://www.solvingdynamics365.com/guides/idempotency-in-dynamics-365-integrations) — the property that makes a retry safe.
---
# Power Automate flow design patterns
How to design reliable, maintainable Power Automate flows — triggers, retries, error handling, child flows, and what not to do.
Source: https://www.solvingdynamics365.com/guides/power-automate-flow-design-patterns
Section: Power Platform / Power Automate
Published: 2026-05-01
Power Automate flows are easy to build and surprisingly easy to ruin. Bad flows fail silently, generate alert fatigue, exceed API limits, and leave admin teams chasing ghosts. The good news: a handful of design patterns prevent almost all of it.
**Pick the right trigger.**
- **Instant triggers** — manually invoked or button-triggered. For ad-hoc work.
- **Automated triggers** — when a Dataverse, SharePoint, or SaaS event happens. Default for most CRM automation.
- **Scheduled triggers** — on a clock. For periodic ETL, reminders, cleanup.
Don't poll on a schedule if an automated trigger exists — you'll generate noise and miss events.
## Filter at the trigger, not in the flow
Most triggers accept filters. Filtering "Account created" by the Type = 'Customer' at the trigger saves the flow from spinning up on every Account create.
## Idempotency
Flows can fire twice — connector retries, replays, manual re-runs. Design actions to be idempotent: check before inserting, use upsert semantics, store a correlation ID on the source record so retries don't double-process.
## Concurrency control
A flow with many concurrent runs racing on the same record causes locks and corruption. Set **concurrency limits** to serialise runs per record key when ordering matters.
## Error handling
Wrap critical actions in **try/catch/finally** scopes. Configure each action's **retry policy** (exponential backoff by default; sometimes None for non-idempotent calls). On error, log to a Dataverse log table and notify a Teams channel — don't email an individual.
## Child flows
Pull repeated logic into **child flows** so it's one definition called from many parents. Saves duplication and isolates failure handling.
## Variables and expressions
Keep flows readable: name variables, comment with the description field on each action, avoid 20-deep nested expressions. If an expression goes over one line, extract it into a Compose action with a descriptive name.
## Performance
Use the OData **$filter** and **$select** on Dataverse list actions — the *Filter rows* and *Select query* fields are not cosmetic, they push work to the server.
## Don't put long-running work in flows
Flows have action timeouts and run-duration limits. For work that takes more than a few minutes, hand off to **Azure Durable Functions**, **Service Bus**, or a Job Queue entry on the back-office system.
## Test in dev, deploy with solutions
Build flows inside a **managed solution** so they version, export, and import cleanly across environments. Building directly in production is the express route to drift.
## Monitor
The **Power Platform admin centre** shows flow run history, success rate, and quota usage. Check it weekly until your flows are boring.
## Where to go next
The companion guides are [error handling patterns](https://www.solvingdynamics365.com/guides/power-automate-error-handling-patterns), [child flows](https://www.solvingdynamics365.com/guides/power-automate-child-flows), and [connectors for Dynamics 365](https://www.solvingdynamics365.com/guides/power-automate-connectors-for-dynamics-365). When a flow fails anyway, [flow failures explained](https://www.solvingdynamics365.com/guides/power-automate-flow-failures-explained) decodes the message. And before a high-volume flow is built, [plug-ins vs Power Automate](https://www.solvingdynamics365.com/guides/integrating-with-dataverse-plug-ins-vs-power-automate) is the decision to make.
---
# Power Automate flow failures explained
The Power Automate errors that stop flows — ActionFailed, BadGateway, InvalidTemplate, 429 throttling, 'Could not find a property named', null Apply to each, expired connections, DLP suspension, silent triggers — with fixes.
Source: https://www.solvingdynamics365.com/guides/power-automate-flow-failures-explained
Section: Power Platform / Troubleshooting
Published: 2026-09-03
Flow failures fall into four families: the flow ran and an action failed; the flow ran and an expression could not be evaluated; the flow was throttled, suspended, or lost its connection; or the flow never ran at all. The run history tells you which, if you know where to look. This reference covers the recurring errors in each family with the fix. Design-level patterns for making flows fail safely are in [Power Automate error handling patterns](https://www.solvingdynamics365.com/guides/power-automate-error-handling-patterns); detecting failures before users do is in [error monitoring](https://www.solvingdynamics365.com/guides/power-automate-error-monitoring).
## Reading a failed run
Open the run, expand every scope and loop until you reach the action with the red icon, and read its Outputs pane: the status code, the error body, and — for connectors — the request the connector actually sent. The message at the top of the run is a summary of a summary; the action's raw output is the truth.
## Actions that failed
### "ActionFailed. An action failed. No dependent actions succeeded."
**Symptom.** A scope, condition, or Apply to each shows failed with this text.
**Cause.** A child action failed and the container reports it. Also appears when every branch of a condition was skipped because the actions were configured to run only on success of something that failed.
**Fix.** Drill into the container; fix the actual failing action. Check Configure run after on actions that should run on failure.
### "BadGateway" / 502 / "The service is unavailable" / 503
**Symptom.** A connector action fails with a gateway status; a retry an hour later works.
**Cause.** The connector's backend, the on-premises data gateway, or the target service was unavailable or timed out. On the gateway, it often means the gateway machine is off, out of memory, or its service account's password expired.
**Fix.** Resubmit the run. If it recurs, check the gateway's status in the admin centre and the target service's health; add a retry policy (Settings on the action) with exponential backoff.
**Prevention.** Default retry policy on every action that talks to a network; gateway clusters rather than single machines for on-premises sources.
### "The response is not in a JSON format."
**Symptom.** An HTTP action or a custom connector fails parsing.
**Cause.** The endpoint returned HTML (a login page, an error page), an empty body, or XML. Typically an expired token, a wrong URL, or an API that returns 204 No Content.
**Fix.** Look at the raw body in Outputs. Fix the authentication or URL; for legitimate non-JSON responses, read `body()` as text or use the Parse JSON action only when there is content.
### "OpenApiOperationParameterValidationFailed" / "Input parameter 'X' is required"
**Cause.** A required field on the action is empty at runtime — a dynamic content token that resolved to nothing.
**Fix.** Trace the token back to its source action and see why it was empty; add a condition or a `coalesce()` default.
### Dataverse: "Resource not found for the segment 'X'." / "Could not find a property named 'X' on type 'Microsoft.Dynamics.CRM.account'."
**Symptom.** A List rows, Get a row, or Update a row action fails with an OData message.
**Cause.** The table name in the URL segment is wrong (it wants the plural entity set name, `accounts`, not `account`), or a column in Filter rows, Select columns, or Expand query is not the lowercase logical name. Lookups in filters need the `_value` form: `_parentcustomerid_value eq '…'`.
**Fix.** Use exact logical names from the table's Columns view; test the filter in the browser against `/api/data/v9.2/` first.
**Prevention.** [FetchXML vs OData](https://www.solvingdynamics365.com/guides/fetchxml-vs-odata-in-dataverse) covers both query languages; use FetchXML for anything with joins.
### Dataverse: "A record with the specified key values does not exist" — 0x80040217 / "Does Not Exist"
**Cause.** Get a row with a GUID that was deleted, a wrong table, or a value that is not a GUID at all (a name pasted into an id field).
**Fix.** Check the value flowing into Row ID; use an alternate key when you only have a business key.
### Dataverse: "Number of requests exceeded the limit of 6000 over time window of 300 seconds" — 0x80072322, HTTP 429
**Symptom.** Dataverse actions fail under load, often in an Apply to each.
**Cause.** Dataverse service protection limits per user: 6,000 requests per five minutes, 52 concurrent requests, and 20 minutes of combined execution time per five minutes. A flow that loops over thousands of rows calling Get and Update for each hits it.
**Fix.** Reduce calls: use Expand query instead of a Get per row, filter at the source, batch with the Dataverse unbound action or a plug-in. Add a retry policy that respects `Retry-After`. Consider [plug-ins](https://www.solvingdynamics365.com/guides/integrating-with-dataverse-plug-ins-vs-power-automate) for genuinely high-volume work.
**Prevention.** Design for the limits: [batch operations in the Dataverse Web API](https://www.solvingdynamics365.com/guides/batch-operations-in-the-dataverse-web-api) and the platform's request allocations.
### Connector: "Rate limit is exceeded. Try again in X seconds." — 429
**Cause.** The connector's own throttle (Office 365 Outlook, SharePoint, Excel Online each have per-minute caps per connection).
**Fix.** Same as above: fewer calls, retry with backoff, spread work over multiple connections or time.
## Expressions that could not be evaluated
### "InvalidTemplate. Unable to process template language expressions in action 'X' inputs at line '1' and column 'N': …"
**Symptom.** The action fails before running; the error quotes an expression.
**Cause.** The rest of the message says which: "The template language function 'int' expects its parameter to be an integer or a string" (type mismatch), "property 'body' doesn't exist" (a token referencing an action that was skipped or returned nothing), "The template language expression cannot be evaluated because property 'value' cannot be selected" (indexing into null), "The template function 'formatDateTime' expects…" (a null date).
**Fix.** Wrap risky reads in `coalesce()` or `if(empty(...))`; check the run-after configuration so the action does not run when its source was skipped; use the `?` operator for optional properties (`body('Get')?['field']`).
**Prevention.** Assume every dynamic token can be null on real data.
### "The execution of template action 'Apply_to_each' failed: the result of the evaluation of 'foreach' expression … is of type 'Null'. The result must be a valid array."
**Cause.** The array fed to Apply to each is null — the List rows returned nothing, or the token points at a property that does not exist.
**Fix.** Feed the loop `coalesce(outputs('List_rows')?['body/value'], json('[]'))`, or add a condition on `length()` before the loop.
### "ExpressionEvaluationFailed"
The same family as InvalidTemplate, raised at evaluation time. Read the detail; the fix is identical.
## Connections, licences, and policy
### "Unauthorized" / "ConnectionAuthorizationFailed" / "The connection is not authenticated"
**Symptom.** Every run of a flow fails at the first connector action; the connection shows a warning in Data > Connections.
**Cause.** The connection's token expired or was revoked — a password change, MFA policy change, the owner leaving the organisation, or a service principal secret expiring.
**Fix.** Re-authenticate the connection, or better, repoint the connection reference to a service account's connection.
**Prevention.** Solution-aware flows with [connection references](https://www.solvingdynamics365.com/guides/connection-references-and-environment-variables) owned by a service account, and secrets in Key Vault with expiry alerts.
### Flow owner left the organisation
**Symptom.** Flows fail with connection errors, or are turned off, after a leaver's account is disabled.
**Cause.** The flows and their connections belonged to a person.
**Fix.** Add a co-owner or reassign ownership through the admin centre's flow management; recreate connections under a service account.
**Prevention.** Every production flow in a solution, owned by a service account, with the team as co-owners.
### "This flow is suspended because it violates a DLP policy" / "Flow suspended"
**Cause.** A DLP policy now classifies two of the flow's connectors in different groups (Business and Non-Business), or blocks one of them. Also suspended when a premium connector is used and the owner's licence lapsed.
**Fix.** Change the connectors to comply, request a policy exception, or fix the licence. The admin centre's policy report shows which rule was hit.
**Prevention.** Check the environment's DLP policy before designing a flow with a new connector; [DLP policies in Power Platform](https://www.solvingdynamics365.com/guides/dlp-policies-in-power-platform) explains the groups.
### "Flow run timed out" / approval never returned
**Cause.** A cloud flow run cannot exceed 30 days. An approval or a Delay until that waits longer than that fails.
**Fix.** Redesign long waits: record the pending state in Dataverse and use a second flow triggered by the response, or a scheduled reminder that escalates.
## The flow that never ran
### Dataverse trigger does not fire
**Cause.** In order of likelihood: the trigger's Scope is User or Business unit and the change came from someone outside it; Select columns lists columns that did not change; Filter rows excludes the row; the flow is turned off; the trigger is on the wrong table (a lookup update on the child does not fire the parent's trigger).
**Fix.** Set Scope to Organization for integration flows; verify the column and filter settings; check the flow's state and the trigger's history in Analytics.
### Scheduled flow ran at the wrong time or not at all
**Cause.** Time zone on the recurrence is UTC by default; daylight saving shifts local times; the flow was turned off for inactivity in a trial environment.
**Fix.** Set the time zone on the Recurrence trigger explicitly; move production flows out of trial environments.
### "Trigger failed" in run history
**Cause.** The trigger's own call failed — a polling trigger on a connector that throttled or a service that was down. The run is logged as a trigger failure with no actions.
**Fix.** Usually self-healing on the next poll; recurring trigger failures mean the connection or the source needs attention.
## When it is not the flow's fault
A flow that calls Dataverse and gets a business error back — "The record already exists", a plug-in's `InvalidPluginExecutionException`, a privilege error — is reporting a Dataverse problem. The error body contains the Dataverse message and code; look them up in [Dataverse Web API errors](https://www.solvingdynamics365.com/guides/dataverse-web-api-errors-explained) and [Dataverse plug-in exceptions](https://www.solvingdynamics365.com/guides/dataverse-plugin-exceptions-explained). Likewise a Business Central connector error carries the BC API message — [Business Central API errors](https://www.solvingdynamics365.com/guides/business-central-api-errors) decodes those.
### Frequently asked questions
**What does 'ActionFailed. An action failed. No dependent actions succeeded' mean?**
Nothing by itself. It is the status of a scope, condition, or Apply to each whose child action failed. Expand the container in the run history and find the action with the red icon — its own error is the real one.
**How do I fix 'Could not find a property named X on type Microsoft.Dynamics.CRM.account'?**
The Dataverse action's filter, select, or expand uses a column name that is not the logical name — a display name, a schema name with the wrong case, or a lookup used without the _value suffix. Use the exact lowercase logical name (new_customerid), and for lookups in filters use _new_customerid_value.
**Why does my Dataverse trigger not fire?**
Almost always scope or filters: the trigger's Scope is User or Business unit while the change was made by someone outside it, Select columns names a column that did not change, or Filter rows excludes the row. Set Scope to Organization for integration flows, and test with a change that touches a listed column.
**What does a 429 'Rate limit is exceeded' error mean?**
The connector or the Dataverse service protection limit throttled the call. Dataverse's limit is 6,000 requests per user per five minutes among others, and connectors have their own per-minute caps. Reduce calls — filter at the trigger, batch, avoid polling — add a retry policy with exponential backoff, and honour Retry-After.
---
# Power Automate vs Make
Power Automate vs Make (formerly Integromat) — visual scenario building, data transformation, operations-based pricing, Dynamics 365 depth, governance, and which fits which team.
Source: https://www.solvingdynamics365.com/guides/power-automate-vs-make
Section: Power Platform / Comparisons
Published: 2026-09-03
Make is the tool people reach for when Zapier feels too simple and Power Automate feels too Microsoft. It has a devoted following among technically minded operators and agencies, a visual builder that makes data flow legible, and pricing that stays reasonable at moderate volume. Against Power Automate in a Dynamics 365 context the question is the same as with any third-party automation tool: where does the platform end and the edge begin?
## What each product is
**Make** (Integromat until 2022, owned by Celonis) is a visual integration platform. A scenario is a diagram: a trigger module, then modules connected by routes, with routers for branching, iterators to split arrays, aggregators to combine them, filters on every route, error handlers, and a general-purpose HTTP module for any API. It connects to 2,000+ apps and is priced per operations executed — every module run counts — in plans from Free through Core, Pro, and Teams to Enterprise, with scenario scheduling intervals that shorten on higher tiers. It runs in Make's cloud (EU and US regions).
**Power Automate** is Microsoft's workflow and RPA platform inside the Power Platform: cloud flows across roughly 1,000+ connectors, desktop flows for RPA, business process flows, approvals, and process mining, priced per user and per bot with rights included in Dynamics 365 and Microsoft 365 licences for in-context flows. It lives in Dataverse environments with solutions, DLP policies, and admin governance. See [what is Power Platform](https://www.solvingdynamics365.com/guides/what-is-power-platform).
## Head to head
| Area | Make | Power Automate |
| --- | --- | --- |
| Builder | Visual diagram: modules, routes, routers, iterators, aggregators | Linear designer with conditions, scopes, loops, parallel branches |
| Catalogue | 2,000+ apps plus HTTP module | ~1,000+ connectors plus custom connectors and HTTP |
| Pricing (2026) | Per operations per month by plan; free tier; Core and Pro from roughly $10–20/month | Premium $15 per user per month; Process $150 per bot; included with Dynamics 365 and Microsoft 365 for in-context flows |
| Data transformation | Excellent: iterators, aggregators, mapping, array and text functions | Capable: expressions, Select, Compose, Filter array, Apply to each |
| Triggers | Webhooks (instant), polling on a schedule (interval by plan), app triggers | Dataverse row events with filters and scope, app events, schedules, HTTP, manual |
| Microsoft depth | Connectors for Microsoft 365 and Dynamics 365 | Native Dataverse, Dynamics 365, SQL, on-premises gateway, Entra service principals |
| Approvals | Via integrations | Native Approvals in Teams and Outlook |
| RPA | None | Desktop flows, attended and unattended |
| Error handling | Error handler routes: resume, ignore, rollback, break, commit | Configure run-after, scopes, retry policies |
| Governance | Teams, roles, SSO and audit on higher tiers | DLP policies, environments, solutions, Managed Environments |
| ALM | Scenario versions, templates, blueprints (JSON export) | Solutions, pipelines, Azure DevOps and GitHub Actions |
| Who builds | Technically minded business users, agencies | Makers and developers; business users for simple flows |
| Regions | EU and US | Environment region; sovereign clouds |
## Where Make wins
**The builder.** Seeing the whole scenario as a diagram, with every module's output mapped into the next by drag and drop, makes complex integrations legible in a way Power Automate's vertical designer does not. Routers and iterators are first-class concepts rather than actions to discover.
**Transformation.** Reshaping arrays, aggregating results, and building request bodies is Make's home turf. In Power Automate the same work is possible but leans on expressions and Apply to each loops that grow unwieldy.
**Price at moderate volume without Microsoft licences.** A small operations team or agency running tens of thousands of operations a month pays little.
**The HTTP module.** Any REST API, with pagination, in a few clicks. Power Automate's HTTP action is a premium connector and a blunter instrument.
**Speed for the technically inclined.** Operators who think in data flows are productive in Make within an afternoon.
## Where Power Automate wins
**Dataverse and Dynamics 365.** Row triggers with filter attributes and scope, actions that respect the security model, service-principal connections, and no per-operation metering. Automation on Dynamics 365 data belongs in the same platform as the data — [Power Automate connectors for Dynamics 365](https://www.solvingdynamics365.com/guides/power-automate-connectors-for-dynamics-365) covers what is native.
**Cost for licensed users.** Dynamics 365 and Microsoft 365 users already have Power Automate for flows in their app's context. Make's operations metering punishes exactly the high-frequency automations that matter in an ERP or CRM.
**Approvals and the Microsoft 365 surface.** Native approvals in Teams and Outlook, adaptive cards, SharePoint, Planner, Excel — the everyday enterprise workflow.
**Governance.** DLP policies, environments, solution-based ALM through pipelines, Managed Environments, and an admin centre that sees every flow. Make's Enterprise tier adds governance; Power Automate's is the default.
**RPA and on-premises.** Desktop flows and the on-premises data gateway have no Make equivalent.
**Data residency and compliance.** Flows run in the environment's region, including sovereign clouds, under the tenant's Purview and audit — a hard requirement for regulated organisations that Make's EU/US regions may not meet.
## Where the differences do not matter
Point-to-point SaaS automations of moderate complexity. Both are reliable, both have the popular connectors, both handle errors and retries competently.
## How the decision usually gets made
**Stack.** Microsoft 365 and Dynamics 365: Power Automate owns process automation, and Make — if present — handles specific edge integrations under governance. No Microsoft commitment: Make is a strong general-purpose choice.
**Nature of the work.** Heavy data reshaping across third-party APIs: Make is more pleasant. Business processes on Dynamics 365 records with approvals and security: Power Automate.
**Volume.** Very high volume in either tool becomes expensive or throttled; the answer at that point is a plug-in, Logic Apps, or Azure Functions — see [Logic Apps Standard vs Consumption](https://www.solvingdynamics365.com/guides/logic-apps-standard-vs-consumption).
**Compliance.** Regulated data and residency requirements: Power Automate in the tenant's environment.
## Using both
Where Make is already in use — often via a marketing agency — the pattern that works is an inventory of scenarios with owners, a DLP-aware list of what data they touch, a service account rather than a person's credentials, and a policy that anything touching Dataverse rows migrates to Power Automate. [Integrating Dynamics 365 with Zapier and Make](https://www.solvingdynamics365.com/guides/integrating-dynamics-365-with-zapier-and-make) covers the mechanics and the governance.
## The short version
Make for technically minded teams doing data-heavy integrations across third-party APIs, especially without Microsoft licences. Power Automate for anything on Dynamics 365 or Dataverse, for approvals and Teams, for RPA and on-premises, for governance and residency — which in a Microsoft shop is nearly everything. Zapier, the third tool in this space, is compared in [Power Automate vs Zapier](https://www.solvingdynamics365.com/guides/power-automate-vs-zapier).
### Frequently asked questions
**What is Make?**
Make, formerly Integromat, is a visual automation platform where scenarios are built as diagrams of modules connected by routes — with routers, iterators, aggregators, and a strong HTTP module — priced by operations executed per month. It is popular with technically minded business users and agencies for its transformation power and its price at moderate volume.
**Is Make cheaper than Power Automate?**
For a small team without Microsoft licences, usually: Make's Core and Pro plans are priced per operations bundle from roughly $10–20 per month as of 2026, and a moderate workload fits. For Dynamics 365 or Microsoft 365 users, Power Automate is already included for flows in their app's context, and Premium is $15 per user with no per-run metering, so at volume Power Automate wins.
**Which is better at data transformation?**
Make. Its iterators, aggregators, array and text functions, and the way every module's output is mapped visually make complex reshaping easier than Power Automate's expression language, Select and Compose actions, and Apply to each loops. Power Automate can do the same work, but with more expressions and more steps.
**Should a Dynamics 365 shop use Make?**
Only at the edges — for a long-tail SaaS tool or an agency-built marketing pipeline — and with an owner and a DLP-aware inventory. Dataverse triggers, the security model, service principals, approvals, and solution-based ALM live in Power Automate, and that is where Dynamics 365 process automation belongs.
---
# Power Automate vs Zapier
Power Automate vs Zapier — connector breadth, pricing models, Microsoft and Dynamics 365 depth, governance, RPA, and which automation tool belongs in which organisation.
Source: https://www.solvingdynamics365.com/guides/power-automate-vs-zapier
Section: Power Platform / Comparisons
Published: 2026-09-03
Zapier is the automation tool most business users already know; Power Automate is the one that comes with the Microsoft licences they already have. For a company running Dynamics 365 the question is rarely which is the better product in the abstract — it is which one should own business-process automation, and whether the other has a role at the edges.
## What each product is
**Zapier** is the original no-code integration service: a trigger in one app runs a sequence of actions in others, across a catalogue of 8,000+ apps. It is priced by task — each action executed — in plans from Free through Professional and Team to Enterprise, with multi-step Zaps, paths, filters, formatters, tables, interfaces, and AI features on the higher tiers. It is browser-based, fast to learn, and run mostly by the business users who build the Zaps.
**Power Automate** is Microsoft's workflow and RPA platform inside the Power Platform: cloud flows across roughly 1,000+ connectors, desktop flows for RPA, business process flows inside model-driven apps, approvals, process mining, and Copilot for building flows. It is priced per user (Premium) and per bot for unattended RPA, with usage rights included in Dynamics 365 and Microsoft 365 licences for flows within those apps' context. It runs inside Dataverse environments with solutions, DLP policies, and admin governance. See [what is Power Platform](https://www.solvingdynamics365.com/guides/what-is-power-platform).
## Head to head
| Area | Zapier | Power Automate |
| --- | --- | --- |
| Catalogue | 8,000+ apps | ~1,000+ connectors plus custom connectors and HTTP |
| Pricing (2026) | Per task by plan; free tier; Professional from roughly $20/month annual and up with task volume | Premium $15 per user per month; Process $150 per bot; included with Dynamics 365 and Microsoft 365 for in-context flows |
| Microsoft depth | Connectors for Outlook, Teams, SharePoint, Dynamics 365, Business Central | Native: Dataverse triggers with filters, Dynamics 365 actions, SQL, on-premises gateway, Entra service principals |
| Triggers | App events, schedules, webhooks | App events, Dataverse row events with filter attributes and scope, schedules, HTTP, manual and button flows |
| Logic | Paths, filters, loops on higher tiers | Conditions, switches, loops, scopes with run-after, parallel branches, child flows |
| Approvals | Via integrations | Native Approvals with Teams and Outlook actionable messages |
| RPA | None | Desktop flows, attended and unattended, machine groups |
| Governance | Team folders, roles, SSO and audit on Enterprise | DLP policies, environments, solutions, Managed Environments, admin centre |
| ALM | Versioning, folders | Solutions, pipelines, Azure DevOps and GitHub Actions |
| Error handling | Retry, autoreplay on paid plans, alerts | Configure run-after, scopes, retry policies, error-handling patterns |
| Who builds | Business users | Makers and developers; business users for simple flows |
| Data residency | Zapier's cloud | Environment region; sovereign clouds |
## Where Zapier wins
**Breadth.** If the tool is a niche SaaS product — a scheduling app, a form builder, a marketing tool — Zapier has the connector and Power Automate probably does not. For marketing and sales operations teams living in best-of-breed SaaS, this is decisive.
**Time to first automation.** A non-technical user can build a working Zap in ten minutes with no environment, solution, or connection reference in sight. Power Automate's learning curve is real, especially once flows live in solutions.
**No Microsoft prerequisite.** A company on Google Workspace, HubSpot, and Slack has no reason to buy into the Power Platform for automation.
**Simplicity of the mental model.** Trigger, actions, done. Zapier's interface hides complexity Power Automate exposes.
## Where Power Automate wins
**Dataverse and Dynamics 365.** Row triggers with filter attributes and scope, actions that respect the security model, service-principal connections, and no per-task metering. Automation on Dynamics 365 data belongs in the same platform as the data — see [Power Automate connectors for Dynamics 365](https://www.solvingdynamics365.com/guides/power-automate-connectors-for-dynamics-365).
**Cost at volume for licensed users.** Dynamics 365 and Microsoft 365 users already have Power Automate rights for flows in their app's context; Premium is a flat per-user fee. Zapier's per-task pricing punishes exactly the high-volume automations that matter.
**Approvals, Teams, and Microsoft 365.** Native approvals routed to Teams and Outlook, adaptive cards, SharePoint, Excel, Planner — the everyday enterprise workflow surface.
**Governance.** DLP policies that stop a flow moving Dataverse data to a personal Dropbox, environments that separate dev from production, solutions that move flows through a pipeline, and an admin centre that sees everything. Zapier's Enterprise tier has governance; Power Automate's is the platform's default.
**RPA and on-premises.** Desktop flows for legacy applications and the on-premises data gateway for SQL and file shares have no Zapier equivalent.
**Error handling.** Scopes, run-after, retry policies, and the patterns in [Power Automate error handling](https://www.solvingdynamics365.com/guides/power-automate-error-handling-patterns) produce automations that fail safely. Zapier's autoreplay helps but is not a design surface.
## Where the differences do not matter
Simple point-to-point automations between well-known SaaS apps — a form submission creates a record, a new file posts a message, a schedule sends a digest. Both do these in minutes and both are reliable for them.
## How the decision usually gets made
**Stack.** Microsoft 365 and Dynamics 365: Power Automate owns process automation; Zapier, if present, handles edge connectors under a DLP policy. Google Workspace and best-of-breed SaaS: Zapier, with Power Automate only if Dynamics 365 or Dataverse enters the picture.
**Who builds.** Business users with no IT involvement: Zapier is easier. Makers inside a governed platform: Power Automate.
**Volume.** Thousands of runs a day: Power Automate, or for very high volume a plug-in or Logic Apps — see [plug-ins vs Power Automate](https://www.solvingdynamics365.com/guides/integrating-with-dataverse-plug-ins-vs-power-automate) and [Logic Apps Standard vs Consumption](https://www.solvingdynamics365.com/guides/logic-apps-standard-vs-consumption).
**Governance and compliance.** Regulated data, audit, data residency: Power Automate inside a Dataverse environment.
## Using both
The realistic pattern in many Microsoft shops is Power Automate as the platform with a small, inventoried set of Zaps for tools it cannot reach — each with a named owner, a DLP-approved connector list, and a plan to replace it if a Power Automate connector appears. [Integrating Dynamics 365 with Zapier and Make](https://www.solvingdynamics365.com/guides/integrating-dynamics-365-with-zapier-and-make) covers the mechanics and the governance.
## The short version
Zapier for breadth, speed, and organisations with no Microsoft commitment. Power Automate for anything that touches Dynamics 365 or Dataverse, for approvals and Teams, for RPA and on-premises, for volume, and for governance — which in a Microsoft shop is nearly everything. The other tool in this space, Make, is covered in [Power Automate vs Make](https://www.solvingdynamics365.com/guides/power-automate-vs-make).
### Frequently asked questions
**Is Zapier or Power Automate cheaper?**
It depends on what you count. Zapier prices per task (each action run), so a busy automation gets expensive fast; Power Automate Premium is $15 per user per month (2026 list) with request limits, and Dynamics 365 and Microsoft 365 licences already include Power Automate for their own contexts. For a Microsoft shop with existing licences, Power Automate is usually free at the margin; for a small team without them, Zapier's entry plans are cheaper.
**Which has more integrations?**
Zapier — 8,000+ apps against Power Automate's roughly 1,000+ connectors. For long-tail SaaS tools Zapier almost always has the connector. For Microsoft services, Dataverse, Dynamics 365, SQL, and on-premises systems through the gateway, Power Automate is deeper.
**Can Zapier connect to Dynamics 365?**
Yes, through its Dynamics 365 CRM and Business Central integrations, and it works for simple create-and-update scenarios. It does not have Dataverse triggers with filter attributes, cannot run inside the Dataverse security model as a service principal the way a flow can, and every task costs money — so it is a tactical bridge, not the platform for Dynamics 365 automation.
**Should a Microsoft shop ever use Zapier?**
Occasionally, for a marketing or sales tool Power Automate has no connector for, with a DLP policy and an owner attached. The failure mode is dozens of unmanaged Zaps holding business processes together outside any governance — the guide on integrating Zapier and Make with Dynamics 365 covers how to keep that contained.
---
# Power BI dataflows vs datamarts
Power BI dataflows, datamarts, semantic models, and Fabric items — when to use each, how they relate.
Source: https://www.solvingdynamics365.com/guides/power-bi-dataflows-vs-datamarts
Section: Power Platform / Power BI
Published: 2026-05-01
Power BI has grown from a desktop reporting tool into a layered data platform. The layering — dataflows, datamarts, semantic models, paginated reports — is confusing without a map. With Microsoft Fabric's emergence, the layers shift further, with some legacy concepts deprecated in favour of Fabric items. This article maps the terrain.
**The traditional Power BI stack.**
- **Dataset (now semantic model)** — the analytical model: tables, relationships, measures (DAX). Backed by Vertipaq in-memory columnstore. Consumers connect to it from reports and Excel.
- **Dataflow** — ETL artefact built in Power Query Online. Outputs to a CDM-folder-structured storage in OneLake (Fabric) or a workspace (legacy).
- **Datamart (legacy)** — a self-contained dataflow + Azure SQL DB + semantic model. Designed for self-serve "I want a small star schema with SQL access" scenarios.
- **Paginated report** — pixel-perfect operational reports; SSRS heritage.
- **Power BI report** — interactive dashboards built in Power BI Desktop.
**Fabric introduces.**
- **Lakehouse** — files-based store on OneLake; Delta tables; Spark and SQL access.
- **Data warehouse (Fabric)** — full T-SQL warehouse on OneLake.
- **Eventstream** — real-time ingestion.
- **Pipelines** — orchestration.
- **KQL database** — telemetry/logs.
- **Notebook** — Spark code.
- **Direct Lake mode** — semantic model reads Lakehouse Delta tables directly, no import.
## Dataflows
The Power Query ETL workspace asset. Reads from sources (SQL, OneDrive, REST APIs), applies transformations, writes to CDM-folder output. Multiple semantic models can reference the same dataflow — central place to do "join customer master once" without each model duplicating logic.
## Datamarts
Introduced 2022; provided self-serve a "SQL endpoint plus model in one click" experience. With Fabric, datamarts are effectively superseded by Lakehouses (for files) and Fabric warehouses (for SQL). Microsoft has signalled datamarts won't see significant new investment; existing datamarts continue working.
## Semantic models
The analytic engine. Two import modes:
- **Import** — data copied into the in-memory model; updates via scheduled or incremental refresh.
- **DirectQuery** — queries pushed to the source at report time; no copy in the model.
- **Direct Lake (Fabric)** — reads Lakehouse Delta tables directly without import or query at run time.
Direct Lake is the new default for Fabric-resident data: in-memory performance without import overhead.
**When to use a dataflow vs other ETL.**
- **Quick self-serve transformations** for non-engineering users → dataflow.
- **Enterprise-grade ETL with version control and testing** → pipelines + notebooks in Fabric, or Azure Data Factory.
- **Real-time ingestion** → Eventstream into a Lakehouse.
Dataflows remain a strong middle ground for citizen data engineers.
**Centralised vs decentralised modelling.**
- **Centralised semantic models** — IT/BI team owns; business consumers connect. Quality controlled; less duplication.
- **Decentralised personal models** — every analyst builds their own from raw data. Fast for that analyst, chaotic across organisation.
Modern Power BI practice favours **certified semantic models** at the centre with self-serve report building on top.
## Connectivity from Excel and Power BI
Semantic models are consumable from:
- **Power BI reports** in the same workspace or other workspaces.
- **Excel** — `Connect to Power BI dataset`.
- **External tools** through XMLA endpoint.
- **Custom apps** via the Power BI REST API.
This makes the certified semantic model the "single version of truth" surface.
**Capacity considerations.**
- **Premium per user (PPU)** — for the user, models up to capacity limits.
- **Premium capacity (P SKU)** — for the workspace, defined throughput.
- **Fabric capacity (F SKU)** — Fabric's unified compute/storage capacity.
Fabric capacity is the future; new investments should land there.
**Refresh patterns.**
- **Scheduled refresh** — N times per day; standard for batch reporting.
- **Incremental refresh** — only updated data refreshes; saves time and storage.
- **Hybrid table** — recent data DirectQuery, older data imported.
- **Direct Lake** — no refresh; reads live from Lakehouse.
**Common pitfalls.**
- **Dataflow proliferation.** Every report builds its own dataflow; duplication explodes.
- **Mixed modes in one model.** Some tables import, some DirectQuery; performance unpredictable.
- **Semantic model dependencies broken.** Underlying data source schema changes; model fails. Build version checks into pipelines.
- **Datamart investment.** Building new datamarts in 2026 — likely wasted effort given Fabric direction.
- **Capacity contention.** Multiple heavy workspaces on shared capacity; reports slow.
## Strategic direction
Microsoft Fabric is the unifying story: OneLake holds the data, Lakehouses and warehouses serve it, semantic models analyse it, Power BI surfaces it. New investments should think Fabric-first: Lakehouse for raw and curated data, Fabric pipelines for ETL, semantic models in Direct Lake mode for analytics, Power BI reports on top. Legacy Power BI artefacts continue working but the centre of gravity has shifted.
### Frequently asked questions
**What is a Power BI dataflow?**
A Power Query Online ETL artefact that reads from sources, applies transformations, and writes CDM-folder output that multiple semantic models can reuse — the place to join customer master data once rather than in every model.
**Are Power BI datamarts deprecated?**
Effectively superseded. Datamarts, introduced in 2022, are replaced in Microsoft Fabric by lakehouses for files and Fabric warehouses for SQL. Existing datamarts keep working, but Microsoft has signalled no significant new investment, so building new ones in 2026 is likely wasted effort.
**What is Direct Lake mode?**
A semantic model mode in Fabric that reads lakehouse Delta tables directly, giving in-memory performance without import refresh or DirectQuery round-trips. It is the default for Fabric-resident data.
**Should I use dataflows or Fabric pipelines for ETL?**
Dataflows for quick self-serve transformations by citizen data engineers; Fabric pipelines and notebooks (or Azure Data Factory) for enterprise-grade ETL with version control and testing; Eventstream for real-time ingestion.
---
# Power BI deployment pipelines
How Power BI deployment pipelines automate Dev/Test/Prod promotion of reports, semantic models, and dataflows — configuration, rules, and the ALM patterns.
Source: https://www.solvingdynamics365.com/guides/power-bi-deployment-pipelines
Section: Power Platform / Power BI
Published: 2026-05-01
Promoting Power BI artefacts from development to production should not be a manual download-upload-reconfigure exercise. **Deployment pipelines** in Power BI Premium and Fabric provide a structured Dev → Test → Prod promotion path with deployment rules, validation, and history. For organisations with serious Power BI investments, pipelines are the canonical ALM mechanism.
**The pipeline structure.**
- **Dev stage** — connected to a dev workspace.
- **Test stage** — connected to a test workspace.
- **Production stage** — connected to a production workspace.
- **Items in scope** — reports, semantic models, dataflows, paginated reports.
Each stage corresponds to a Power BI workspace; deployment moves items between workspaces with appropriate transformations.
**Setting up.**
1. Create a deployment pipeline in Power BI Service.
2. Assign workspaces to stages.
3. (Optional) Connect Dev workspace from VS Code / Power BI Desktop for editing.
4. Deploy artefacts from Dev to Test, Test to Prod.
The pipeline is a record; workspaces hold actual artefacts.
**Deployment rules.**
- **Data source rules** — switch connection string per stage.
- **Parameter rules** — change parameter values per stage.
- **Refresh schedule** — different per stage.
For example: Dev pipeline connects to dev SQL; Test to test SQL; Prod to prod SQL. Rules automate the switch.
## Compare and deploy
Before deploying:
- See what's different between stages.
- Per-item: New, Different, Unchanged.
- Review changes; confirm intent.
- Deploy selected items.
This is the safety net — see what'll change before clicking.
## Selective deployment
Don't have to deploy everything:
- Pick specific items.
- Useful for hotfix scenarios.
- Useful when multiple items are in flux but only some are ready.
## Cross-stage deployment
Standard flow: Dev → Test → Prod sequentially. Sometimes:
- Hotfix straight to Prod skipping Test (with care).
- Rollback by deploying older Test version back to Prod.
Pipeline handles both directions; discipline applies.
**Permissions.**
- Pipeline admin can deploy.
- Individual workspace permissions still apply.
- Granular: someone can be Dev admin but Test reviewer.
For governance, role separation across stages matters.
**Workspace setup.**
- Workspaces typically have descriptive names: `Sales-Dev`, `Sales-Test`, `Sales-Prod`.
- Items moved by pipeline; manual changes in Prod risk drift.
- For "no manual production changes" policy, lock down Prod workspace access.
## Deployment history
Each pipeline records:
- Deployments made.
- Who deployed.
- When.
- What changed.
This is the audit trail.
## Integration with Git
Power BI integrates with Git (Azure Repos, GitHub):
- Workspaces backed by Git repository.
- Changes versioned in commits.
- Branch-based development.
- Merge to deploy.
For mature ALM, Git integration + pipelines is the combination. Adoption varies; the integration is improving.
## API-based pipelines
Power BI REST API supports pipeline operations:
- List pipelines.
- Trigger deployments.
- Get deployment history.
Used by CI/CD tools (Azure DevOps, GitHub Actions) for automation beyond what the UI provides.
**Comparison with manual export/import.**
| Aspect | Pipeline | Manual |
|---|---|---|
| Speed | Fast | Slow |
| Error rate | Low | High |
| Audit trail | Native | Manual |
| Rules | Automated | Manual |
| Cost | Premium feature | Free |
For organisations on Premium / PPU, pipelines are clearly preferred.
## Premium vs Fabric
Both support deployment pipelines:
- **Power BI Premium** — original; well-tested.
- **Fabric** — newer; integrated with broader Fabric workspace concept.
Functionally similar; Fabric is the strategic direction.
**Common pitfalls.**
- **No pipeline.** Manual promotion; drift inevitable.
- **Deployment rules incomplete.** Production points at test data source.
- **Manual changes in Prod.** Workspace divergence; future deploys conflict.
- **No environment isolation.** Dev workspace points at prod data; unintentional impact.
- **Refresh credentials mismatched** — pipeline deploys but refresh fails in target.
- **No deployment review.** Deploy without checking what changed.
**Best practices.**
- **Strict workspace separation** by stage.
- **Deployment rules for every source** — no environment-specific URLs in code.
- **Compare before deploy.**
- **Document deployment in change ticket.**
- **Test in Test stage** — actually test before promoting.
- **Monitoring post-deployment** — verify refreshes succeed in Prod.
## Hotfix patterns
Production issue:
1. Identify the problem.
2. Fix in Dev or directly in a hotfix workspace.
3. Test minimally.
4. Deploy through pipeline (Dev → Test → Prod, or skip).
5. Document the hotfix and root cause.
6. Plan permanent fix into next regular cycle.
## Power Apps Pipelines comparison
Similar concept across Power Platform:
- **Power BI deployment pipelines** — for BI artefacts.
- **Power Platform pipelines** — for Power Apps / flows.
Each pipeline tool specific to its surface; both follow similar Dev → Test → Prod patterns.
## Strategic positioning
Deployment pipelines are how serious Power BI deployments handle change. The pipeline provides the discipline; the operational rhythm (regular deploys, post-deploy validation, incident retros) provides the value. For Premium / PPU customers, treating pipelines as default infrastructure rather than optional convenience is the right approach. The cost in setup is small; the benefit in reliability and traceability is significant.
---
# Power BI for Dynamics 365
How Power BI integrates with Dynamics 365 — pre-built apps, Dataverse and F&O connectors, Microsoft Fabric, and where the data actually lives.
Source: https://www.solvingdynamics365.com/guides/power-bi-for-dynamics-365
Section: Power Platform / Power BI
Published: 2026-05-01
Power BI is the default analytics layer for any Dynamics 365 customer. Microsoft ships pre-built Power BI apps for every major Dynamics 365 product, and customers extend or replace them with their own. The biggest design choice is where the data sits — and there are now three serious answers.
## Pre-built Power BI apps
From the Power BI app marketplace, install **Microsoft's published apps** for Sales, Customer Service, Finance, Business Central, Supply Chain, Field Service, and Project Operations. Each app contains a curated dataset, dashboards, and reports tuned to the source product. Out of the box, these answer 80% of the typical analytical questions and are the right starting point even if you eventually replace them.
## Direct connectors
Power BI has first-class connectors to:
- **Dataverse** — direct query against the Dataverse SQL endpoint or import via the Dataverse connector. The right pattern for CRM-side reporting where data volumes are modest and you want live numbers.
- **Business Central** — REST API and OData connectors. Fast for moderate volumes; for years of history, prefer the data lake export.
- **F&O entity store / data lake** — historical fact-table extracts for large reporting needs.
## Microsoft Fabric and OneLake
The strategic direction. **Synapse Link for Dataverse** streams Dataverse changes into OneLake near-real-time; **Synapse Link for F&O** does the same for Finance/SCM. The result is a Fabric lakehouse containing both CRM and ERP data, queryable with Power BI's **DirectLake** mode for fast performance without import refreshes. For mid-to-large customers, this is becoming the default analytics architecture.
## Embedding
Power BI reports embed inside Dynamics 365 model-driven apps as **system charts** or as embedded reports in dashboards. Embedded reports respect row-level security configured in Power BI.
## Row-level security
Power BI supports **row-level security (RLS)** that scopes data per user — typically by mapping a Dataverse business unit or territory to an RLS role. Configure it in Power BI Desktop, deploy to the service, and reports show each user only their data.
## Performance
Import models are fastest for end users but require scheduled refresh. DirectQuery is live but slower and load-sensitive. DirectLake bridges the two, querying OneLake parquet without import. Pick deliberately per dataset.
## Costs
Power BI Pro per user, Premium per user, or Premium capacity. Pre-built apps require at least Pro for end users; large embedded scenarios usually justify a Premium capacity.
## Operational reality
Don't build a custom Power BI model the day before go-live. Start with Microsoft's app, evolve from real user questions, and migrate to Fabric when scale demands it.
## Where to go next
The analytics layer underneath is [Microsoft Fabric and Dynamics 365](https://www.solvingdynamics365.com/guides/microsoft-fabric-and-dynamics-365) and [Synapse Link for Dataverse](https://www.solvingdynamics365.com/guides/azure-synapse-link-for-dataverse). On the Power BI side: [row-level security](https://www.solvingdynamics365.com/guides/power-bi-row-level-security-deep-dive), [dataflows vs datamarts](https://www.solvingdynamics365.com/guides/power-bi-dataflows-vs-datamarts), and [deployment pipelines](https://www.solvingdynamics365.com/guides/power-bi-deployment-pipelines) for moving reports between workspaces.
---
# Power BI gateway for on-prem data
How the on-premises data gateway bridges Power BI to on-prem data sources — installation, configuration, security.
Source: https://www.solvingdynamics365.com/guides/power-bi-gateway-for-on-prem-data
Section: Power Platform / Power BI
Published: 2026-07-26
Power BI lives in the Microsoft cloud; many Dynamics 365 customers still have on-premise data sources — old SQL Server databases, legacy ERPs, file shares, internal services — that must be combined with cloud data for analytics. The **on-premises data gateway** is the bridge — a small Windows service running inside the customer's network that securely brings cloud Power BI queries to on-prem data.
**The architecture.**
The gateway sits in the customer's network as a Windows service:
- **Outbound-only connection** to Microsoft's Azure Service Bus relay. The gateway doesn't accept inbound from the internet; it polls Microsoft.
- When Power BI cloud needs to query an on-prem source, it sends the query through Azure Service Bus.
- The gateway picks up the query, runs it against the configured on-prem source, and returns results back through Service Bus to Power BI.
- The result lands in Power BI's data model; the user sees their report.
This pattern works without VPN setup, without opening firewall ports, without exposing on-prem data to the internet.
**Two gateway types.**
- **Standard mode** — for use by multiple users / Power BI reports. Production scenario. Multiple users share the gateway; admin centrally manages.
- **Personal mode** — for an individual maker's exploration; the gateway runs on the maker's PC. Less robust but quick for prototyping.
Production deployments use standard mode.
**Installation.**
1. Download the on-premises data gateway installer from Microsoft.
2. Install on a Windows server inside the network — typically a dedicated server, not a shared one.
3. Sign in with a Microsoft 365 / Entra ID account that has appropriate Power BI admin rights.
4. Register the gateway with a name and recovery key.
5. Configure data source connections — add each on-prem source the gateway will serve, with credentials.
**Data source configuration.**
For each on-prem data source the gateway should serve:
- **Type** — SQL Server, file share, OData feed, custom connector.
- **Server / database / path** — connection details.
- **Credentials** — typically a service account dedicated to gateway use, with read-only access to the source.
- **Privacy levels** — for combining data sources, declare each source's sensitivity to prevent cross-contamination in queries.
## High availability
Single-gateway deployments are a single point of failure. Production:
- **Gateway cluster** — multiple gateway machines registered to the same logical cluster. Power BI load-balances across them.
- **Failover** — if one gateway fails, queries route to others.
- **Maintenance windows** — rolling restarts during low-usage hours.
For mission-critical analytics, gateway clusters are essential.
## Refresh
Power BI datasets refresh from on-prem sources via the gateway:
- **Scheduled refresh** — Power BI cloud kicks off refresh on a schedule.
- **On-demand refresh** — user triggers refresh; same path through the gateway.
- **Refresh rate limits** — Pro datasets refresh up to 8 times per day; Premium up to 48 times per day.
- **Real-time queries (DirectQuery)** — every report interaction queries through the gateway; minimal latency required.
**Performance.**
- **Latency** — every query has gateway round-trip overhead; 100-500ms typical.
- **Bandwidth** — large result sets transit through Service Bus; can saturate the gateway's link to Azure.
- **Concurrent queries** — gateway has limits per CPU / memory; oversized concurrent load needs cluster expansion.
**Security.**
- **Outbound-only** — no inbound exposure.
- **Service Bus relay** — encrypted via TLS.
- **Authentication** — Power BI authentication and gateway-resident credentials are separate; query authorisation respects Power BI; data-source connectivity uses gateway-configured credentials.
- **Audit** — gateway logs every query; configurable retention.
**Use cases for Dynamics 365 customers.**
- **Combining cloud BC / D365 with on-prem ERP data** — for customers transitioning or running parallel systems.
- **Joining D365 data with on-prem SQL Server** — internal data marts, legacy applications.
- **File-share document references** — pulling document metadata from on-prem SharePoint or file servers.
- **Custom internal APIs** — accessing custom services that aren't internet-exposed.
**Maintenance.**
- **Gateway version updates** — Microsoft releases updates monthly. Stay current.
- **Credentials rotation** — periodically rotate data source credentials.
- **Resource monitoring** — gateway CPU, memory, disk I/O. Plan for growth.
- **Connection refresh** — connections occasionally need re-authentication.
**Limits.**
- **Gateway file size** — large datasets (gigabytes) through gateway are slow. Consider replicating to Azure SQL or Synapse for analytics.
- **Some connectors aren't supported** through gateway — primarily cloud-native ones don't need it.
- **DirectQuery performance** — gateway adds latency per query; not always suitable for high-interaction reports.
**Common pitfalls.**
- **Single gateway as production** — outage takes down all reports. Cluster.
- **Gateway server under-resourced** — slow queries, timeouts. Right-size CPU and memory.
- **Stale credentials** — gateway data sources fail mysteriously; rotate and refresh.
- **Insecure credentials** — gateway service account with admin rights to source. Use read-only.
## Operational reality
For Dynamics 365 customers with on-prem data, the gateway is essential infrastructure. Plan for it, maintain it, monitor it like any other production service. Cloud-first analytics with cloud-first data sources doesn't need it; mixed environments do.
---
# Power BI incremental refresh
How Power BI incremental refresh works — partitioning by date, range parameters, the refresh policy, and the patterns for large datasets.
Source: https://www.solvingdynamics365.com/guides/power-bi-incremental-refresh
Section: Power Platform / Power BI
Published: 2026-05-01
A semantic model with 10 years of transactional data shouldn't refresh all 10 years every day. **Incremental refresh** in Power BI partitions data by time, refreshes only recent partitions, and leaves historical partitions untouched. For any model with > 1M rows or significant data refresh latency, incremental refresh is essential.
## The concept
Data is partitioned by a date column:
- **Historical partitions** — older data; refreshed rarely or not at all.
- **Incremental partitions** — recent data; refreshed every cycle.
- **Active partition** — current period; may be refreshed.
The model query has filter parameters that determine the date range; refresh dynamically computes which partition to refresh.
## Setup
In Power BI Desktop:
1. Add two parameters: `RangeStart` (datetime) and `RangeEnd` (datetime).
2. Apply filter in Power Query: `Source[Date] >= RangeStart and Source[Date] < RangeEnd`.
3. Right-click the table → Incremental refresh.
4. Configure refresh policy:
- **Archive data starting** — how far back to store. E.g., "5 years".
- **Incrementally refresh data starting** — refresh window. E.g., "10 days".
5. Save and publish.
On first publish, Power BI partitions the data; subsequent refreshes only update the recent partition.
**The refresh policy.**
- **Archive period** — how far back history is kept (5 years).
- **Refresh period** — how recent the refresh window (10 days).
- **Detect data changes** — optional column tracking modifications; refresh only modified records.
The window between archive and refresh is "cold" — stored but not refreshed.
## Detect data changes
Smarter incremental:
- Specify a "last modified" column.
- Refresh only checks rows modified since last refresh.
- Most efficient for slowly-changing dimensions.
## Real-time data
Combine incremental with DirectQuery:
- Recent partition in DirectQuery for real-time.
- Older partitions in Import.
- **Hybrid Tables** feature in Power BI Premium.
Hybrid combines the best of both: real-time recency, performant import for history.
**Performance benefits.**
- **Refresh time** — minutes instead of hours.
- **Memory** — partitions loaded on demand.
- **Storage** — efficient compression per partition.
For a 100M-row table, incremental refresh can cut refresh time by 95%+.
**Partition strategy.**
- **Yearly** — for slowly changing data, longer history.
- **Monthly** — most common; balances granularity and refresh cost.
- **Daily** — for very recent / fast-changing data.
The refresh policy determines partition granularity.
**Limitations.**
- **DirectQuery and Live Connection** — partial support; DirectQuery to many sources fully supports.
- **Service-side scheduled refresh** — must be enabled.
- **Source must support range filter** — pushdown to source for efficiency.
## Source pushdown
Critical for performance:
- Power BI sends the range filter to source.
- Source returns only matching rows.
- Source-side filter avoids transferring full data.
Without pushdown, even incremental refresh reads everything.
## Premium / Premium Per User
Incremental refresh requires:
- **Power BI Pro** for basic incremental (limited).
- **Premium / PPU** for full feature including detect data changes and hybrid tables.
For meaningful data sizes, Premium is the practical choice.
## Initial load
First refresh is expensive:
- Reads full history per archive period.
- Can take hours.
- Often broken into manual partitions to manage.
Plan the initial load carefully; may need to schedule it manually first.
## Partition troubleshooting
Tabular Editor and SQL Server Management Studio can connect to the Premium dataset and show partitions:
- Per-partition row count.
- Refresh timestamp.
- Memory footprint.
Visibility helps when refresh seems wrong.
**Common pitfalls.**
- **No source pushdown.** Each refresh reads all source data; defeats incremental.
- **Filter not on date column.** Filter on derived date; pushdown fails.
- **Detect data changes column wrong.** Misses updated rows.
- **Archive period too long.** Wastes storage on unused history.
- **Initial load timeout.** First refresh exceeds limits; partitions incomplete.
- **Cross-table dependencies.** Two tables with different partition strategies; joins inefficient.
**Best practices.**
- **One date column per fact table** — incremental aligns.
- **Pushdown verified** — check query trace.
- **Archive period justified.** Don't archive 10 years if 3 suffice.
- **Refresh window short.** 5–10 days typical; longer if source data changes far back.
- **Monitoring** — refresh duration trends.
**Schema changes.**
- Adding a column requires full refresh.
- Changing data types may invalidate partitions.
- Major changes: deploy then full refresh; subsequent refreshes incremental again.
**Operational rhythm.**
- **Daily / hourly** — scheduled refresh.
- **Monthly** — refresh metrics review.
- **Quarterly** — full refresh to reset partitions if drift.
## Strategic positioning
Incremental refresh is essential for any Power BI semantic model with material data volume. The setup investment is moderate (defining parameters, configuring policy); the operational benefit is substantial (faster refreshes, predictable resource usage, scalable to billions of rows). For new models with growing data, design with incremental from the start; retrofitting later is harder. The pattern is mature; the discipline of using it is what separates production-grade models from prototypes.
---
# Power BI paginated reports
How paginated reports differ from interactive Power BI reports — SSRS lineage, design tool, when pixel-perfect matters.
Source: https://www.solvingdynamics365.com/guides/power-bi-paginated-reports
Section: Power Platform / Power BI
Published: 2026-05-01
Power BI's headline experience is **interactive reports** — dashboards built in Power BI Desktop, browsed in the service. But every Power BI deployment of any size eventually needs the *other* report type: **paginated reports** — pixel-perfect, page-oriented documents born from SQL Server Reporting Services (SSRS).
## Why the distinction
Interactive Power BI reports excel at exploration: filters, drillthrough, slicers, charts. They don't excel at print: a 47-page month-end pack with vendor statements, regulatory submissions, customer invoices. For these, paginated reports are the right tool.
**Paginated reports in short.**
- Lineage: SSRS RDL format.
- Designed in **Power BI Report Builder** (free download).
- Hosted in the Power BI service or Power BI Report Server.
- Output formats: PDF, Excel, Word, CSV, image.
- Page-based — explicit page breaks, headers, footers.
- Data-bound at runtime via parameters.
**Use cases for paginated.**
- **Regulatory submissions** — government forms with exact layouts.
- **Customer-facing invoices and statements** — branded, printable.
- **Operational reports** — picking lists, packing slips, daily sales by store, formatted for printer.
- **Long tabular exports** — sub-ledger details, audit packs.
- **Email blasts** — generate a PDF per customer with personalised content.
## Designing a paginated report
Open Report Builder:
1. **Data source** — connect to a Power BI semantic model, SQL Server, Azure SQL, Dataverse, or OData.
2. **Dataset** — query the data source.
3. **Layout** — drag controls onto pages: tables, matrices, charts, text boxes, images.
4. **Parameters** — define inputs the user provides (date range, customer ID).
5. **Formatting** — fonts, colours, page size, headers, footers.
6. **Preview** — runtime test.
7. **Publish** to Power BI service.
The design experience is more traditional than Power BI Desktop — closer to Crystal Reports or SSRS than to modern interactive design tools.
## Data sources
Paginated reports can query:
- Power BI semantic models (modern recommended path).
- Azure Synapse, Azure SQL, on-prem SQL via gateway.
- Dataverse.
- OData feeds.
- Many others through extensions.
A modern pattern is centralising in a Power BI semantic model and having paginated reports query the same model — single source of truth across interactive and paginated.
**Hosting.**
- **Power BI service** — the cloud, requires Premium or PPU.
- **Power BI Report Server (PBIRS)** — on-prem alternative, useful for sovereignty requirements. Slower release cadence; tend to lag service features.
**Triggering reports.**
- **Manual** — user opens the report and provides parameters.
- **Subscription** — email schedule sends PDF to recipients.
- **Power Automate** — flow generates the report with parameters and routes the output (email, attach to a record, save to SharePoint).
- **API** — programmatic generation.
The Power Automate integration is the workhorse for operational delivery — "every Monday email each sales rep a paginated PDF of their week ahead."
**Comparison to interactive Power BI.**
| Aspect | Interactive | Paginated |
|---|---|---|
| Purpose | Exploration | Print/export |
| Layout | Flexible canvas | Pixel-precise |
| Output | Browser experience | PDF/Excel/etc |
| Author | Power BI Desktop | Report Builder |
| Data | Semantic models | Many sources |
| Parameters | Slicers (in-report) | Run-time inputs |
| Hosting | Service / PBIRS | Service / PBIRS |
**Where paginated is still essential.**
- Anything that needs to be **printed or emailed as a static document** with fixed layout.
- **Regulatory-format submissions** with strict pagination.
- **High-volume per-record generation** (10,000 customer statements at month end).
**Modern alternatives.**
- **Power BI mobile** — interactive but mobile-friendly.
- **Export to PDF from interactive** — works for simple cases, awkward for complex.
- **Generate documents from Power Automate** — Word templates, dynamic PDF generation; for documents with limited data and high formatting needs, sometimes simpler than paginated.
**Common pitfalls.**
- **Migrating SSRS reports as-is.** They work but look dated; consider redesign in Report Builder.
- **Overcomplicated queries inline.** Heavy SQL embedded in datasets; performance hit. Push to views or semantic models.
- **No subscription discipline.** Reports emailed forever to people who left; subscription audit is a recurring hygiene task.
- **Wrong tool choice.** Building an exploration scenario as paginated, or a printable scenario as interactive — both lead to friction.
- **Forgotten data refresh dependencies.** Paginated against an out-of-date semantic model emails wrong numbers.
## Operational guidance
A mature Power BI deployment uses both: interactive for analytical consumption, paginated for operational document delivery. Treat them as complementary, not competing. The teams that try to force one to do the other's job end up with frustrating experiences and unhappy users.
---
# Power BI row-level security — a deep dive
How row-level security (RLS) works in Power BI semantic models — DAX roles, dynamic security, object-level security.
Source: https://www.solvingdynamics365.com/guides/power-bi-row-level-security-deep-dive
Section: Power Platform / Power BI
Published: 2026-05-01
A Power BI report that shows everyone's data to everyone is rarely the right answer. Sales managers see their team; account executives see their accounts; HR sees their region. **Row-level security (RLS)** in Power BI semantic models filters data per user, so the same report shows different rows to different people. Designed well, it's transparent and reliable; designed poorly, it leaks data or breaks queries.
**The two patterns.**
- **Static RLS** — roles with hardcoded filter values. "Region = US" for the US Sales role.
- **Dynamic RLS** — roles that filter based on the current user's properties. "AccountManager.Email = USERNAME()" returns only the current user's accounts.
Dynamic is far more flexible; one role serves many users.
## Defining a role
In Power BI Desktop:
1. Modeling tab → Manage Roles.
2. Add Role; give it a name.
3. Add DAX expression as a filter on relevant tables.
Example role "Region Manager":
```dax
Sales[Region] = LOOKUPVALUE(RegionMapping[Region], RegionMapping[UserEmail], USERNAME())
```
Filters Sales to rows matching the current user's mapped region.
## USERNAME() function
Returns the current authenticated user's identity:
- In Power BI Service: email or UPN.
- In Power BI Desktop: usually `DOMAIN\username`.
Use `USERPRINCIPALNAME()` for consistent UPN across surfaces.
## Mapping table approach
Common pattern:
- Separate mapping table: `UserAccess[UserEmail, Region]`.
- Role filter joins user email to the mapping.
- Adding/removing user access = editing the mapping table.
Cleaner than hardcoding user emails in roles.
## Testing RLS
In Power BI Desktop:
- View as Roles → select role.
- Optionally "Other user" → enter email.
- Report renders as that user would see it.
Test every role before publishing.
## Assigning users to roles
In Power BI Service:
- Semantic model → Security.
- Per role, add users or groups.
- Microsoft Entra security groups recommended for scale.
## Group-based assignment
Critical at scale:
- Map an Entra group to a role.
- Add user to the group → automatically has the role.
- Remove from group → no access.
Maintenance happens in Entra, not Power BI; cleaner separation.
## Multiple roles per user
If user has multiple roles assigned:
- Filters are OR'd.
- User sees union of what each role allows.
So Role A (Region = US) + Role B (Region = EMEA) = sees US + EMEA. Sometimes desirable (regional manager covering two regions); sometimes confusing (overlapping role assignments hide intent).
## Object-level security
Beyond rows:
- Hide specific columns from specific roles.
- Hide entire tables.
- Configured in Tabular Editor or Power BI external tools.
Use cases:
- Sales sees customer financial data; Marketing doesn't.
- Engineers see technical fields; Operations doesn't.
Object-level is newer; less commonly used but powerful.
**Performance considerations.**
- RLS filters apply on every query.
- Complex DAX in roles → slow queries.
- Indexes / relationships help.
- Cardinality of filtering column matters.
For very large datasets with many users, RLS can become a performance limiter; optimise role definitions.
**DirectQuery vs Import.**
- **Import mode** — RLS filters applied at query time against imported data.
- **DirectQuery** — filters translated to source query.
- **Direct Lake (Fabric)** — filters applied at OneLake query.
All support RLS; mechanisms differ.
## Inheritance and composite models
When composite (mixed import + DirectQuery):
- RLS rules must cover both sources.
- Misconfiguration risks data leak from unfilters source.
Audit composite models carefully.
**Common pitfalls.**
- **Role not assigned.** User has access to report but no role → sees nothing (or all data, depending on default).
- **Default access too broad.** No role = all data; should be no role = no access.
- **Hardcoded user emails.** Mapping table preferred.
- **Cross-filter direction not set.** Filter doesn't propagate; data leaks.
- **Role left for testing.** "Test Admin" role with no filter; assigned in production.
- **No audit of role changes.** Role definitions drift; security gaps emerge.
**Audit and testing.**
- **Periodic role audit** — what roles, who's in them, what they see.
- **Penetration test** — try to access data outside role; should fail.
- **Documentation** — role purpose and definition documented.
**RLS vs workspace permissions.**
- **Workspace permissions** — coarse: can user open this report?
- **RLS** — fine: which rows does this user see?
Both apply. Workspace permissions give access to the report; RLS filters within.
**Dynamic vs static trade-offs.**
- **Static**: simpler, more roles needed, harder to maintain.
- **Dynamic**: more complex DAX, fewer roles, easier maintenance.
Dynamic almost always wins for deployments with > 10 users.
## Cross-system consistency
If Dataverse has its own row-level security (BU-based, hierarchical), aligning Power BI RLS to match is essential:
- Same user → same data in Dataverse and Power BI.
- Mapping table can be sourced from Dataverse user / team structure.
## Strategic positioning
Row-level security is foundational for enterprise Power BI. Without it, every report exposes all data; reports become useless for sensitive content. With it, the same semantic model serves diverse audiences appropriately. Investment in proper role design, group-based assignment, and periodic audit pays back continuously. Skipping it means either limiting reporting scope or accepting data exposure — neither acceptable for serious deployments.
---
# Power Fx explained
The Power Fx formula language — Excel-like syntax, where it's used in the Power Platform, and what's different from JavaScript.
Source: https://www.solvingdynamics365.com/guides/power-fx-explained
Section: Power Platform / Power Apps
Published: 2026-05-01
**Power Fx** is Microsoft's low-code formula language. It's the language used in Power Apps canvas apps, Dataverse formula columns, certain Power Automate scenarios, and is being adopted across more of the Power Platform every release. Designed deliberately to feel like Excel — strongly typed, declarative, functional — it's accessible to anyone who has ever written `=SUMIF(...)` in a spreadsheet.
## Excel-like syntax
Power Fx looks like Excel formulas. `=` prefix isn't used in Power Apps but the syntax is `Filter(Customers, Country = "Sweden")`, `Sum(Orders.Total)`, `If(Status = "Active", "Yes", "No")`. Anyone fluent in spreadsheets is productive in Power Fx within hours.
## Declarative
Power Fx is declarative — you describe what you want, not how to compute it. The runtime decides evaluation order, caching, and dependencies. Variables are mostly avoided; **named formulas** and **collections** (in-memory tables) are the idiomatic way to manage state.
## Functions
Hundreds of built-in functions cover text manipulation, math, dates, table operations (Filter, Sort, AddColumns, GroupBy, Sum, Count), navigation, controls, and data connection actions. Most have direct Excel equivalents.
## Records and tables
First-class data types. A **record** is a JSON-like object: `{Name: "Karen", Country: "Sweden"}`. A **table** is a list of records. Table operations are vectorised — `Filter(Customers, Country = "Sweden")` returns a table without explicit looping.
## Tables and connectors
When connected to Dataverse, SharePoint, SQL, or another data source, tables in Power Fx are *backed by* the underlying source. **Delegation** matters: functions that can be evaluated server-side (delegable) run efficiently on large datasets; non-delegable functions fall back to a 2000-row client-side limit. The maker is warned in the editor when they write a non-delegable expression.
**Where it's used.**
- **Canvas Power Apps** — every property of every control is a Power Fx expression.
- **Dataverse formula columns** — calculate values stored on records, similar to Excel formulas in a sheet column.
- **Power Apps custom pages** — embedded in model-driven apps with Power Fx behaviour.
- **Power Automate desktop** — increasingly in flow design.
- **Excel** — the syntax is converging; some Power Fx functions are now in Excel directly.
## Differences from JavaScript
No variables required, no statements, no loops. Side effects exist (`Set`, `Patch`, `Collect`, `Navigate`) but are expressions, not statements. Errors propagate as values rather than thrown exceptions.
## Limits
Not Turing-complete in the traditional sense — there are no arbitrary loops. Heavy programmatic logic still belongs in JavaScript (in HTML web resources), Power Automate flows, or C# plug-ins.
## Adoption
Excel-literate users build working apps in days. Microsoft is open-sourcing the language; a Power Fx command-line interpreter exists for testing expressions.
### Frequently asked questions
**Where is Power Fx used?**
Every property of every control in canvas Power Apps, Dataverse formula columns, custom pages embedded in model-driven apps, increasingly Power Automate, and the syntax is converging with Excel itself.
**How is Power Fx different from Excel formulas?**
The syntax is deliberately Excel-like — Filter, Sum, If — but expressions run against tables backed by data sources, records are first-class JSON-like values, and side effects such as Set, Patch, and Collect exist as expressions rather than statements.
**What is delegation in Power Fx?**
Whether a function can be evaluated server-side by the data source. Delegable expressions run efficiently on large tables; non-delegable ones fall back to a client-side limit of 2,000 rows, and the editor warns when you write one.
**Can Power Fx replace JavaScript or C#?**
Not for heavy programmatic logic. Power Fx has no arbitrary loops or statements; complex logic still belongs in JavaScript web resources, Power Automate flows, or C# plug-ins.
---
# Power Fx named formulas
How named formulas in Power Fx differ from variables — declarative, recomputed, no side effects — and how they reshape canvas app code organisation.
Source: https://www.solvingdynamics365.com/guides/power-fx-named-formulas
Section: Power Platform / Power Apps
Published: 2026-05-01
Named formulas are a relatively recent addition to canvas apps that, once understood, change how an experienced maker organises code. They're named expressions evaluated lazily when referenced, with no explicit assignment and no implicit recomputation cost — a properly functional layer on top of Power Fx that complements (and often replaces) variables.
## The historical pattern: variables
Canvas apps have long had variables — `Set(varCurrentUser, User())`, `UpdateContext({selected: thisItem})`. Variables are mutable, assigned imperatively, persist until reassigned. They're familiar to developers from imperative languages but they create classic problems: out-of-date values, race conditions on async work, scattered assignments.
**Named formulas in App.Formulas.** In the canvas app `App` object's `Formulas` property:
```
CurrentUser = User();
DefaultSiteId = First(Sites).Id;
TodayLabel = "Today is " & Text(Today(), "long");
GrossMargin = SalesAmount - CostAmount;
```
Each line names a formula. Anywhere the name is referenced, the formula re-evaluates. There's no `Set`, no `Update`. The compiler can detect dependencies and recompute lazily.
**Properties.**
- **Declarative** — you say what it is, not when to compute it.
- **Pure** — no side effects allowed in the formula.
- **Lazy** — only evaluated when referenced.
- **Cached intelligently** — re-evaluated when dependencies change, not on every reference.
- **Constant by reference** — the name always means the same expression, never "the value at a moment in time."
**Compared to variables.**
| Aspect | Variable | Named Formula |
|---|---|---|
| Assignment | `Set(name, value)` | `name = expr;` in App.Formulas |
| Mutability | Mutable | Immutable definition |
| Update | Manual via Set | Auto-recompute on dependency change |
| Side effects | Allowed | Not allowed |
| Scope | App-wide or screen-local | App-wide |
| Asynchronous | Yes, can store Patch results | No, must be synchronous |
**When to use named formulas.**
- **Derived values** — anything computed from other state.
- **Configuration constants** — labels, defaults.
- **App-wide reference data** — current user, current language, today's date.
- **Pure transformations** — formatted labels, filtered collections (where filter inputs are stable).
**When to keep using variables.**
- **Async results** — outputs from `Patch`, custom connector calls.
- **Mutable UI state** — selected tab, current step in a wizard.
- **Counters and toggles** — anything explicitly time-varying.
## Example: replacing OnStart variables
A common pattern is loading reference data in App.OnStart:
```
Set(varCurrentUser, User());
Set(varDefaultSite, First(Sites));
Set(varTodayLabel, "Today is " & Text(Today(), "long"));
```
Equivalent with named formulas in App.Formulas:
```
CurrentUser = User();
DefaultSite = First(Sites);
TodayLabel = "Today is " & Text(Today(), "long");
```
The named formula version:
- Doesn't block app start (lazy).
- Recomputes automatically when underlying data changes.
- Lives in one place; no need to remember Set is called somewhere.
For typical reference data loads, this is a meaningful UX improvement — app starts faster.
## Dependency tracking
Power Fx tracks dependencies. If `GrossMargin = SalesAmount - CostAmount` and `SalesAmount` is itself a named formula or a data source field that changes, GrossMargin re-evaluates automatically. The maker doesn't trigger updates manually.
## Performance
Lazy evaluation means formulas referenced but never used cost nothing. Formulas referenced once compute once. Formulas referenced repeatedly within a render cycle benefit from caching. Heavy formulas referenced in a galaxy of bound controls can still be expensive — design accordingly.
**Limitations.**
- **No side effects** — `Patch`, `Notify`, `Navigate` are not allowed.
- **Synchronous only** — connector calls returning async results not allowed.
- **No If/With with control mutation** — pure expressions only.
- **App-level scope** — named formulas live on App, not per screen.
## Component formulas
Power Fx custom components can have their own named formulas, scoped to the component. Useful for component-internal derived values without polluting app scope.
**Best practices.**
- **Use named formulas as defaults for any derived value.** Reach for variables only when mutability is genuinely required.
- **Name carefully** — these are app-wide; use Pascal or clear prefixes.
- **Refactor large App.OnStart** — most Set calls can become named formulas, dramatically simplifying start logic.
- **Document the dependency graph** when it gets complex — a comment block at the top of App.Formulas listing key formulas helps future maintainers.
**Common pitfalls.**
- **Mixing imperative thinking** — trying to "trigger" a formula recompute. Power Fx handles this; if it's not recomputing, it's because dependencies haven't changed.
- **Storing async results** — won't work; needs variable.
- **Over-reliance on App scope** — sometimes a per-screen variable is genuinely the right scope.
## Operational guidance
Named formulas are the modern default for derived state in canvas apps. They reduce code, improve correctness, and produce apps that are easier for the next maker to understand. The "imperative variable everywhere" style is still common but increasingly outdated.
---
# Power Pages for Dynamics 365 customer portals
Building customer-facing portals on top of Dataverse — Power Pages templates, authentication, security, and operational realities.
Source: https://www.solvingdynamics365.com/guides/power-pages-for-customer-portals
Section: Power Platform / Power Pages
Published: 2026-05-01
**Microsoft Power Pages** is the low-code platform for building secure, external-facing websites that read and write Dataverse. For Dynamics 365 customers, it's the standard way to deliver customer self-service portals, B2B partner extranets, public-sector citizen portals, event-registration sites, and supplier collaboration hubs.
## The shape of a Power Pages site
A site has **pages** (content), **web templates** (Liquid-driven layout), **forms** (rendering Dataverse forms with controlled fields and permissions), **lists** (rendering Dataverse views), and **web files** (assets — images, scripts, stylesheets). Everything is configured through a maker portal with both visual designers and direct code editing.
## Authentication
Power Pages supports multiple identity providers: **Entra ID**, **Microsoft account**, **Google**, **Facebook**, **LinkedIn**, **Apple**, and any **OpenID Connect** or **SAML 2.0** provider. **Local accounts** (username/password stored in Dataverse) are also supported but discouraged. Anonymous browsing is allowed where the use case fits (public knowledge portals); behind a login is the more common pattern.
## Identity to record mapping
Authenticated users map to **Contact** records in Dataverse — one portal user is one Contact. Self-registration and identity-provider sign-up flows create the Contact automatically; admin-driven invitations are also possible.
## Web roles
Permissions inside Power Pages are governed by **web roles** assigned to Contacts. Each role grants access to pages, forms, lists, and Dataverse data through **table permissions**. The pattern is similar to Dynamics 365 security roles but scoped to portal users only; production CRM users don't get portal permissions through Dataverse roles.
## Table permissions
Critical concept. **Table permissions** define what portal users can read, write, create, delete on specific Dataverse tables, scoped by relationship (e.g. "this Contact can read their Account's Cases", not "any Case"). Misconfigured table permissions are the most common Power Pages security mistake — too permissive grants data leaks; too restrictive blocks users from their own data.
## Customer use cases
Most Dynamics 365 customers use Power Pages for at least one of:
- **Case logging** — customers create and track cases against Customer Service.
- **Knowledge browsing** — exposing the customer-facing slice of the knowledge base.
- **Account self-service** — customers update contact info, see invoices, pay online (with payment-processor integration).
- **Partner portals** — distributors and resellers access deal registration, pricing, and shared opportunities.
## Limits
Power Pages is great at moderate-complexity portals. Highly visual marketing sites, e-commerce checkouts, and complex public-facing experiences often integrate Power Pages for the data-driven sections with a separate CMS or framework for the rest.
## Operating cost
Per active user per month, with a separate anonymous-page-view tier. Capacity is bought in packs.
---
# Power Pages Liquid templating
How Liquid templates work in Power Pages — variables, tags, filters, rendering Dataverse data, and the design patterns for customer-facing portals.
Source: https://www.solvingdynamics365.com/guides/power-pages-liquid-templating
Section: Power Platform / Power Pages
Published: 2026-07-28
Power Pages portals — Microsoft's external-facing website platform on top of Dataverse — render content through the **Liquid** template language. Originally created by Shopify, Liquid is a logic-light templating language designed for safe content rendering. Understanding it is essential for building anything beyond the simplest Power Pages portal.
## The Liquid concept
Liquid templates mix HTML with **objects** (data variables), **tags** (control flow), and **filters** (transformations). Templates compile and render server-side; the result is HTML sent to the user's browser.
**Three types of Liquid elements.**
- **Output** (in `{{ }}`) — print a value.
- **Tags** (in `{% %}`) — control flow (if, for, capture, etc.), but no output.
- **Filters** (in `| filter`) — transform values during output.
Example:
```liquid
{% if user.fullname %}
Welcome, {{ user.fullname | upcase }}!
{% else %}
Welcome, guest.
{% endif %}
```
The `{% if %}` and `{% endif %}` are tags; `{{ user.fullname }}` is an output; `| upcase` is a filter.
## Power Pages-specific objects
The portal exposes specific objects:
- **`user`** — the authenticated user (when signed in). Properties include `fullname`, `email`, `id`, `roles`.
- **`page`** — the current page being rendered. Properties: `title`, `summary`, `url`.
- **`entities`** — access to Dataverse entities. Used for querying records: `{% entitylist logical_name:"contact" %}`.
- **`entityform`** — for forms tied to specific Dataverse forms.
- **`weblinks`** — navigation menus configured in Power Pages.
- **`request`** — current HTTP request context.
- **`settings`** — site-level configuration.
- **`now`** — current date/time.
These objects give templates access to the live data layer of the portal.
**Querying Dataverse records.**
```liquid
{% fetchxml entities_query %}
{% endfetchxml %}
{% for opp in entities_query.results.entities %}
{{ opp.name }} — {{ opp.estimatedvalue | currency }}
{% endfor %}
```
The `{% fetchxml %}` tag runs a FetchXML query; the result is available in subsequent template logic. Power Pages also supports the `{% entityview %}` tag for using saved Dataverse views and `{% entitylist %}` for configured lists.
**Common filters.**
- **`upcase`, `downcase`, `capitalize`** — case manipulation.
- **`date`** — format dates (`{{ contact.createdon | date: "yyyy-MM-dd" }}`).
- **`currency`** — format money values.
- **`escape`** — HTML-escape (default for user content; rarely turned off).
- **`size`** — count of array or characters of string.
- **`first` and `last`** — first / last element of an array.
- **`limit`** — limit array to N elements.
- **`truncate`** — shorten text.
- **`replace`** — string replace.
- **`url_encode`** — for building safe URLs.
**Logic — `if`, `unless`, `case`.**
```liquid
{% if user.roles contains 'VIP' %}
VIP content
{% elsif user.roles contains 'Member' %}
Member content
{% else %}
Public content
{% endif %}
{% case user.country %}
{% when "Sweden" %}
Welkommen!
{% when "Germany" %}
Willkommen!
{% else %}
Welcome!
{% endcase %}
```
**Loops — `for`.**
```liquid
{% for opportunity in opportunities %}
{{ opportunity.name }}
{% endfor %}
{% for product in products limit: 5 %}
{{ product.name }}
{% endfor %}
```
## Capture and variables
`{% capture %}` stores rendered output in a variable for later use:
```liquid
{% capture greeting %}
Hello, {{ user.fullname | default: "guest" }}
{% endcapture %}
{{ greeting }}
```
## Includes
Reusable template fragments via `{% include %}`:
```liquid
{% include 'header' %}
... main content ...
{% include 'footer' %}
```
## Performance
Liquid is fast but complex queries inside loops can degrade:
- Move queries outside loops where possible.
- Use `{% fetchxml %}` with precise filters rather than fetching everything.
- Cache repeated lookups in `capture` variables.
## Security
Liquid is sandboxed — templates can't execute arbitrary code; they can only call defined functions and access defined data. This is the deliberate safety property — templates run as content, not as code.
User-supplied input rendered through Liquid is escaped by default (HTML-escaped), preventing XSS. Don't bypass escaping unless you know the source is trusted.
**Common pitfalls.**
- **Queries inside heavy loops** — N+1 query pattern slows rendering.
- **Forgetting to escape** — using `| raw` or similar to bypass escaping on user content is an XSS vulnerability.
- **Templates that mix too much logic** — Liquid is for presentation; complex business logic belongs in Power Automate / plug-ins, not templates.
- **Unfamiliar filter / tag** — Microsoft documents Power Pages-specific extensions; verify exists before using.
## Operational reality
Liquid is straightforward once you've built a few templates. The Power Pages designer + Liquid combination produces effective portals without diving into full web development. For more complex needs (rich client interaction, custom UI), consider whether Power Pages is the right tool or if a custom-built solution makes more sense.
---
# Power Pages security, in depth
How Power Pages secures external-facing portals — identity providers, web roles, table permissions, page permissions, and the audit and DLP that wraps them.
Source: https://www.solvingdynamics365.com/guides/power-pages-security-in-depth
Section: Power Platform / Power Pages
Published: 2026-05-01
Power Pages portals are exposed on the public internet, and most of them give external users authenticated access to Dataverse data. Getting the security model right matters more here than in any internal Power Platform application. The good news: the security model is well-defined and the pitfalls are documented.
## Identity
Authenticated portal users are represented in Dataverse as **Contact** records. The contact has a primary identity-provider linkage — usually OAuth-2.0 via Entra ID, an external identity provider (Google, Microsoft, Facebook, Apple, LinkedIn), or a SAML/OpenID Connect federation. **Local accounts** (username/password stored in Dataverse) are supported but discouraged; identity-provider sign-in is more secure and scales better.
## Multi-factor authentication
Configurable at the identity-provider level (e.g. Entra ID Conditional Access policies enforce MFA on the IdP, and Power Pages inherits it).
## Web roles
Once authenticated, a portal user gets one or more **web roles**. Web roles are the portal-side equivalent of Dataverse security roles, but scoped to the portal only — they don't grant access to the underlying Dynamics 365 application. Each web role is associated with **table permissions**, **page permissions**, and **content permissions**.
## Table permissions
The most important and most misconfigured Power Pages concept. **Table permissions** define what portal users (in specific web roles) can do with specific Dataverse tables. The privileges are familiar — Read, Create, Write, Delete, Append, Append-To — but the scope is what makes it nuanced:
- **Global** — across all rows in the table. Use sparingly; usually too permissive.
- **Contact** — rows owned by the signed-in contact. The default for self-service: a customer sees their own profile.
- **Account** — rows owned by the signed-in contact's parent account. A B2B portal: a buyer sees their company's data.
- **Parental** — through a configured 1:N relationship from a parent the user has permission to. E.g. cases linked to the user's account: the user has permission on cases because they have permission on the account, and the relationship grants child access.
Misconfigured table permissions are the #1 source of Power Pages data leaks. Test every permission scenario before going live.
## Page permissions
Control which authenticated users see which pages. Anonymous browsing of certain pages, web-role gating of others. A "members area" exists because page permissions block unauthenticated users.
## Content permissions
Control which file attachments are visible per user — for portals that distribute documents (statements, policy documents) per customer.
## Anti-CSRF and request validation
Power Pages includes built-in protection against cross-site request forgery, with form-level tokens. Don't disable these.
## Audit and logging
Portal access events log to Dataverse audit; configure audit on sensitive tables. Identity-provider login events log at the IdP.
## DLP
Power Pages can be governed by **data loss prevention policies** like any other Power Platform app, classifying connectors as Business / Non-Business and preventing inadvertent data flow.
## Operational reality
Run a security review before every Power Pages launch. Test every web role with a real test user. Audit table permissions quarterly. Treat portal security with the same rigour as a public website.
---
# Power Pages with Dataverse search
How to make Power Pages portals searchable — enabling Dataverse search, scoping by table and security, indexing, and the patterns for portal-friendly search UX.
Source: https://www.solvingdynamics365.com/guides/power-pages-with-dataverse-search
Section: Power Platform / Power Pages
Published: 2026-05-01
A Power Pages portal exposing dozens of tables, hundreds of articles, and thousands of cases needs **search** to be usable. The built-in answer is **Dataverse search** — the Lucene-based search service powering global search in model-driven apps, exposed to Power Pages through portal-aware components and security trimming.
**What Dataverse search provides.**
- **Full-text indexing** of configured tables and columns.
- **Relevance ranking** across multiple tables.
- **Auto-suggest** as the user types.
- **Faceting** — filter by table type, by attribute.
- **Security trimming** — results respect user permissions.
For a portal, security trimming is the headline feature — anonymous users see public articles; authenticated contacts see public + their organisation's records.
## Enabling Dataverse search
At environment level:
1. Power Platform admin centre → environment → Settings → Product → Features.
2. Enable Dataverse search.
3. Wait for initial indexing — depends on table sizes, typically minutes to hours.
Per table, in the table designer:
1. Properties → Searchable: Yes.
2. Search index: add specific columns to index.
Without searchable tables, Dataverse search returns nothing.
## Search in Power Pages
The portal exposes search through:
- **Search bar component** — drop into a page; users type, results display.
- **Search page** — dedicated full results experience.
- **Filtering** — facet by table or by attribute.
- **Highlighting** — matched text highlighted in results.
The component handles security trimming via the portal's authenticated identity (anonymous or contact-bound).
## Indexing columns thoughtfully
Index columns users actually search:
- Title, name, subject columns — always.
- Description, body columns — usually.
- Tag/keyword columns — yes.
- Internal IDs, system columns — usually no, unless users search by ID.
Over-indexing inflates the index and slows ranking; under-indexing makes search blind.
## Search results security
Power Pages search uses **table permissions** — the portal-specific access control mechanism. A search result row is shown only if:
- The user has read access to the row through the portal's web role and table permission configuration.
- The row matches the search query.
Anonymous users see only rows accessible to the "Anonymous Users" web role; authenticated users see additionally what their contact's web roles grant.
## Auto-suggest
Typing a few characters returns instant suggestions:
- Top 5–10 results.
- Live as the user types.
- Includes top tables to scope to.
The suggestion experience is critical for portal usability — users abandon search if it's slow.
## Custom search
For requirements beyond Dataverse search:
- **Azure Cognitive Search** integration via custom code.
- **External search engines** (Algolia, ElasticSearch) via integration.
- **Liquid templates** invoking custom search APIs.
Most portals stay with Dataverse search; custom search is for unusual cases (specific ranking logic, advanced linguistic analysis).
**Common pages with search.**
- **Knowledge base** — search KB articles.
- **Case lookup** — find existing cases.
- **Product catalogue** — search products.
- **Forum / community** — search discussions.
- **Document library** — search uploaded files.
For each, the search page is configured to scope to relevant tables.
## Liquid-template integration
Power Pages' Liquid templating language lets you embed search results into pages programmatically — render a featured-results widget on the home page, run a "you might also like" search based on the current page context.
## File search
Power Pages supports **file attachments** on Notes and Document Locations. Dataverse search can index the content of attached files (PDF, Word, Excel, text) — searching for "warranty terms" finds the PDF where the phrase appears. Indexing is asynchronous after attachment upload.
**Common pitfalls.**
- **No initial indexing wait.** Search runs against an empty index for a while; users assume it's broken.
- **Table permissions missing.** A table is indexed but no portal permission; search finds nothing for the user.
- **Wrong columns indexed.** The user searches by SKU; SKU column isn't indexed; finds nothing.
- **Too many tables enabled.** Search returns noise; faceting helps but only if the user knows to use it.
- **Performance under load.** Large portals with thousands of concurrent searches hit indexing limits; Premium capacity may be needed.
## Reindexing
When you change indexed columns:
- The index needs to rebuild.
- Power Platform handles rebuild asynchronously.
- During rebuild, results may be incomplete.
- Schedule reindexing for low-traffic windows.
## Operational rule
Portal search is the navigation tool users actually reach for after the first day. Tune it: pick the right tables, index the right columns, design search pages that respect security, and monitor search analytics for "no results" patterns that reveal indexing gaps or missing content. A portal whose search "just works" is a portal users return to.
---
# Power Platform ALM with Azure DevOps
How to set up CI/CD for Power Platform using Azure DevOps — Build tools, pipelines, source control, and automated deployment between environments.
Source: https://www.solvingdynamics365.com/guides/power-platform-alm-with-azure-devops
Section: Power Platform / ALM & governance
Published: 2026-05-01
For Power Platform teams that take application lifecycle management seriously, the canonical CI/CD path runs through **Azure DevOps** (or its sibling GitHub Actions). The Microsoft-published **Power Platform Build Tools** extension supplies the building blocks; the rest is pipeline composition.
## Power Platform Build Tools
A free Azure DevOps extension Microsoft maintains. It provides tasks for:
- **Authenticate** — service-principal sign-in to a Power Platform environment.
- **Tool installer** — install / cache the `pac` CLI.
- **Pack / unpack solution** — convert between solution.zip and unpacked source files.
- **Import / export solution** — pull from or push to an environment.
- **Publish customisations** — make changes effective after import.
- **Apply / unpack solution upgrade** — managed solution upgrade flow.
- **Solution checker** — static analysis against Microsoft's published rules.
- **Set solution version** — update version in metadata before packaging.
- **Reset environment** — wipe and restart a sandbox.
These tasks compose into pipelines covering build, validation, and deployment.
**Typical pipeline structure.**
```yaml
# Build pipeline (runs on PR or main commit)
- Checkout source from Git
- Pack solution from unpacked source folder
- Run solution checker against the packed solution
- Publish artefact: the .zip
# Release pipeline (deploys to environments)
- Stage 1: Deploy to UAT
- Import managed solution to UAT environment
- Run smoke tests (Power Automate or custom)
- Manual approval gate
- Stage 2: Deploy to Production
- Import managed solution to Production environment
- Publish customisations
- Notify stakeholders
```
## Source control structure
A typical repo:
```
src/
Solution.Customer/
Other/ (solution.xml, customizations.xml)
Entities/ (per-table folders with metadata)
Workflows/
Reports/
Plugins/
WebResources/
PluginAssemblies/
build/
build.yml
release.yml
```
`pac solution unpack` extracts a solution.zip into this folder structure for source control; `pac solution pack` converts back to a .zip for deployment.
## Service principals
Pipelines authenticate to Power Platform environments as **service principals** registered in Microsoft Entra ID. Each environment trusts a service principal with appropriate permissions (System Administrator role on the target Dataverse environment). Storing credentials in Azure DevOps secret variables (or Azure Key Vault for higher security) keeps them out of source.
## Solution checker integration
A best practice is to gate every PR build on **solution checker** results. The checker scans for performance issues, security concerns, accessibility problems, and platform misuse. Failing the build on critical issues forces fixes before merge.
## Environment variables
Solutions can contain **environment variables** that hold values differing per environment — API URLs, connection identifiers, feature flags. The pipeline injects the correct values per target environment at import time.
## Connection references
Power Automate flows depend on **connection references** that abstract the specific connection used. The pipeline maps connection references to actual connections per environment, so a flow that calls SharePoint in dev hits the dev SharePoint, and in production hits production SharePoint.
## Approval gates
Production deployments should require manual approval — typically a release manager or governance team signing off. Azure DevOps supports approvals with deferral, audit, and Teams integration.
## Telemetry and rollback
Capture deployment success / failure events to Application Insights. Configure rollback as a separate pipeline that imports the previous solution version. Test the rollback occasionally.
## Operational reality
Teams that adopt Power Platform ALM with Azure DevOps deploy more confidently and recover from issues faster. The initial investment — pipeline build, training, source-control migration of existing solutions — takes a week or two; the ongoing pay-off compounds over years.
---
# Power Platform ALM with managed solutions
Application lifecycle management on the Power Platform — solutions, managed vs unmanaged, environments, pipelines, and source control.
Source: https://www.solvingdynamics365.com/guides/power-platform-alm-with-managed-solutions
Section: Power Platform / ALM & governance
Published: 2026-05-01
Application lifecycle management (ALM) is what turns one-off Power Platform experiments into a maintainable system. Microsoft's ALM story is centred on **solutions** — versioned, deployable containers of components — moving through a chain of environments with controlled promotion.
## Solutions
A **solution** is a Dataverse-aware bundle of customisations: tables, columns, forms, views, charts, web resources, Power Automate flows, canvas apps, model-driven apps, business process flows, security roles, and many more. A solution has a publisher (with a prefix that scopes custom names) and a version number.
## Unmanaged vs managed
Solutions exist in two states:
- **Unmanaged** — editable. Components inside an unmanaged solution can be modified in the environment they live in. The state of every dev environment.
- **Managed** — read-only at the component level. Imports of managed solutions install or update components without letting downstream users edit them. The state of every UAT and production environment.
## The flow
Develop in an unmanaged solution in a **dev environment**. Export the solution as managed. Import the managed solution to **UAT**. Test. Import the same managed package to **production**. Repeat per release.
## Environments
A healthy Power Platform deployment uses at least three environments: **Dev**, **Test/UAT**, **Production**. Larger organisations add per-feature dev environments, hotfix environments, and training environments. Each environment is administered through the **Power Platform admin centre**.
## Pipelines
**Power Platform pipelines** is Microsoft's built-in promotion mechanism: configure a pipeline from dev → UAT → prod, with approvals and validation gates, and run promotions from the maker portal. For more complex needs, **Azure DevOps** or **GitHub Actions** with the **Power Platform build tools** automate end-to-end CI/CD: export solution on commit, build, validate, deploy.
## Source control
Solutions can be **unpacked** with the `pac` CLI into a folder of XML and YAML files — one file per table, form, flow, app — that lives in Git. Pull requests review the diff, branches isolate features, and pipelines build and deploy on merge. This is the canonical way to manage non-trivial Power Platform development.
## Solution layering
Multiple solutions can install on top of each other (e.g. ISV base + customer customisations). Layering is helpful for ISV scenarios; for in-house teams it complicates things — start with one solution per logical app.
## Anti-patterns
Editing directly in production. Building in the default environment. Having no version control. All trade speed today for pain forever; resist them from day one.
## Where to go next
Next: [solution patches vs upgrades](https://www.solvingdynamics365.com/guides/solution-patches-vs-solution-upgrades) for the release rhythm, [connection references and environment variables](https://www.solvingdynamics365.com/guides/connection-references-and-environment-variables) for environment-specific configuration, [import and export pipelines](https://www.solvingdynamics365.com/guides/solution-import-export-pipelines) and [ALM with GitHub Actions](https://www.solvingdynamics365.com/guides/alm-with-github-actions-for-power-platform) for automation. When an import fails, [solution import errors](https://www.solvingdynamics365.com/guides/dataverse-solution-import-errors) is the reference.
---
# Power Platform environments
Environments in the Power Platform — types, capacity, regions, and how they relate to Dynamics 365 and Dataverse.
Source: https://www.solvingdynamics365.com/guides/power-platform-environments
Section: Power Platform
Published: 2026-05-01
An **environment** in the Power Platform is an isolated container for apps, flows, Dataverse data, and security. Environments are the unit of administration, capacity, region, and licensing. Every Dynamics 365 CRM-side app *is* an environment with Dataverse plus the relevant Dynamics 365 components installed. Understanding the environment model is foundational.
**Environment types.**
- **Default.** Every tenant has a single default environment, automatically created and owned by Microsoft Entra ID. It's intended for personal productivity makers and casual flows, *not* for production business apps. Treat it as untrusted; lock it down with DLP policies.
- **Production.** A first-class environment for running real apps. Includes Dataverse. The standard target for any deployed Dynamics 365 or Power Apps app.
- **Sandbox.** A non-production environment for testing, training, and demos. Can be reset, copied from another environment, and converted to production.
- **Developer.** Personal environments for individual makers, with Dataverse, scoped to the maker's own work. Free up to a usage cap.
- **Trial.** Time-limited environments that expire automatically.
- **Microsoft Dataverse for Teams.** A lightweight, Teams-scoped environment with a constrained Dataverse for in-team apps. Different storage model from full Dataverse.
## Capacity
Each tenant has Dataverse storage capacity allocated by licences and add-ons. Environments compete for that capacity; the **Power Platform admin centre** shows usage per environment. Production environments consume more capacity than sandboxes; defaults are surprisingly small.
## Regions
Environments are pinned to a region (Europe, North America, Asia Pacific, etc.) at creation. Region determines where Dataverse data physically lives. Moving an environment between regions requires a Microsoft-supported migration; default to creating in the right region.
## Security groups
Each environment can be assigned a **Microsoft Entra security group** that controls who's allowed in. Without one, anyone in the tenant with a sufficient licence can access the environment — usually not what you want for production. Set the security group on day one.
## Environment admin and DLP
Tenant admins enforce **data loss prevention (DLP) policies** that classify connectors (e.g. SharePoint and Dataverse as Business; Twitter and HTTP as Non-Business) and forbid flows from combining Business with Non-Business. DLP applies per environment or globally.
## Lifecycle
Environments can be copied (data and customisations), reset (data wiped), backed up (Dataverse storage), and restored from backup. Production environments get 28 days of point-in-time restore by default.
## Cost
Beyond Dataverse storage, environments themselves are usually free up to a count. Pay-as-you-go billing is available for tenants that want capacity-billed environments without licence allocation.
## Where to go next
The design question — how many, for whom — is [environment strategy for Dynamics 365 projects](https://www.solvingdynamics365.com/guides/environment-strategy-for-dynamics-365-projects). Governance on top of environments is [Managed Environments](https://www.solvingdynamics365.com/guides/managed-environments-in-power-platform) and [DLP policies](https://www.solvingdynamics365.com/guides/dlp-policies-in-power-platform), administered from [the Power Platform admin center](https://www.solvingdynamics365.com/guides/power-platform-admin-center). Capacity is explained in [Dataverse storage types](https://www.solvingdynamics365.com/guides/dataverse-storage-types-explained).
### Frequently asked questions
**What should the default environment be used for?**
Personal productivity and casual flows only. Every tenant gets one, owned by Entra ID, and it should be treated as untrusted and locked down with DLP policies — never as the home for production business apps.
**What environment types exist?**
Default, production, sandbox (resettable, copyable, convertible to production), developer (free personal environments with Dataverse up to a cap), trial (auto-expiring), and Dataverse for Teams with its constrained storage model.
**How do I restrict who can access an environment?**
Assign a Microsoft Entra security group to it. Without one, anyone in the tenant with a sufficient licence can get in. Set it on day one for production.
**Can I move an environment to another region?**
Only through a Microsoft-supported migration. Region is fixed at creation and decides where Dataverse data physically lives, so create in the right region from the start.
---
# Prepayments in Business Central
How Business Central handles prepayments — sales and purchase prepayment invoices, GL impact, and the integration with order processing.
Source: https://www.solvingdynamics365.com/guides/prepayments-in-business-central
Section: Business Central / Finance & accounting
Published: 2026-05-01
**Prepayments** in Business Central handle the accounting for invoices issued or received *before* the goods are delivered or services rendered. Deposit on a sales order, advance to a vendor, milestone billing tied to an order — all are prepayment scenarios. The mechanism is well-defined but unfamiliar to anyone who has only seen simple post-and-pay systems.
## The business problem
A customer places an order worth 100,000. Terms require 30% on order (a deposit) and 70% on delivery. Without prepayment functionality, you'd post a separate manual invoice for 30,000, then later post the full 100,000 sales invoice, then somehow reconcile the two. Prepayments build this into the order processing flow.
## Setting up prepayments
Each sales and purchase line carries a **prepayment %** field (defaulting from the customer/vendor or set per line). Prepayment **posting accounts** — separate from regular sales/purchase accounts — are configured in the general posting setup: *Sales Prepayments Account* (a balance-sheet liability for prepayments received) and *Purchase Prepayments Account* (a balance-sheet asset for prepayments paid).
## The prepayment invoice
From a sales order with prepayment % set, the user issues a **prepayment invoice**. Business Central calculates the prepayment amount (sum of line × prepayment %), posts it to the Sales Prepayments Account (rather than a revenue account), and creates a customer ledger entry. The customer is invoiced, can pay, and the payment is recorded as a normal receipt against the prepayment invoice.
## The final invoice
When the goods ship or the service is delivered and the *final* sales invoice posts, Business Central recognises the full revenue, then reverses the previously-posted prepayment from the Sales Prepayments Account, so the net effect is correct: revenue recognised on delivery, no double-counting of cash.
## Partial deliveries
Both prepayments and final invoices can be partial; the prepayment amount remaining is tracked per line and consumed proportionally as the final invoice posts.
## Purchase prepayments
The mirror image. A purchase order with prepayment % triggers a prepayment invoice received from the vendor, posted to Purchase Prepayments Account. When the goods receipt happens and the final invoice posts, the prepayment is reversed.
## VAT
Prepayments are VAT-relevant. Prepayment invoices include VAT at the prepayment rate; the final invoice reconciles the VAT correctly. Country localizations vary on the exact VAT treatment — verify per country.
**Common pitfalls.**
- **Mixing prepayment and non-prepayment lines** on the same order is supported, but adds complexity. Keep simple where possible.
- **Cancelling a prepayment invoice** before the goods ship requires reversing the prepayment and the related receipt; not difficult but rarely done, so users need training.
- **Foreign currency prepayments** with FX revaluation between prepayment and final invoice produce additional FX gain/loss entries; configure FX revaluation routines to include the prepayment accounts.
## Statutory uses
In several jurisdictions, prepayment invoices are statutorily required for any payment before delivery. Configure prepayment % accordingly.
---
# Printers and print management in Business Central
How Business Central handles printing — cloud printer setup, Universal Print, document-to-printer routing, and the patterns for warehouse and retail printing.
Source: https://www.solvingdynamics365.com/guides/business-central-printers-and-print-management
Section: Business Central / Admin & ops
Published: 2026-05-01
Updated: 2026-08-25
Printing from a cloud SaaS application to physical printers is harder than from on-premise software. Business Central solves this through **cloud printing integrations**, **Universal Print** support, and document-to-printer routing rules. For operations that print invoices, packing lists, shipping labels, and warehouse documents at volume, configuring printing well matters.
## The historical pain
BC on-premises printed directly to local printers. BC SaaS runs in Microsoft's cloud — no direct path to a printer at the customer's site. Three solutions emerged:
- **Print to PDF** — generate PDF, user manually prints. Workable for low volume.
- **Email to printer** — send PDF to a printer's email address. Some printers support this.
- **Cloud print services** — Microsoft Universal Print or third-party (PrintNode, Printix).
## Universal Print integration
Microsoft Universal Print is the strategic answer:
- Microsoft cloud service.
- Customer's on-prem printers registered with Universal Print.
- BC sends print jobs to Universal Print.
- Universal Print delivers to the physical printer.
Setup involves Universal Print licence (separate from BC), printer registration, and BC's Universal Print connector configuration.
**Configuration in BC.**
- **Printer Selections** page maps documents to printers.
- Each printer record represents a Universal Print printer.
- Documents (Sales Invoice, Picking List, etc.) routed to designated printers.
The mapping is per-company; admins maintain it.
## Print management on documents
Some documents have **Print Management** rules:
- **By customer / vendor** — specific customer gets paper invoice; others get email.
- **By document type** — orders to a specific printer; invoices to another.
- **By number of copies** — different copies for different recipients.
The configuration sits on customer/vendor cards or globally.
**Warehouse-specific printing.**
- **Picking lists** — printed at the start of a pick.
- **Packing lists** — at packing station.
- **Shipping labels** — at the ship station.
- **Receipt confirmations** — at the dock.
Each station typically has its own dedicated printer; routing matters.
**Retail printing (Commerce).**
- **Receipts** — printed at POS terminal directly via POS hardware.
- **Different model from BC printing** — POS hardware drivers handle receipt printers.
- **Universal Print** less relevant for receipt printing; specialty drivers.
## Label printing
Specialty:
- **ZPL (Zebra)** — Zebra label printers.
- **Bartender, NiceLabel** — third-party label software.
- **Direct from BC** — limited; usually a label printing extension.
## Per-tenant extensions for printing
Many partners build BC extensions that:
- Print directly to PrintNode / similar cloud print API.
- Generate barcode labels.
- Support specific printer models.
- Handle high-volume warehouse printing.
**Cloud printer setup.**
1. Print server in customer environment connects on-prem printers to Universal Print or third-party.
2. Printers appear in cloud print service.
3. BC registered to print to those printers.
The print server is a managed component; small VM running the print connector.
## Email-based printing alternatives
For simple needs:
- Printer email address configured.
- BC sends documents as email attachments to printer.
- Printer prints automatically.
Works for simple cases; not all printers support this; security implications.
**Common pitfalls.**
- **Printer routing forgotten.** Documents print to default; chaos at multiple stations.
- **Universal Print licence missed.** Required licence not provisioned.
- **Print connector down.** Print server crashes; printing stops; nobody notices until queue piles.
- **PDF rendering fonts.** Custom fonts not embedded; receipts look wrong.
- **Receipt printer not handled.** POS uses different mechanism than BC's print management.
**Operational rhythm.**
- **Daily** — print queue monitoring (Universal Print console).
- **Weekly** — printer maintenance, paper replenishment.
- **Per outage** — restart print connector; verify queues.
## Strategic positioning
Printing is unglamorous but critical for warehouse, manufacturing, and retail operations. Plan early; Universal Print is the strategic path for most scenarios. For specialty label printing or high-volume retail receipts, partner extensions or specialty drivers fill the gaps. The investment is moderate; the alternative (manual PDF printing, scattered email-to-printer hacks) costs ongoing operational pain.
---
# Process designer and classic workflows in Dataverse
The legacy workflow engine in Dataverse — what classic workflows do, the migration to Power Automate, and what still uses them.
Source: https://www.solvingdynamics365.com/guides/process-designer-and-classic-workflows
Section: Customer Engagement / Dataverse platform
Published: 2026-07-08
Before Power Automate became the cloud-flow standard, Dynamics 365 had **classic workflows** — a configuration-based, code-light workflow engine running inside Dataverse. The classic engine still exists, still works for many scenarios, and is what some standard Dynamics 365 features still use internally. But Power Automate has substantially superseded it for new build.
**Classic workflow basics.**
A **classic workflow** is a Dataverse-internal process that runs on:
- **Record events** — create, update of specific fields, delete, status change, assignment.
- **Scheduled trigger** — periodic execution.
- **On-demand** — invoked manually by a user.
Each workflow:
- Has a **scope** (User, Business Unit, Parent: Child BU, Organization).
- Runs as **synchronous** (real-time, in the same transaction) or **asynchronous** (queued for background execution).
- Contains a sequence of **steps** — actions to take.
**Available step types.**
- **Create Record** — generate a new record (e.g. create a follow-up activity when a case is created).
- **Update Record** — modify the current or related record.
- **Send Email** — generate an email using a template.
- **Start Child Workflow** — recursive composition.
- **Assign Record** — change ownership.
- **Change Status** — modify status / status reason.
- **Wait Condition** — pause until a condition is met (asynchronous workflows only).
- **Conditional branches** — if-then-else logic.
## Designed in the Process Designer
The visual designer (originally for Dynamics CRM, evolved into the modern process designer in the maker portal) provides drag-and-drop construction. Each step is configured with field-bound expressions and conditions.
**Common historical use cases.**
- **Welcome email** when a lead is created.
- **Auto-assign cases** to queue based on attributes.
- **Status change cascades** — opportunity won → create a follow-up task.
- **Field defaulting** beyond what business rules support.
- **Inactivity timers** — escalate cases after N hours.
Many of these patterns still work; many have migrated to Power Automate equivalents.
**Why Power Automate has superseded most classic workflow.**
- **Connector library** — Power Automate connects to hundreds of external services; classic workflow is Dataverse-internal.
- **Visual designer** — Power Automate's designer is more modern and approachable.
- **Versioning and ALM** — Power Automate flows live in solutions and version cleanly.
- **Error handling** — Power Automate has better retry, error, and parallel branch handling.
- **Monitoring** — Power Automate run history is rich; classic workflow logs are basic.
- **Microsoft strategic direction** — investment is in Power Automate; classic workflow is in maintenance.
**Where classic workflow still matters.**
- **Synchronous in-transaction logic** — classic synchronous workflows run *inside* the Dataverse transaction. Power Automate flows run asynchronously after the transaction commits. For logic that must succeed-or-fail with the originating operation, classic synchronous workflows have an advantage.
- **Legacy customisations** — existing workflows that work fine; migration cost may not be worth the benefit.
- **Some standard Dynamics 365 features** still implement internal logic as classic workflows (e.g. some Quote → Order conversion patterns).
- **Real-time field updates** — quick synchronous workflow updates can be more performant than Power Automate at very high volume.
## Migrating from classic to Power Automate
Microsoft provides migration tooling — point at a classic workflow, generate a Power Automate flow template that approximates the same behaviour. Often requires manual refinement. Migration patterns:
- Simple "on create, do X" workflows → straightforward Power Automate trigger flow.
- Workflows with wait conditions → Power Automate flows with delay actions.
- Multi-stage workflows → Power Automate with multiple steps.
For workflows that mix simple logic with classic-workflow-specific behaviour (synchronous in-transaction needs), the migration to Power Automate may not preserve semantics — careful review needed.
## Inventory existing classic workflows
Before migration:
- List every active classic workflow in the environment.
- Document its purpose, trigger, scope, status.
- Assess: is it still needed? Can it be retired? Should it migrate?
- Plan migration over time — don't try to migrate all at once.
**Common pitfalls.**
- **Migration assumed automatic** — the tooling produces a starting point, not a finished migration. Validate behaviour.
- **Forgetting that classic workflows aren't being invested in** — building new classic workflows when Power Automate would serve better.
- **Synchronous vs async confusion** — replacing synchronous classic workflow with async Power Automate changes transaction semantics.
## Operational reality
For new functionality, default to Power Automate. For legacy classic workflows, retire when convenient; don't force a fragile migration. The two coexist cleanly; gradual modernisation is the practical path.
---
# Process mining in Power Automate
How Power Automate Process Mining analyses real process data to discover process variants, identify bottlenecks, and recommend automation — what it does.
Source: https://www.solvingdynamics365.com/guides/process-mining-in-power-automate
Section: Foundations
Published: 2026-05-01
Power Automate Process Mining (originally acquired as Minit, now an integrated capability) analyses **event logs** from business systems to reconstruct what processes actually do — not what the documentation says they do, not what stakeholders believe they do, but what happens in practice. The output is a quantified map of process variants, durations, and exception paths, with automation recommendations.
## The core idea
Every business process leaves a trail of events in source systems — "order created", "approval granted", "invoice posted", "payment received". Stitching these events together by a common case ID (order number, invoice number) reveals the actual flow: how long each step takes, which variants are common, where rework happens, where SLAs miss.
## Input data — the event log
The minimum:
- **Case ID** — the entity being tracked (order, ticket, invoice).
- **Activity name** — what happened.
- **Timestamp** — when.
Optional but valuable:
- **Resource** — who did it (user or team).
- **Cost** — financial impact.
- **Outcome** — final status.
- **Attributes** — customer type, region, amount, anything segmentable.
The event log is the artefact process mining consumes. Building it cleanly from source systems is the bulk of the work.
**Data sources.**
- **Dynamics 365 / Dataverse** — out-of-the-box connectors pull activity records.
- **SQL Server / databases** — query historical event tables.
- **SAP, Salesforce** — via connectors or extracted exports.
- **Custom systems** — CSV upload or custom connector.
- **Process desktop activity** — process advisor recording desktop UI events.
**What process mining produces.**
- **Process map** — a directed graph of activities with frequencies and durations on edges.
- **Variants** — every unique path taken; ranked by frequency.
- **Bottlenecks** — activities or transitions with long wait times.
- **Rework loops** — activities that occur multiple times per case.
- **Compliance deviations** — paths violating expected process rules.
- **Filtering and drill-down** — slice by attribute (region, customer segment, time period).
## Variants
Real processes diverge into dozens or hundreds of variants:
- **Variant 1 (60% of cases)** — happy path, all steps in order.
- **Variant 2 (15%)** — manual exception handling.
- **Variant 3 (5%)** — rework loop.
- **Long tail** — hundreds of low-frequency variants with idiosyncratic paths.
Quantifying variants reveals where standardisation could yield large gains.
## Automation recommendations
Process Mining identifies activities suitable for automation:
- **High-frequency manual activities** — automation impact is volume × per-instance time saving.
- **Repetitive rework loops** — pre-validation could eliminate.
- **Approval bottlenecks** — automated routing or AI-based pre-decisioning.
Recommendations link directly to Power Automate templates — the AI suggests a flow to start with.
## Process Advisor — desktop process recording
A complementary capability: a recording agent on a user's desktop captures clicks, keystrokes, and screen events. Multiple recordings cluster into a "as-is" desktop process, ready for RPA automation. Useful for processes whose digital footprint isn't in events but in user actions.
**Use cases where process mining wins.**
- **AP processes** — invoice arrival to payment, where rework and exceptions cost real money.
- **Order to cash** — quote to invoice cycle time analysis.
- **Customer service tickets** — resolution time, escalation patterns.
- **Loan applications** — approval bottleneck analysis.
- **Manufacturing** — order to ship cycle decomposition.
**Use cases where it doesn't fit well.**
- **Processes with poor event capture** — manual processes without timestamps in systems.
- **Highly variable creative work** — no repeating pattern to mine.
- **Strategic processes** — board decisions, M&A; the value is in judgement, not flow.
## The hard part — data preparation
Getting clean event data is 70%+ of a process mining project:
- **Identifying the case ID** across systems.
- **Reconciling activity names** — "Invoice Received" in one system, "Invoice Captured" in another, same event.
- **Filtering noise** — system events, not business events.
- **Handling missing timestamps** — gaps in event capture.
- **Volume management** — millions of events per process.
Underestimating this is the most common project failure mode.
## Compliance and conformance checking
Beyond exploration, process mining can check whether actual paths conform to a defined reference model. Deviations are quantified — useful for regulatory processes where prescribed sequence matters.
**Common pitfalls.**
- **Boil-the-ocean scope.** Trying to mine every process at once. Start with one high-impact, well-instrumented process; demonstrate value; expand.
- **Ignoring the data preparation cost.** Sponsors expect insights in days; reality is weeks of data work first.
- **Action follows insight, but slowly.** Mining reveals problems; fixing them requires process redesign and change management.
- **Variants over-aggregated or under-aggregated.** Too aggregated, you miss patterns; too disaggregated, the long tail is noise. Tune.
- **Privacy.** Event logs include user IDs — process mining requires DPIA in regulated industries.
## Operational guidance
Process mining is a powerful diagnostic tool; treat it as a continuous capability, not a one-time project. Mine, fix, mine again. The teams that get value embed mining into their continuous improvement cadence and tie insights to specific automation, process redesign, or training actions.
---
# Procurement transparency for public sector on Dynamics 365 Finance
How public bodies run transparent, auditable procurement on Dynamics 365 Finance and Supply Chain Management — purchasing policies and thresholds.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-for-public-sector-procurement-transparency
Section: Industries / Public sector
Published: 2026-09-02
Public procurement has one requirement commercial procurement does not: it must be seen to be fair. Thresholds decide which procedure applies, competing bids must be evaluated against published criteria, the decision must be documented, and the spend must be reportable — to auditors, to elected members, and under freedom-of-information regimes to anyone who asks. Dynamics 365 Finance and Supply Chain Management provides the workflow, policy, and audit machinery; the tendering portal and the statutory notices remain outside it. This guide walks the procurement cycle from a transparency standpoint. For fund accounting, budget control, and encumbrance, see [public sector features](https://www.solvingdynamics365.com/guides/dynamics-365-public-sector-features).
## Policies encode the rules
**Purchasing policies** are the mechanism for turning procurement regulations into system behaviour. Policy rules are assigned to organisation hierarchies — a legal entity, a department, a fund — and cover:
- **Requisition control**: who may raise requisitions, for which categories, and whether a catalogue item is required.
- **Purchase order creation and consolidation**: whether requisitions become orders automatically or wait for a buyer.
- **RFQ requirements**: the rule that requisitions above a threshold amount must go through a request for quotation before an order can be raised. This is the rule that implements "three quotes above this value" and "formal tender above that value".
- **Purchase agreement application**: lines must draw down from an existing framework agreement where one exists for the category.
- **Category access**: which procurement categories each part of the organisation may buy from.
Set the thresholds to match the regulation, tie them to the organisation hierarchy that mirrors delegated authority, and review them when the regulation changes. The policy is the documented control; auditors can read it directly.
## Requisition to approval
Purchase requisitions with workflow are the entry point for controlled spend. The workflow routes by amount, category, and organisation — through a line manager, a budget holder, and above a threshold a procurement officer — with the [purchase requisitions and approvals](https://www.solvingdynamics365.com/guides/purchase-requisitions-and-approvals-in-f-and-o) guide covering the configuration. Budget control checks the fund at submission and reserves it as a pre-encumbrance, so that a requisition cannot proceed against an exhausted budget; the [budget control](https://www.solvingdynamics365.com/guides/budget-control-in-f-and-o) guide covers the mechanics.
The transparency value is the workflow history: who approved what, when, with what comment, held on the requisition and reportable. A requisition approved outside the system — an email chain and a manually raised order — has no such history, and the policy should make that path impossible rather than merely discouraged.
## Requests for quotation and scored bids
For competitive procedures, the **request for quotation** (RFQ) is the in-product mechanism. An RFQ is issued to selected vendors or opened for response, vendors reply with prices and delivery, and the replies are compared. Two features carry the fairness burden:
- **Vendor collaboration** lets vendors see the RFQ and submit their bid through the portal, with a timestamp, rather than by email to a buyer. The [vendor collaboration](https://www.solvingdynamics365.com/guides/vendor-collaboration-in-f-and-o) guide covers the setup. Sealed-bid behaviour — nobody sees replies until the deadline — is a process control on top of it, not a lock in the product.
- **Scoring criteria** on the RFQ let evaluators rate each bid against weighted criteria — price, quality, delivery, sustainability — with the scores recorded per evaluator and per reply. The award recommendation is then a documented calculation, not a buyer's preference. Configure the criteria before the RFQ is issued; adding them afterwards is exactly what a losing bidder's challenge will point to.
The RFQ, replies, scores, and award create a complete record of the competition. What the RFQ does not do is publish the notice in the official journal, run a full e-tendering procedure with clarifications and standstill periods, or handle the structured questionnaires that formal tenders require. Public bodies use their jurisdiction's e-tendering platform for that, and the F&O RFQ either mirrors the result or is skipped for formal tenders, with the award recorded directly as a purchase agreement.
## Framework agreements
Public bodies buy most routine goods and services under frameworks. **Purchase agreements** model them: a vendor, a validity period, committed quantities or values by category or item, prices, and release orders drawn against them. Policy can require that lines in a category use the framework, and consumption against the agreement is visible, which is what a compliance review checks first. The [sales and purchase agreements](https://www.solvingdynamics365.com/guides/sales-and-purchase-agreements-in-f-and-o) guide covers the mechanics.
## The audit trail
Every document in the cycle carries its workflow history, its change history where database logging is enabled, and its posting trail. For public bodies the additional habits are enabling the **database log** on vendor bank details and vendor master changes (the classic fraud vector), keeping document attachments — the specification, the evaluation report, the conflict-of-interest declarations — on the RFQ or agreement rather than in a shared drive, and retaining procurement records for the statutory period. Financial reporting and Power BI over the purchasing tables give auditors and members the spend by vendor, category, and procedure.
## Publishing spend
Many jurisdictions require publication of spend above a threshold, contracts awarded, and supplier lists. The data is in F&O; the publication is a scheduled export. Azure Synapse Link or the data lake export feeds a reporting layer from which the open-data file or the transparency report is produced with the required fields and redactions; the [data lake export](https://www.solvingdynamics365.com/guides/data-lake-export-for-dynamics-365-finance) guide covers the plumbing. Do not build the transparency report as a direct query against production.
## Where Business Central fits
Smaller public bodies — parish and town councils, arm's-length bodies, schools trusts — run **Business Central**, which has purchase quotes, approval workflows by amount, and dimensions for fund and cost centre, but no purchasing policies, no RFQ with scoring, and lighter budget control. It is adequate where the procurement regulation is simple and the formal tenders run on the national portal anyway. The transparency burden is then met by the approval workflow history and a spend export, and the bid evaluation record lives with the portal.
## The gap to name early
The product provides the controlled process and the evidence. It does not know the regulation — the thresholds, the standstill periods, the publication obligations — and the implementation must encode them in policy, workflow, and procedure. Procurement teams should own that configuration alongside finance, because the first time a threshold changes and the policy does not, the audit finding will be theirs.
---
# Production scheduling in Dynamics 365 Supply Chain
How scheduling works in Dynamics 365 SCM — operations vs job scheduling, finite vs infinite capacity.
Source: https://www.solvingdynamics365.com/guides/production-scheduling-in-f-and-o
Section: Finance & SCM / Manufacturing
Published: 2026-05-01
Production scheduling in Dynamics 365 Supply Chain Management has more dials than any other module. The scheduling decisions made at implementation determine whether the system supports the planner's job or fights it every day.
**Two scheduling layers.**
- **Master planning** — high-level material and capacity plans across the planning horizon. Driven by **Planning Optimization** (the modern engine that replaced the legacy MRP). Outputs planned production orders sized to match demand and constrained by lead times.
- **Production scheduling** — the operation-level sequencing of work on specific work centres, with start times, end times, and resource allocations. This is the planner's daily working surface.
## Operations vs job scheduling
When a production order is firmed and released, it can be scheduled in two granularities:
- **Operations scheduling** — schedules each routing operation as a whole, with single start and end times. Faster, less granular. Suitable when the work centre capacity is the main concern and within-operation sequencing isn't critical.
- **Job scheduling** — schedules each job (a single occurrence of an operation on a specific work centre) at the lowest level, with full precedence and sequencing. Slower to compute, much more accurate. Required for any scenario where minute-level sequencing matters (e.g. tight changeovers between SKUs).
**Finite vs infinite capacity.**
- **Infinite capacity** — the scheduler ignores work-centre capacity limits. Useful for planning what *should* happen given demand; less useful for committing to delivery dates.
- **Finite capacity** — the scheduler respects work-centre calendars and existing load. Operations that can't fit get pushed out. Required to produce realistic delivery dates.
Most production environments switch on finite capacity from day one; the trick is configuring the calendars and capacities accurately.
## Forward vs backward scheduling
A production order can be:
- **Forward scheduled** from a start date — operations begin at the start date and run forward; the finish date is computed.
- **Backward scheduled** from a finish date — operations are scheduled to end on the finish date; the start date is computed.
The choice depends on the business need. Make-to-stock production with no specific delivery date forward-schedules from earliest start. Make-to-order with a customer delivery date backward-schedules from the required ship date.
## The Gantt chart
F&O's production scheduling Gantt chart visualises operations across work centres and time. Planners drag operations to reschedule, hold operations to free capacity, and assess load by work centre. The Gantt is functional but not as polished as dedicated APS (Advanced Planning and Scheduling) tools.
## Constraints not covered
Out of the box, F&O's scheduler handles work-centre capacity, calendars, and operation duration. It does *not* natively handle:
- **Material constraints** — the scheduler assumes material will be available. Real shortages aren't reflected automatically.
- **Sequence-dependent setup times** — switching from product A to product B vs A to C may take different setup times; the standard engine doesn't model this.
- **Tooling and labour constraints** as independent resources.
- **Campaigning** — running batches of similar SKUs together to minimise changeovers.
For these, customers add **partner APS solutions** (Asprova, PlanetTogether, Preactor, Simio) that integrate to F&O.
## Master scheduling cadence
Most operations run a regenerative or net-change plan nightly; finite scheduling of the planning horizon runs in the morning. The shop-floor sees a stable, realistic plan when they start work.
## Where ROI compounds
Finite, accurate scheduling moves on-time delivery from "we missed several this week" to "we hit them" — and the difference compounds in customer relationships and inventory cost.
---
# Project governance for Dynamics 365 implementations
How to structure governance for a Dynamics 365 project — steering committee, project management office, decision rights.
Source: https://www.solvingdynamics365.com/guides/project-governance-for-dynamics-365
Section: Implementation / Project execution
Published: 2026-05-01
A Dynamics 365 implementation involves dozens of decisions per week — scope changes, technical trade-offs, resource priorities, vendor management. **Project governance** is the structure that ensures these decisions happen at the right level, by the right people, with the right input. Done well, governance keeps the project moving; done badly, it becomes bottleneck or rubber-stamp.
**Why governance matters.**
- **Decision velocity** — projects without governance suffer slow decisions or wrong-level decisions.
- **Accountability** — clear who decides what.
- **Risk management** — issues surfaced and addressed.
- **Stakeholder alignment** — common direction.
- **Audit trail** — what was decided and why.
For multi-million-dollar implementations, governance is essential, not optional.
**Governance bodies.**
- **Steering Committee** — strategic; meets monthly typically.
- **Project Management Office (PMO)** — operational coordination.
- **Working groups** — domain-specific (Finance, Sales, etc.).
- **Technical advisory** — architecture decisions.
Each has scope and authority.
**Steering Committee composition.**
- **Executive sponsor** — typically C-level or senior VP.
- **Business leads** per major function.
- **CIO / IT leader.**
- **Partner / vendor lead.**
- **Project sponsor** from customer side.
5-8 people typically; larger becomes ineffective.
**Steering Committee responsibilities.**
- Approve major scope changes.
- Resolve cross-functional conflicts.
- Approve budget increases.
- Make go / no-go decisions at milestones.
- Address escalated risks.
- Provide strategic direction.
Doesn't manage day-to-day; sets direction and resolves stuck issues.
**Meeting cadence.**
- **Monthly** standard.
- **Weekly** during critical phases (pre-go-live, cutover).
- **Ad-hoc** for urgent issues.
Cadence calibrates to project phase.
**Standard steering committee agenda.**
- Status dashboard.
- Risks and issues.
- Decisions required.
- Scope change requests.
- Budget and timeline.
- Quality metrics.
- Next phase preview.
Time-boxed; not everything every meeting.
**Project Management Office (PMO).**
- Day-to-day coordination.
- Status tracking.
- Risk and issue logs.
- Communications.
- Documentation management.
- Vendor coordination.
For larger projects, dedicated PM; for smaller, part-time PM.
**Working groups.**
- Per business function (Finance, Sales, Operations, IT).
- Subject matter experts.
- Weekly typically.
- Detail-level decisions in domain.
Working groups make most decisions; steering only sees what gets escalated.
**Decision rights.**
- **RACI matrix** — Responsible, Accountable, Consulted, Informed per decision type.
- **Documented decision authority** — what level decides what.
- **Escalation triggers** — when does a decision move up?
Without clear authority, decisions stall or get made at wrong level.
**Common decision types.**
- **Scope inclusion / exclusion.**
- **Customisation vs standard.**
- **Architecture choices.**
- **Vendor performance issues.**
- **Resource changes.**
- **Schedule changes.**
- **Budget changes.**
Each should have defined authority.
**Risk management.**
- **Risk register** maintained.
- **Per risk**: probability, impact, mitigation, owner.
- **Review cadence** — weekly in PMO, monthly in steering.
- **Top risks elevated** — focus attention on highest impact.
Active risk management is a leading indicator of project health.
**Issue management.**
- **Issue log** — known problems requiring action.
- **Per issue**: description, impact, target resolution, owner.
- **Escalation** path defined.
Stuck issues elevated to higher levels.
**Communication.**
- **Status reports** — weekly or biweekly.
- **Stakeholder updates** — periodic to broader audience.
- **All-hands** — milestone communications.
- **Issue alerts** — ad-hoc on critical events.
Communication discipline keeps stakeholders engaged.
## Status reporting
A typical weekly status:
- **Highlights** — what's progressing well.
- **Lowlights / risks** — what's concerning.
- **Decisions needed.**
- **Forecast** — on/off track per milestone.
- **Quality metrics** — defects, performance.
- **Next week's focus.**
Concise, honest reporting; over-rosy reports lose credibility.
**RACI matrix example.**
| Decision | Customer Lead | Project Mgr | Steering | Partner |
|---|---|---|---|---|
| Customisation request | R | A | C (if material) | C |
| Vendor change | I | R | A | I |
| Scope expansion | C | R | A | C |
| Technical architecture | C | R | I | A |
| Go-live date | C | R | A | C |
R = Responsible, A = Accountable, C = Consulted, I = Informed.
Clear up front; reduces ambiguity.
**Quality metrics.**
- **Defect count** — by severity.
- **Test pass rate** — current cycle.
- **User acceptance status** — UAT progress.
- **Customisation count** — vs plan.
- **Burn rate** — actual vs budget.
Quantitative metrics drive objective decisions.
**Vendor management.**
- **Performance against SOW.**
- **Quality of deliverables.**
- **Team engagement.**
- **Issue resolution speed.**
Periodic vendor performance review; address issues early.
**Change control.**
- **Formal change request process.**
- **Impact analysis** per change.
- **Approval at appropriate level.**
- **Documentation updated.**
Without change control, scope drifts; with too much, every minor adjustment becomes process.
**Common pitfalls.**
- **Governance theatre.** Meetings happen; decisions don't.
- **Decisions at wrong level.** Steering deciding details; working groups stuck on strategy.
- **Slow decisions.** Bottlenecks build.
- **No escalation discipline.** Stuck issues never elevated.
- **Status reporting sugar-coats.** Steering surprised by go-live problems.
- **Sponsor disengaged.** Project lacks executive air cover.
**Phased governance evolution.**
- **Discovery** — lighter governance.
- **Design / Build** — full governance.
- **UAT / Cutover** — intensified.
- **Hypercare** — adjusted focus.
- **Operations** — transition to standard ops governance.
Governance shape evolves with project phase.
## Strategic positioning
Governance is what turns a complex project into a manageable one. The structure isn't intrinsically valuable; the discipline of using it is. Mature implementations have governance that produces decisions, surfaces risks, and aligns stakeholders.
For project sponsors:
- Design governance early.
- Ensure decision authority is clear.
- Maintain meeting discipline.
- Use the structure; don't go around it.
- Adjust as the project evolves.
The cost is meeting time; the benefit is on-track delivery, fewer surprises, and informed stakeholders. Underinvested governance leads to project drift; overinvested becomes bureaucratic friction. The right level is enough to coordinate but not so much it becomes the work.
---
# Project Operations deployment types
How Project Operations comes in three deployment shapes — Lite, Resource & Non-Stocked, and Finance — what differs between them.
Source: https://www.solvingdynamics365.com/guides/project-operations-deployment-types
Section: Customer Engagement / Project Operations
Published: 2026-05-01
**Dynamics 365 Project Operations** is offered in three distinct deployment types, each targeting a different project services scenario. They aren't interchangeable — picking the wrong one means rebuilding later. Understanding the three at the start of any project-services Dynamics initiative saves significant time and licence churn.
**The three deployments.**
- **Project Operations — Lite (PO Lite)** — for opportunity-to-cash on Dataverse only.
- **Project Operations — Resource and Non-Stocked / Production-Based** — for organisations needing tighter integration with Finance & Operations.
- **Project Operations — Finance and Operations Integrated** — for organisations on F&O with full ERP-grade project management.
The naming has shifted over recent waves; current branding emphasises the underlying scenarios rather than the deployment names directly. Microsoft documents the three shapes consistently.
## PO Lite — Dataverse only
Best for:
- Smaller professional services firms.
- Project-centric work without complex ERP needs.
- Organisations on the CE-side of Dynamics 365 (Sales, Customer Service).
- Time-tracking, project billing, basic revenue recognition.
What it offers:
- Project planning (tasks, schedule, resources).
- Time and expense entry.
- Project quotes and contracts.
- Invoicing via sales orders or directly.
- Basic revenue and cost reporting.
What it doesn't offer:
- Deep inventory integration.
- Complex revenue recognition standards (ASC 606 multi-element).
- Advanced manufacturing-style WIP and cost accounting.
- Multi-currency consolidation at scale.
Licensing: priced per user; Dataverse-only deployment cheaper and simpler.
## Resource and Non-Stocked-Based
Best for:
- Mid-market and enterprise services firms.
- Organisations needing F&O for finance but project management on the CE side.
- Hybrid scenarios where parts of operations are on F&O.
Architecture:
- Project, resource, time entry on Dataverse (CE side).
- Project accounting, revenue recognition, billing on F&O.
- Dual-write integration syncs between.
The advantage: front-line teams use a CE-style modern UX while finance gets F&O-grade accounting. The cost: integration complexity; dual-write maintenance.
## F&O Integrated (full ERP)
Best for:
- Large project-driven manufacturers.
- Engineer-to-order, build-to-order businesses.
- Organisations on F&O for everything; want projects integrated into the broader ERP.
Architecture:
- Project module within F&O itself.
- Full integration with inventory, production, procurement.
- Project ledger, cost categories, WIP, revenue recognition all in F&O's project sub-ledger.
Capabilities:
- Manufacturing projects (the project consumes BOMs and produces output).
- Construction-style projects (long-lead, milestone-based).
- Government contracting (DCAA / FAR compliance).
- Multi-LE projects (entities collaborating on one project).
This is the heaviest deployment but the most capable for complex scenarios.
**Picking between them.**
- **Pure services with simple needs** → PO Lite.
- **Services with F&O finance integration** → Resource and Non-Stocked.
- **Manufacturing or complex projects on F&O** → F&O Integrated.
If unsure, lean toward the lighter option — upgrading is non-trivial, but starting too heavy is operational overkill.
## Migration between deployments
A common scenario: company starts with PO Lite, grows, decides to integrate with F&O. Migration is possible but involves:
- Re-platforming project schedules.
- Re-establishing financials in F&O.
- Re-training teams.
- Data conversion.
Plan months for a real migration, not weeks. The decision to deploy on the right type from the start saves significant cost later.
**Common cross-deployment concepts.**
- **Project** — the core entity.
- **Project task / WBS** — work breakdown structure.
- **Project resource** — people assigned to the project.
- **Time entry / expense entry** — actuals.
- **Project contract** — billing arrangement (fixed-price, T&M, milestone).
- **Project invoice** — billing to customer.
- **Project actuals** — committed costs and revenue.
These exist in all three but vary in depth.
## Resource scheduling
All deployments include resource scheduling:
- **Resource Scheduling Optimization (RSO)** — ML-driven resource matching.
- **Schedule board** — manual assignment.
- **Resource fulfillment** — bookings on the project.
Field Service and Project Operations share scheduling infrastructure; an organisation running both gets unified scheduling.
## Time entry
Universal pattern:
- Resource enters time against project / task daily or weekly.
- Manager approves.
- Time posts to project actuals — flowing to billing and revenue recognition.
PO Lite has a simpler time entry surface; F&O Integrated has additional time entry features (multiple time categories, regulatory timekeeping).
**Common pitfalls.**
- **Wrong deployment chosen at start.** Cost of correction high.
- **Integration complexity underestimated.** Dual-write reliability work is real ops effort.
- **Configuration sprawl.** Every customer's slightly different; managing varied configs across many customers is heavy for partners.
- **Licensing confusion.** Three deployments → multiple SKUs and add-ons; getting licensing right takes specialist help.
- **Roadmap misalignment.** Some features land in one deployment before others; planning around current capability matters.
## Strategic positioning
Microsoft's investment is across all three, but the most innovation lands in the integrated deployments (Resource/Non-Stocked and F&O). PO Lite remains supported for the simpler scenarios but doesn't always get newest features first.
Choose deployment based on actual business needs, not aspirations. Start lighter, upgrade only with concrete evidence of need. The deployment choice is one of the biggest decisions in any Project Operations project — give it the analysis it deserves.
---
# Projects in Business Central
How Business Central handles project accounting, resourcing, time, and billing — and when to step up to Project Operations.
Source: https://www.solvingdynamics365.com/guides/business-central-projects
Section: Business Central / Service & projects
Published: 2026-05-01
Updated: 2026-08-31
Business Central's project module (called **Jobs** in older versions; **Projects** in newer ones) is built for services-led businesses that need to track time and cost against engagements and bill customers from them. It is genuinely capable for SMB consulting, agency, light professional services, installation, and field-work organisations — and stops short of being a full PSA (professional services automation) suite.
## Projects and tasks
A **project** belongs to a customer and contains a hierarchy of **project tasks**. Each task has a budget and a billable plan. Tasks roll up into the project for profitability and WIP reporting.
## Planning lines
Within a task, **planning lines** describe what is budgeted, billable, or both: hours of a resource at a sell rate, items consumed at cost, GL expenses. Planning is in three flavours — *Budget* (cost only), *Billable* (revenue only), or *Both* (combined). This separation makes it easy to model fixed-price work, time-and-materials, and capped engagements.
## Resources and time
Resources (people or equipment) have unit costs and price lists. **Time sheets** let users enter hours by week against projects and tasks, which then post to job journals. Resource availability and basic capacity planning are included.
## Posting and WIP
As resources consume time and items are issued to a project, **job ledger entries** record cost and the WIP module can defer those costs to the balance sheet via WIP journals, recognised as revenue and COGS on completion or percentage-of-completion.
## Billing
**Job Sales Invoices** are created from billable lines, in advance or in arrears, with milestone schedules, retainers, and progress billing all supported.
## WIP methods — the decision that bites later
The WIP setup is where project accounting projects go wrong, because the method chosen at implementation determines how revenue and cost hit the P&L for every project afterwards. BC ships several **WIP methods** — completed contract (nothing to P&L until the project closes), cost value, sales value, percentage of completion, and cost of sales — and the right one is an accounting-policy decision, not a system preference. Two practical warnings. First, the WIP calculation is only as good as the **budget** (percentage-of-completion divides actuals by budget, so an unmaintained budget produces confidently wrong revenue recognition). Second, WIP calculation and WIP posting are separate, deliberate steps — run monthly, reviewed by someone who understands the numbers, not automated into the dark. The mechanics get their own guide in [WIP and recognition for jobs in BC](https://www.solvingdynamics365.com/guides/wip-and-recognition-for-jobs-in-bc), and the terminology in the [WIP glossary entry](https://www.solvingdynamics365.com/glossary/wip).
## Purchasing against projects
Cost doesn't only arrive through time sheets. Purchase order and purchase invoice lines carry project and task fields, so subcontractor invoices, materials, and expenses post straight onto the project as job ledger entries. This is also the discipline point: costs booked to a plain G/L account without the project reference simply vanish from project profitability, and no report finds them later. Make the project field effectively mandatory for project-driven purchase categories, and review "project-less" cost postings weekly during the first months.
## Making it work in practice
- **Time discipline is the whole game.** Project profitability in BC is a report over job ledger entries; if consultants book hours weekly-ish and generously round, every downstream number is fiction. Weekly time sheet approval with a named approver is a process decision that matters more than any configuration.
- **Model engagement types deliberately.** Fixed-price work: budget lines as *Budget*, invoicing via *Billable* milestone lines. T&M: *Both*, so every posted hour creates a billable line. Mixing the patterns on one task produces double-billing or unbilled work.
- **Keep the task structure shallow.** Two or three levels. A task hierarchy mirroring a 200-line project plan makes time entry a treasure hunt and guarantees miscoded hours.
- **Invoice from the system.** Creating invoices in Word "because the layout is nicer" breaks the link between billed and posted amounts. Fix the [document layout](https://www.solvingdynamics365.com/guides/document-layouts-and-report-design-in-business-central) instead.
## Limits — and when Project Operations earns its cost
Resource-level utilisation reporting, formal resource scheduling boards, and complex pricing/billing rules (multi-currency milestone with retention, for example) are basic. Companies that need full PSA — opportunity-to-cash for services with resourcing, scheduling, and complex billing — typically move to **Project Operations**, which is a separate Dynamics 365 app that integrates back to BC or Finance.
The honest dividing line: if projects are *what you sell* and the pain is in winning, staffing, and scheduling them — sales pipeline for engagements, bench management, skills-based resourcing — BC's module was never meant to solve that, and [Project Operations](https://www.solvingdynamics365.com/guides/what-is-dynamics-365-project-operations) is the answer. If projects are how you *account* for delivery and the pain is cost capture, WIP, and billing, BC's module is enough and considerably cheaper. Moving up for prettier Gantt charts alone is an expensive way to buy a picture; the comparison is walked through in [BC jobs vs Project Operations](https://www.solvingdynamics365.com/guides/business-central-jobs-vs-projects).
---
# Public sector features in Dynamics 365
How Dynamics 365 Finance supports public-sector accounting — fund accounting, budget control, encumbrance, grants, and compliance.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-public-sector-features
Section: Finance & SCM / Public sector
Published: 2026-05-01
Dynamics 365 Finance ships a **Public Sector** feature set that turns the standard ERP into a government-grade fund-accounting system. Public-sector finance is fundamentally different from commercial finance — fund-balance accounting, mandatory budget control, encumbrance, and stricter audit — and these features are how F&O reaches that bar.
## Fund accounting
Public bodies don't run a single P&L; they account by **fund**, where each fund is a self-balancing set of accounts representing a programme, grant, or restricted purpose. Public Sector mode adds **derived financial hierarchies** that classify GL postings by fund, function, programme, and other public-finance dimensions, with intra-fund balance enforcement.
## Budget control
General Public Sector users run **budget control** in *hard-stop* mode — a transaction that would exceed its budget line is blocked at entry, not warned. Budget control checks happen at multiple points (requisition, purchase order, invoice) with configurable rules. Funds are released and consumed throughout the year and reconciled at period-end.
## Encumbrance and pre-encumbrance
When a purchase requisition is approved, F&O posts a **pre-encumbrance** against the budget — money set aside but not yet committed. When the requisition becomes a purchase order, the pre-encumbrance converts to an **encumbrance**. When the vendor invoice arrives, the encumbrance is relieved and an actual expense posts. This three-stage commitment accounting is mandatory in most public-sector environments.
## Grants management
Awards, sub-awards, billing schedules, and grant-specific budget tracking. Costs incurred against a grant can be allocated and billed back to the granting authority through standard or custom rules.
## Year-end procedures
Public-sector year-end carries forward open encumbrances, closes the fund balances, and produces the required statutory disclosures. The standard close routines extend with public-sector-specific steps.
## Procurement compliance
Public-sector procurement often requires open competitive bidding, vendor pre-qualification, and audit trails for every step. F&O's Procurement and Sourcing module is the workhorse here, configurable for the bidding rules of the jurisdiction.
## Vendor 1099 (US) and equivalents
Year-end vendor reporting for tax authorities ships standard for the US (1099) with localization variants for other countries.
## Where it fits
Federal, state/provincial, and large municipal governments are the target. Smaller public bodies (small cities, school districts) can run Public Sector but the implementation cost is meaningful — for very small public organisations, Business Central with a fund-accounting ISV add-on is sometimes the more proportionate fit.
---
# Purchase requisitions and approvals in Dynamics 365 Finance
How F&O's purchase requisition workflow handles requesters, approvers, conversion to PO, and the integration with procurement policy and budget control.
Source: https://www.solvingdynamics365.com/guides/purchase-requisitions-and-approvals-in-f-and-o
Section: Finance & SCM / Supply chain & inventory
Published: 2026-06-16
For enterprise organisations, every meaningful spend should start as a **purchase requisition** — a formal request from an employee asking the organisation to commit to buying something. The requisition routes through approval, gets approved (or rejected), and then converts to a purchase order that the procurement team executes. Dynamics 365 Finance handles the full lifecycle.
## The requester experience
An employee identifies a need:
- Buy office supplies.
- Engage a contractor.
- Purchase software licences.
- Order equipment.
- Pay for training.
Through a self-service workflow (often via a Power Apps interface or directly in F&O), the requester:
1. **Creates the requisition** — selects items / services from the catalogue, enters details, attaches supporting documents (quotes, justifications).
2. **Submits** — the workflow engages.
3. **Tracks** the requisition's status as it moves through approval.
4. **Receives notification** when approved (or rejected with reason).
## The approval workflow
F&O's workflow engine routes the requisition:
- **Manager approval** — first line, the requester's direct manager.
- **Budget check** — does the requested amount fit within the cost-centre's available budget?
- **Procurement category approval** — different category-specific approvers (IT requisitions to IT lead, HR requisitions to HR lead).
- **Threshold-based escalation** — over €10,000 requires director; over €50,000 requires VP; over €100,000 requires CFO.
- **Compliance review** — for specific scenarios (contractor engagements need legal review).
The exact routing is configured per organisation; F&O's workflow engine accommodates substantial complexity.
**Approval responses.**
- **Approve** — moves to the next step or, if final, marks requisition approved.
- **Reject** — requester is notified; requisition can be re-submitted with changes.
- **Request change** — the approver asks for modifications before approving.
- **Delegate** — pass to a substitute approver.
- **Recall** — the requester withdraws their request.
Each action is logged with timestamp, comments.
## Budget control integration
For organisations using **budget control** (mandatory in public sector, common in cost-controlled commercial operations):
- The requisition's projected expense reserves budget on submission (pre-encumbrance).
- Approved requisition converts pre-encumbrance to encumbrance.
- The encumbrance commits budget against the cost centre.
If submitting a requisition would exceed available budget, the workflow either blocks (hard-stop) or warns (soft, requires override). Public Sector configurations typically run hard-stop.
## Procurement category management
Spend is classified into **procurement categories** — a hierarchical taxonomy:
- IT > Software > SaaS subscriptions.
- IT > Hardware > Laptops.
- HR > Recruitment > Headhunter fees.
- Marketing > Events > Sponsorships.
Categories drive:
- Approval routing — different categories to different approvers.
- Catalog visibility — what items / services requesters can see.
- Reporting — spend analysis by category.
- Sourcing policy — preferred-vendor rules per category.
## Vendor management
Approved requisitions can be sourced from:
- **Preferred vendors** — pre-qualified with negotiated pricing. Default for many categories.
- **New vendors** — requires vendor onboarding workflow first (financial, compliance, regulatory checks).
- **Punch-out catalogues** — for commodity items, requesters browse external vendor catalogues (Amazon Business, vendor-specific portals) with prices and details flowing back into F&O.
## Conversion to purchase order
Once a requisition is approved, the procurement team:
- **Manually converts** — reviews and creates the PO.
- **Auto-converts** — for low-value, low-risk categories, the system auto-creates the PO without manual intervention.
- **Combines requisitions** — multiple small requisitions for the same vendor can combine into one PO.
The PO becomes the formal commitment to the vendor.
**Procurement controls beyond requisitions.**
- **Three-way matching** — at invoice posting, F&O matches the invoice to the PO and the receipt; mismatches require explicit override.
- **Contract compliance** — POs reference framework contracts; pricing pulls from agreed rates.
- **Receiver reporting** — once goods arrive, they're received against the PO; this triggers accruals.
**Reporting.**
- **Open requisitions** — pending approval per stage.
- **Approved-but-not-converted** — requisitions waiting for procurement.
- **Spend by category** — analytical view of procurement activity.
- **Average approval cycle time** — workflow performance.
- **Off-contract spend** — requisitions sourced outside preferred vendors.
**Common pitfalls.**
- **Approval workflow too complex** — every step requires sign-off; requisitions take weeks.
- **Insufficient category structure** — everything is "Other"; reporting is useless.
- **No conversion automation** — every requisition manually converted; procurement is a bottleneck.
- **Catalogue out of date** — requesters can't find what they need; raise ad-hoc requisitions.
## Operational reality
Mature procurement processes route the bulk of spend through structured requisitions; only true emergencies bypass. The discipline produces visibility, control, and cost savings — usually several percent of total procurement spend.
---
# Quality management in Dynamics 365 SCM
How F&O's quality management module handles inspection plans, quality orders, nonconformance, and the link from quality data to operational decisions.
Source: https://www.solvingdynamics365.com/guides/quality-management-in-f-and-o
Section: Finance & SCM / Supply chain & inventory
Published: 2026-05-01
For regulated industries (food, pharma, medical devices) and quality-sensitive operations (automotive, electronics), F&O's **Quality Management** module captures the inspection and nonconformance workflows that determine whether incoming, in-process, and outbound material can be used. Done right, it ties directly into operational decisions — block, release, rework, scrap.
**Core entities.**
- **Test** — a specific measurement (dimensional, chemical, visual).
- **Test group** — a collection of tests applied together.
- **Quality association** — defines when a quality order is auto-created (e.g. on receipt of items in this group from these vendors).
- **Quality order** — the actual inspection record, with results per test, disposition, and follow-up actions.
- **Nonconformance** — a captured defect with root cause analysis fields and corrective action.
## Quality associations
The auto-creation rules:
- **Event** — Purchase receipt, Production reporting as finished, Inventory transaction, Sales picking, etc.
- **Reference** — item group, item, vendor, customer, or specific products.
- **Sampling plan** — full inspection, percentage, fixed quantity.
- **Test group** — which tests to run.
Quality association rules are the engine that translates "we always inspect first lot from any new vendor" into automatic quality orders without operator decision.
**Sampling plans.**
- **100%** — every unit.
- **Quantity per lot** — fixed sample size.
- **Percentage** — proportional sample.
- **Acceptance sampling (AQL)** — statistical sampling per ISO 2859 or military standards.
The right plan depends on test cost and consequence of escape. Visual checks may be 100%; destructive testing is small samples.
**The inspection workflow.**
1. Quality association fires; quality order is created.
2. The inspected quantity is segregated to a quarantine warehouse or quarantine bin until disposition.
3. Quality engineer runs the tests, records results per test line.
4. The system evaluates pass/fail per test against limits.
5. Overall disposition is set: **Pass**, **Fail**, **Conditional**.
6. Disposition drives next steps: release to stock, return to vendor, rework, scrap.
## Quarantine integration
Items being inspected are typically segregated to a **quarantine warehouse** or **quarantine bin**. Until the quality order is dispositioned, the material is not available for normal operations. The integration is automatic with warehouse-managed receipts: receipt → quarantine, quality order pass → move to normal inventory.
## Nonconformance
A failed quality result, or a problem discovered downstream, generates a **nonconformance**:
- **Problem type** — internal, customer, vendor.
- **Diagnosis** — what was found.
- **Cause** — root cause (5 Whys, fishbone analysis fields).
- **Operations** — corrective actions taken (rework, scrap, return, accept with deviation).
- **Costs** — labour and material costs of the response.
Nonconformance records aggregate into supplier scorecards (vendor X has Y nonconformances/quarter) and trend analysis.
## Corrective and preventive actions (CAPA)
For regulated industries, nonconformance leads to formal CAPA — actions designed to prevent recurrence. F&O has CAPA fields but for FDA-regulated environments, dedicated CAPA software is often layered on top.
## Certificate of analysis (CoA)
Quality results can be printed as a Certificate of Analysis sent to customers with shipments — proof of test results. Configure the report to pull from quality order data, sign off by quality manager, attach to shipping.
## Production integration
In manufacturing:
- **In-process inspections** — quality orders triggered at specific operations.
- **Final inspection** — before reporting production complete.
- **Statistical process control** — measurements tracked over time; trends visible.
## Vendor integration
Quality data informs vendor management:
- **Supplier scorecard** — pass rate, defect rate, response time.
- **Vendor approval status** — restricted, approved, preferred.
- **Inspection level** — first-article inspection for new items, reduced inspection for proven items.
**Common pitfalls.**
- **Quality associations too narrow.** Missing items not covered → inspection skipped.
- **Tests poorly defined.** Vague test descriptions; results inconsistent across inspectors.
- **No quarantine discipline.** Items released to stock before disposition; operational risk.
- **Nonconformance not analysed.** Records accumulate, no trend analysis, no CAPA — quality module becomes paperwork.
- **CoA out of sync with results.** A CoA prepared at receipt sent later doesn't reflect any retests — process must enforce final result on CoA.
## Operational rhythm
Quality data is most valuable when reviewed regularly: weekly nonconformance trends, monthly vendor scorecard reviews, quarterly process capability analysis. The module is a tool for those rhythms — without the rhythm, it's data collection without action.
## When it's not enough
Pharma GxP environments often need eQMS systems (Veeva, MasterControl, Tracewise) layered on top for validated audit trails, electronic signatures, and regulatory submission. F&O integrates with these via APIs.
---
# Quick view and quick create forms in Dataverse
How quick view forms and quick create forms streamline data entry and lookup in Dynamics 365 — design, embedding, and the user-experience impact.
Source: https://www.solvingdynamics365.com/guides/quick-view-and-quick-create-forms
Section: Customer Engagement / Dataverse platform
Published: 2026-05-01
Beyond the main form on a Dataverse record, two specialised form types — **quick view forms** and **quick create forms** — provide compact, focused views for specific UX patterns. Used well, they substantially reduce the user's clicks and form-switching effort.
**Quick view forms.**
A **quick view form** displays read-only data from a *related record* embedded inside the parent form. The classic example: on an Opportunity form, a quick view showing the related Account's address, primary contact, and credit limit — without navigating to the Account.
Each quick view form has:
- **Source table** — what kind of record it shows (Account, Contact, Asset, etc.).
- **Columns shown** — what fields to display.
- **No sections / tabs** — quick views are flat layouts.
Quick views can be **embedded in parent forms** through field-style quick view controls. On the Opportunity form, you add the customer account's quick view; the form designer surfaces it as a panel beneath the lookup. When the lookup changes (different customer selected), the quick view refreshes with the new record's data.
**Common patterns.**
- Account info on Opportunity / Lead / Case forms.
- Contact info on activities.
- Asset info on work orders.
- Product info on quote / order lines.
- User info anywhere relevant.
The pattern saves users from constantly clicking through lookups to read related data.
**Quick create forms.**
A **quick create form** is a slim, inline creation form that appears as an overlay or panel — typically for creating a new record without leaving the current context. Examples:
- "New Contact" quick create from an Account record — minimal fields (name, email, phone), one click to create and link.
- "New Activity" quick create — create a phone call or task without opening the full activity form.
- "New Opportunity" quick create from a Contact — capture the essentials, then optionally open the full form to complete.
A quick create form has:
- **Subset of fields** — only the essentials needed for the create.
- **No sections / tabs** typically — flat layout for speed.
- **Optional auto-link** — if launched from a parent record, can pre-populate the lookup back to the parent.
Quick create dramatically reduces friction for casual record creation. Users can capture notes, contacts, tasks without losing context in what they were doing.
**Configuration.**
- **Per-table** — each Dataverse table can have one quick create form and one or more quick view forms.
- **Enable quick create** — per table, a toggle controls whether the quick create form is available.
- **Form picker** — for tables with multiple quick view forms, the parent-form designer picks which to embed.
**Design principles.**
For **quick view forms**, show only what's relevant in context. Don't replicate the full record; show the 5–8 fields a user looking at the parent needs.
For **quick create forms**, capture the minimum needed for a valid record — name, key relationship fields, mandatory fields. Trust users to open the full form for the rest. The friction tax of unnecessary fields kills quick create's value.
**Limits.**
- **Read-only for quick view** — can't edit related-record fields inline through the quick view. For inline editing of related records, use editable subgrids or in-line editing patterns.
- **No business process flows** in quick create — only the main form supports BPF.
- **Limited form scripting** — quick view forms have minimal JavaScript hooks compared to main forms.
- **Mobile rendering** — both render on mobile, but complex quick views can be cramped on small screens. Test.
## Performance
Each quick view embedded in a parent form is a separate Dataverse query at form load. Pages with many embedded quick views slow down. Audit which ones genuinely add value.
**Common patterns and pitfalls.**
- **Don't embed quick view of grandparent** — Account → Opportunity → Quote. Embedding Account's quick view on the Quote is multi-hop and slow. Replicate the key fields if needed.
- **Quick create blocked by required fields** — too many required fields on the quick create form defeats its purpose. Make only the truly mandatory required.
- **Forgetting to enable quick create** — users complain that "+ New" doesn't open quickly; the toggle is off.
## Operational reality
Quick view and quick create forms are some of the most user-loved features when designed well. Spend deliberate UX time on them per major table; they pay back in adoption.
---
# Quote-to-cash for distributors on Dynamics 365
How the quote-to-cash cycle runs for a wholesale distributor on Dynamics 365 — quoting in the ERP versus in Sales, the pricing stack, credit and margin control.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-for-distributors-quote-to-cash
Section: Industries / Distribution
Published: 2026-09-02
Distributors live on volume, thin margin, and speed. A quote-to-cash process that takes three systems and two re-keys is not a process, it is a cost. Dynamics 365 can run the full cycle inside the ERP — quote, order, credit check, pick, ship, invoice, collect — and the main design question is what, if anything, the CRM app adds. This guide walks the cycle for a wholesale distributor and is blunt about the ISV boundaries. For the multi-warehouse side of fulfilment see [multi-warehouse fulfilment](https://www.solvingdynamics365.com/guides/dynamics-365-for-distributors-multi-warehouse-fulfilment); for the industry overview, [Dynamics 365 for wholesale distribution](https://www.solvingdynamics365.com/guides/dynamics-365-for-wholesale-distribution).
## Where the quote lives
There are two places a quote can be created: the ERP (**Supply Chain Management** sales quotations or **Business Central** sales quotes) and **Dynamics 365 Sales**. Distributors should default to the ERP.
The ERP quote has the real prices, the real stock, the customer's real credit position, and converts to a sales order without integration. A quote in Dynamics 365 Sales has the opportunity, the contact history, and the pipeline, and it converts to a sales order only through Dual-write, a connector, or an integration, all of which have to carry the pricing outcome across. For a distributor doing hundreds of transactional quotes a day, that integration is a liability.
The case for Sales is account management, not quoting: territory planning, opportunity tracking on new-account wins, activity history, and marketing follow-up. Distributors that run Sales successfully use it for the relationship and let the ERP own every priced document. The [wholesale distribution overview](https://www.solvingdynamics365.com/guides/dynamics-365-for-wholesale-distribution) discusses this split.
## The pricing stack
Distribution pricing is where the ERP earns its licence. Supply Chain Management's stack, from the bottom up:
- **Base sales price** on the item.
- **Trade agreements** — price and discount journals by item, item group, or all items, against customer, customer group, or all customers, with quantity breaks, date ranges, and currency. Line discounts, multiline discounts, and total discounts stack according to the discount parameters.
- **Sales agreements** — contractual commitments by quantity or value with a customer, which the [sales and purchase agreements](https://www.solvingdynamics365.com/guides/sales-and-purchase-agreements-in-f-and-o) guide covers.
- **Unified pricing management** — the newer rule-based pricing engine shared with Commerce, which adds price components, margin-based and attribute-based pricing, and a clearer evaluation trace than legacy trade agreements. Distributors implementing today should evaluate it rather than defaulting to trade agreements.
- **Rebates and trade allowances** — accrued off the invoice, covered in [trade allowance and rebates](https://www.solvingdynamics365.com/guides/trade-allowance-and-rebates-in-f-and-o).
Business Central's stack is simpler — the price and discount lists of the new pricing experience, with customer price groups, campaigns, and quantity breaks — and adequate for most SMB distributors.
What neither product does: price optimisation (what *should* the price be for this customer and item given elasticity and competitor data), and guided selling for complex product mixes. Both are ISV territory. A distributor asking for "AI pricing" is asking for an ISV or a data-science project over the ERP's transaction history.
## Margin and credit control at order entry
Two checks belong on the sales line, not in a month-end report:
- **Margin visibility and floors.** Supply Chain Management can show cost and margin on the line and alert on lines below a threshold; enforcing a floor needs a small extension or a workflow. Business Central shows profit on the line and needs an extension to block. Either way, the sales desk should see the margin and someone should own the exceptions.
- **Credit check.** Supply Chain Management's credit management module runs blocking rules at order entry, confirmation, picking, packing slip, or invoice, with a release workflow. It is genuinely good and under-used. The [credit and collections](https://www.solvingdynamics365.com/guides/credit-and-collections-management-in-f-and-o) guide covers it. BC has credit limits with a warning or a block, and the [customer credit limits](https://www.solvingdynamics365.com/guides/customer-credit-limits-and-blocking-in-bc) guide covers the options.
## Confirmation, EDI, and self-service
Large customers send orders by EDI and expect acknowledgements, ASNs, and invoices back the same way. Neither product ships an EDI translator; the pattern is an EDI ISV or a managed EDI service mapped to the sales order and packing slip entities, and the [EDI guide](https://www.solvingdynamics365.com/guides/edi-with-business-central) covers the BC side. The order confirmation, once posted, is the commitment the customer holds you to, so the price and delivery date on it must be final — confirm after credit check and ATP, not before.
For smaller customers, **customer self-service** in Supply Chain Management or a Power Pages portal over BC gives order entry, order status, and invoice copies without a phone call. The [customer self-service](https://www.solvingdynamics365.com/guides/customer-self-service-in-f-and-o) guide describes the first-party option. It is basic; a distributor whose customers expect a B2B web shop with rich search and personalised catalogues is looking at Commerce's B2B storefront or a partner e-commerce platform.
## Fulfilment through invoice
From confirmed order to invoice, the flow is standard: release to warehouse, pick, pack, ship with packing slip or shipment, invoice. The distribution-specific decisions:
- **Invoice timing.** Per shipment, daily per customer, or on a summary schedule. Supply Chain Management's summary update parameters and BC's combine-shipments both handle consolidated invoicing; choose per customer group and stop arguing about it.
- **Charges.** Freight, handling, and small-order surcharges as auto charges on the order rather than manual lines, so they are consistent and tax-correct.
- **Direct delivery** for lines the distributor does not stock, which the [drop-ship patterns](https://www.solvingdynamics365.com/guides/dynamics-365-for-distributors-drop-ship-patterns) guide covers.
## Collections
The cycle ends when cash arrives. Supply Chain Management's collections workspace, aging, collection letters, and interest handle a large ledger; BC's reminders and finance charge memos handle a smaller one. Distributors with thousands of small accounts benefit from customer payment portals and card-on-file, both partner territory. The single highest-impact habit is disputing invoices at line level in the system rather than in email, so that the dispute is visible to the collector, the salesperson, and the customer.
## Measuring it
Quote-to-order conversion, order-to-ship time, invoice accuracy (credit notes as a share of invoices), and days sales outstanding. All four come out of the transaction tables in Power BI; none of them come out of the box as a distributor dashboard. Build the four measures in the first month after go-live and review them weekly; they will show where the re-keying still hides.
---
# RapidStart Services in Business Central
How RapidStart Services accelerates Business Central setup — configuration packages, questionnaires, worksheets.
Source: https://www.solvingdynamics365.com/guides/business-central-rapidstart-services
Section: Business Central / Admin & ops
Published: 2026-05-01
Updated: 2026-08-25
**RapidStart Services** is the setup-acceleration toolkit in Business Central. Designed to make new-tenant configuration faster — through configuration packages, questionnaires, and worksheets — it has been the standard tool for partner implementations since the NAV days. Today, RapidStart coexists with newer tools (PowerShell-based deployment, Power Automate, custom dataflows), but remains useful for specific scenarios.
**The three RapidStart components.**
- **Configuration packages** — export/import of setup data and master data.
- **Configuration questionnaires** — guided question-and-answer for setup decisions.
- **Configuration worksheets** — workflow tracking of setup tasks.
Each serves a different purpose; together they form a configurable setup methodology.
## Configuration packages
A package contains:
- **Tables** to be exported / imported.
- **Filters** on each table (which records).
- **Field selections** per table.
- **Dimensions** — capture related dimension data.
Example workflow:
1. Partner creates package in their master / reference company.
2. Exports as Excel or RapidStart .rapidstart file.
3. Imports into the customer's new company.
4. Reviews and adjusts.
5. Applies to populate setup tables.
For typical setups (chart of accounts, payment terms, units of measure, posting groups), packages turn manual data entry into bulk import.
## Templates
Microsoft ships templates for common scenarios:
- Manufacturing setup.
- Service company setup.
- Retail setup.
Partners build their own templates for industry verticals.
**Questionnaires.**
- A structured list of setup questions.
- Customer answers; answers map to setup values.
- Applied to populate setup tables.
The pattern: "What's your fiscal year start?" → answer → populates Accounting Periods.
In practice, questionnaires are used less often than configuration packages — most setup data is bulk imported rather than answered per field.
**Configuration worksheets.**
- List of configuration tasks.
- Each task tracks status (Not Started, In Progress, Completed).
- Assigned to specific resources (consultants, customer team).
- Tracks dependencies.
It's project management for setup work. Useful for keeping a structured implementation visible.
## Migration packages
A specific RapidStart use case:
- Export master data from old system to Excel.
- Import via configuration package.
- Customer's customers, vendors, items populated.
This is the standard pre-go-live data migration approach for small-to-mid migrations. For large migrations, Data Management Framework (DMF) or custom ETL is preferred.
**Limitations.**
- **Volume** — slow for huge datasets (>100K records).
- **Complex relationships** — multi-table imports with foreign keys require careful sequencing.
- **Validation** — limited; bad data still imports.
- **No incremental updates** — designed for initial population, not ongoing sync.
For these reasons, RapidStart is best suited to:
- Initial setup of configuration tables.
- Small-to-mid master data migrations.
- Standardising setup across multiple customer implementations.
**Modern alternatives.**
- **Power Automate** for ongoing data sync — better for recurring loads.
- **Custom REST API import** — programmatic and scalable.
- **Configuration via AL** — for partner extensions defining setup.
- **Business Central installation code** (`OnInstallApp` event) for extension-specific setup.
**Best practices.**
- **One package per logical domain** — Finance setup, Sales setup, Inventory setup; don't have one giant package.
- **Test packages on a fresh sandbox** before production import.
- **Document package contents** — what's in it, where it came from, what it overrides.
- **Version-control packages** alongside extensions in git.
**Common pitfalls.**
- **Importing wrong data.** Production-data packages imported into new tenant accidentally.
- **Re-importing breaks setup.** Importing a package twice can corrupt data.
- **Sequencing errors.** Importing customers before payment terms exist; FK violations.
- **Manual edits after import.** Customer edits packaged data; next package import overwrites.
- **No reset mechanism.** Mistakes in setup hard to undo without rebuilding the company.
## Sandbox vs production
RapidStart can run in sandbox without affecting production. Always test imports in sandbox first; verify counts, spot-check records, validate workflows.
## Multi-company setup
A common pattern: one configuration package applied across multiple companies for consistency. Limitations:
- Company-specific data (number sequences, posting groups specifics) often needs per-company adjustment.
- Master data should be the same across companies.
## Strategic positioning
RapidStart Services is mature but increasingly an "implementation acceleration" tool rather than a strategic platform. New customers benefit from quick setup; ongoing data operations should use modern tools. Partners building methodologies should layer RapidStart with newer tooling — configuration packages for initial setup, Power Automate for ongoing sync, REST APIs for high-volume programmatic operations. The toolkit isn't going away; it's just one tool among many in the modern BC implementer's bag.
---
# Real-time vs background workflows in Dataverse
The two execution modes for Dataverse classic workflows — real-time / synchronous vs background / asynchronous — and the implications for behaviour.
Source: https://www.solvingdynamics365.com/guides/real-time-vs-background-workflows
Section: Customer Engagement / Dataverse platform
Published: 2026-07-10
A classic Dataverse workflow runs in one of two modes — **real-time (synchronous)** or **background (asynchronous)**. The same workflow definition behaves quite differently in each mode; the choice matters for transaction semantics, performance, and operational behaviour.
**Real-time workflows.**
A **real-time workflow** runs **synchronously** as part of the same Dataverse transaction that triggered it:
- The user (or API call) initiates an operation (Create, Update, Delete, etc.).
- Dataverse runs the operation.
- Real-time workflows registered to fire on that event execute *inside* the transaction.
- Any errors in the workflow can roll back the entire transaction.
- The user / API caller waits for the workflow to complete before getting the response.
**Implications:**
- **Transactional integrity** — workflow logic that fails rolls back the originating operation. Use case: a workflow that validates customer credit before allowing an opportunity to advance can refuse the operation by raising an error.
- **Synchronous execution** — the user pays for the workflow time. Slow workflows make the UI feel slow.
- **Latency contribution** — every real-time workflow adds latency to its trigger event.
- **Error visibility** — workflow errors surface immediately to the user.
- **Cannot use wait conditions** — synchronous execution can't pause indefinitely.
**Background workflows.**
A **background workflow** runs **asynchronously** after the originating operation:
- The user initiates the operation; Dataverse processes it.
- Background workflows queue for later execution.
- A separate execution thread picks them up and runs them.
- Workflow errors are logged to the workflow history but don't affect the original operation.
**Implications:**
- **No transaction rollback** — the originating operation already committed; the workflow can't undo it.
- **No user-visible latency** — the originating operation completes immediately.
- **Eventual consistency** — there's a delay between the originating operation and the workflow's effects.
- **Wait conditions supported** — workflows can pause for hours or days waiting for conditions.
- **Failure handling** — failed workflows can be retried automatically or surfaced in the workflow log for investigation.
- **Higher throughput** — many background workflows process in parallel.
**Choosing.**
Use **real-time** when:
- The workflow is fast (milliseconds).
- Errors in the workflow should roll back the originating operation.
- Synchronous data integrity is essential.
Use **background** when:
- The workflow takes more than a fraction of a second.
- Wait conditions, delays, or polling are involved.
- The workflow makes external calls (API, integration).
- The workflow is part of an asynchronous business process.
- Errors should be recoverable but not block the original operation.
**Real-time workflow caveats.**
- **Avoid external API calls** — adds unpredictable latency to user operations.
- **Avoid heavy logic** — substantial computation slows the user experience.
- **Be careful with side effects** — modifications cascade through other triggers and other workflows.
- **Test under load** — real-time workflows that work at low volume may bottleneck at scale.
**Background workflow caveats.**
- **Queue backlog** — heavy background workflow load can produce queue delays. A workflow that "should fire immediately" might fire minutes later if the queue is full.
- **No automatic compensation** — if a background workflow needs to roll back its effects, you must write compensation logic explicitly.
- **Wait state cleanup** — workflows with wait conditions sitting indefinitely consume resources. Clean up abandoned waits.
## The Power Automate parallel
The same dichotomy applies to Power Automate flows:
- **Instant flows** triggered synchronously in a UI context — equivalent to real-time.
- **Automated flows** triggered on Dataverse events — typically asynchronous, equivalent to background.
Modern Dynamics 365 implementations use Power Automate for most asynchronous orchestration; classic background workflows survive for legacy logic; real-time classic workflows survive where in-transaction semantics matter.
**Monitoring.**
- **Real-time** — failures surface to users immediately. Application Insights captures the trigger context.
- **Background** — workflow history table records every execution with status. Long-running queues need active monitoring.
**Common pitfalls.**
- **Wrong mode chosen** — real-time workflow doing heavy work slows the UI; background workflow doing critical validation lets bad data slip through.
- **External calls in real-time mode** — API timeouts make the UI freeze.
- **No queue monitoring for background workflows** — workflows pile up unnoticed.
- **Wait conditions abandoned** — stuck waits consume resources indefinitely.
## Operational reality
For new logic, default to Power Automate (typically asynchronous). For existing classic workflows, audit which should be real-time vs background based on what the logic actually requires. Mode mismatches are one of the most common workflow performance and behaviour issues.
### Frequently asked questions
**What is the difference between a real-time and a background workflow?**
A real-time workflow runs synchronously inside the triggering transaction — it can roll the operation back and the user waits for it. A background workflow queues and runs afterwards; the original operation has already committed and failures are logged rather than blocking.
**Can a real-time workflow use wait conditions?**
No. Synchronous execution cannot pause; wait conditions, delays, and polling require background workflows, which can wait hours or days.
**Should new logic be a classic workflow at all?**
Usually not. Default to Power Automate for asynchronous orchestration. Real-time classic workflows survive where in-transaction validation matters; background workflows survive as legacy logic.
**Why are my background workflows firing late?**
Queue backlog. Heavy background workflow volume delays execution by minutes, and abandoned wait states consume resources — monitor the queue and clean up stuck waits.
---
# Real-time vs outbound journeys
The two journey models in Customer Insights – Journeys — when to use each, key differences, and the Microsoft direction of travel.
Source: https://www.solvingdynamics365.com/guides/real-time-vs-outbound-journeys
Section: Foundations
Published: 2026-05-01
Customer Insights – Journeys (the successor to Dynamics 365 Marketing) ships two distinct journey models — **real-time journeys** and **outbound journeys**. They look similar in the designer but operate on very different mechanisms. Microsoft is moving customers toward real-time as the default; understanding why matters for both new builds and existing-tenant migrations.
## Outbound journeys
The original model, inherited from the older Dynamics 365 Marketing product. Built around:
- **Segments** — saved queries that produce static lists of contacts at journey-start time.
- **Static membership** — once the journey starts, the contact list is largely fixed; mid-journey additions are limited.
- **Scheduled execution** — the journey runs on a calendar, sending email at planned times.
- **Email-centric** — historically email-heavy with limited support for other channels.
- **Less personalisation** — limited mid-flight branching on real-time signals.
Outbound is the right pattern for traditional campaigns: "send this email to everyone in segment X tomorrow at 9am, follow up with a second email three days later if they didn't open the first".
## Real-time journeys
The modern model, built natively for the new Customer Insights – Journeys product. Built around:
- **Triggers** — events that fire the journey for one specific person at the exact moment the event happens. Triggers come from Dataverse changes, web form submissions, API calls, page visits, custom events.
- **Dynamic membership** — every event evaluates eligibility; the journey activates per individual the moment their data matches.
- **Real-time execution** — milliseconds-to-seconds between trigger and action.
- **Multi-channel** — email, SMS, push notifications, in-product messages, Teams cards, custom channels.
- **Richer branching** — wait for behaviour signals (opened the email? clicked? visited the page?) and adapt the next step.
Real-time is the right pattern for behaviour-driven engagement: "when a customer downloads a whitepaper, wait 24 hours, send a follow-up email, wait for their click, if they clicked the demo link, send a sales-handoff email; if they didn't, send a different nurture email".
**The differences in practice.**
| Aspect | Outbound | Real-time |
|---|---|---|
| Trigger | Segment + schedule | Event |
| Membership | Mostly static | Fully dynamic |
| Latency | Seconds-to-hours | Near-instant |
| Channels | Email-led | Multi-channel native |
| Mid-journey branching | Limited | Rich |
| Volume | Large batches | Distributed bursts |
| Compliance | Legacy | Modern (consent-by-design) |
## Microsoft direction
Microsoft is investing in real-time as the strategic platform. Outbound is in maintenance mode — supported, but not the focus of new feature work. Microsoft has announced timelines for outbound deprecation; new customers should build real-time-first.
## Migration
For existing customers with outbound journeys, Microsoft provides tools to migrate journeys to the real-time model. Many require rebuilding (the underlying mechanics differ enough that automatic conversion has limits). Plan migration as a small project, not a flip-switch.
## When outbound is still right
Some scenarios remain outbound-friendly: bulk monthly newsletters with no behaviour-driven follow-up, simple announcement campaigns, lift-and-shift legacy campaigns awaiting migration. But for any *new* behaviour-driven engagement, build real-time.
## The hybrid period
Mature tenants run both side-by-side during the migration window — real-time for new builds, outbound for legacy campaigns yet to migrate. Document which lives where and migrate the highest-value journeys first.
## Operational reality
Real-time journeys demand cleaner data and better event design. The reward is dramatically more relevant customer experiences; the investment is real but bounded.
### Frequently asked questions
**What is the difference between real-time and outbound journeys?**
Outbound journeys start a mostly static segment on a schedule and are email-led. Real-time journeys start per person on an event — a form fill, a Dataverse change, an API call — with dynamic membership, near-instant execution, multi-channel sends, and rich behaviour-based branching.
**Is outbound marketing being retired?**
Yes. Microsoft has put outbound in maintenance mode, announced deprecation timelines, and provisions new environments as real-time only. New journeys should be built real-time-first.
**Can outbound journeys be migrated automatically?**
Partly. Microsoft provides migration tooling, but the mechanics differ enough that many journeys need rebuilding. Treat it as a small project and migrate the highest-value journeys first.
**When is outbound still acceptable?**
For legacy bulk newsletters and simple announcements awaiting migration during a hybrid period. Any new behaviour-driven engagement belongs in real-time.
---
# Reason codes in Business Central
How Business Central uses reason codes to classify transactions — returns, inventory adjustments, credit memos — and the reporting they enable.
Source: https://www.solvingdynamics365.com/guides/reason-codes-in-business-central
Section: Business Central / Finance & accounting
Published: 2026-05-01
**Reason codes** in Business Central are short tags attached to transactions to explain *why* they happened. They look unimportant in setup; they become the foundation of meaningful operational reporting when used consistently.
## Where reason codes appear
Most transactional documents and journals carry a *Reason Code* field:
- **Sales credit memos** — why is this credit being issued? (Damaged goods, wrong item shipped, pricing error, customer complaint, return for refund.)
- **Sales returns** — why is the customer returning? (Wrong item, defective, no longer needed, ordered too many.)
- **Purchase credit memos** — why are we sending this back to the vendor? (Damaged in transit, wrong item received, quality issue.)
- **Purchase returns** — same reasons mirrored on the inbound side.
- **Inventory adjustments** — why is stock being adjusted? (Cycle count variance, damage, found, theft, expired, sample.)
- **G/L journal entries** — categorisation of manual journals.
- **Item ledger entries** — explanation for movements outside the normal posting flow.
## The reason code table
Setup is minimal:
- **Code** — a short identifier (RET-DEFECT, RET-WRONG, COUNT-VAR, etc.).
- **Description** — human-readable label.
Codes can be created freely and updated; deleting a code used historically requires care.
## Default values
Documents can default a reason code from a customer template, vendor template, or location, so the most common reason auto-fills.
## Why they matter — reporting
Reason codes are the analytical axis for *why* questions:
- **Return rate by reason** — what proportion of returns are defective vs wrong-item vs customer error? Drives supplier scorecards and quality programs.
- **Inventory variance analysis** — what's the breakdown of variance reasons? Damage vs theft vs counting error vs spoilage.
- **Customer complaint categorisation** — credit memo reason codes feed customer-service quality metrics.
- **Operational improvement** — patterns in reason codes reveal which processes need fixing.
## Reporting through dimensions
Reason codes are *not* dimensions — they live on a separate field on each transaction. Standard BC reports filter by reason code; Power BI dashboards group and chart by it.
## Coding discipline
This is where most companies fail. Reason codes only work if they're:
- **Used consistently** — every credit memo gets a reason code, not just some.
- **Coded specifically** — "Other" as 50% of all reasons reveals nothing.
- **Limited in number** — 8–15 reason codes per area, not 50. Too many and users pick the first option to escape.
- **Reviewed annually** — codes that aren't used should be retired; new operational categories should be added.
## Mandatory configuration
For documents where reason coding is critical (e.g. sales credit memos), make the field **mandatory** through workflow rules or page customisation. Users cannot post the document without selecting a reason. Annoying for users in the short term; invaluable for the data over months.
## Cross-system analysis
When reason codes are consistently captured, the Power BI dashboards built on top illuminate operational dynamics the team didn't know were there: a spike in "damaged in transit" returns linked to a specific carrier, a seasonal pattern in "customer ordered too many" suggesting demand-planning improvements, a vendor whose "defective" rate is 3× the average.
## Limits
Reason codes are flat — a single value per transaction. For multi-dimensional categorisation (reason + sub-reason + root cause), customers add custom fields or use a dedicated quality module.
## Operational reality
Reason codes are unglamorous, painfully simple, and remarkably powerful. Spend 30 minutes designing a good set; train the team; report on it monthly.
---
# Recurring journals in Business Central
How to use recurring journals in Business Central for periodic postings — fixed amounts, variable amounts, allocations, and expiration dates.
Source: https://www.solvingdynamics365.com/guides/recurring-journals-in-business-central
Section: Business Central / Finance & accounting
Published: 2026-05-01
**Recurring journals** in Business Central automate the periodic postings that finance teams would otherwise re-key every month: rent, lease payments, scheduled accruals, depreciation outside the FA module, payroll provisions, intercompany cost transfers, and any other regular non-document journal.
## The recurring journal
It looks like a regular general journal but with extra columns that control repetition. Each line carries:
- **Recurring Method** — how the amount is calculated:
- **Fixed** — same amount each period.
- **Variable** — amount manually entered each period; otherwise zero.
- **Balance** — reverses to zero the GL account's balance each period (used for clearing accounts).
- **Reversing Fixed / Variable / Balance** — same as above plus an automatic reversing entry the following day (for accruals that reverse next period).
- **Recurring Frequency** — a date formula expressing how often the line should re-post: `1M` (monthly), `1Q` (quarterly), `1Y` (annually), `7D` (weekly), or compound formulas.
- **Posting Date Formula** — the formula that computes the next posting date when the journal is run.
- **Expiration Date** — when the line stops re-posting (blank for indefinite).
## How it works
When the user posts a recurring journal, Business Central:
1. Posts the lines using the dates and amounts.
2. Advances the **Posting Date** of each line by the **Recurring Frequency**.
3. Resets the **Amount** to zero on Variable lines (forcing manual entry next period) or keeps the Fixed amount.
4. Skips lines whose expiration date has passed.
The same journal is then ready for next period's run — no manual rebuild.
## Allocations
Recurring journal lines support **allocations** — splitting a single posting across multiple destinations by percentage. Common use: an IT cost recorded centrally, allocated 40% to Sales, 30% to Operations, 20% to Finance, 10% to Other. The allocation rule is configured once, executed on every run.
## Dimension defaults
Each recurring line carries default dimensions, so postings tag the right cost centre, project, or other dimension without manual entry every period.
## Reversing entries
The reversing recurring methods are the classic accrual pattern: post an accrual on month-end, automatically reverse on the first of the next month, accrue again with new amounts. Standard finance hygiene without manual reversal effort.
## Multiple batches
Recurring journals live in batches like regular journals, so you can organise by frequency, owner, or purpose: a "Month-End" batch with all monthly accruals, a "Quarterly" batch, a "Weekly Payroll Provision" batch.
## Approval workflow
Like other journals, recurring journals can be routed through approval workflow before posting.
**Operating discipline.**
- **Document the purpose** of each recurring line in the *Description* and the *External Document No.* fields — controllers six months in should understand why each line exists.
- **Review quarterly** — recurring entries become invisible noise if nobody reviews them. Expired contracts, changed allocations, stale amounts all degrade the GL.
- **Use expiration dates** for time-bounded postings (a 24-month lease, for example).
- **Standardise the batches** — month-end accruals in one batch, fixed monthly costs in another, allocations in a third.
## Limits
Very complex calculation logic (e.g. allocations based on a formula across actuals) belongs in custom code or a Power Automate flow that builds the journal from a calculation — recurring journals handle fixed-rule patterns well, not data-driven complex logic.
---
# Relationship Analytics in Dynamics 365 Sales
How Relationship Analytics scores account and contact health — input signals, the relationship health score, KPIs surfaced.
Source: https://www.solvingdynamics365.com/guides/relationship-analytics-in-dynamics-365-sales
Section: Customer Engagement / Sales
Published: 2026-05-01
A salesperson with 80 active accounts can't deeply intuit each relationship's health. **Relationship Analytics** in Dynamics 365 Sales (Premium SKU) aggregates engagement signals into a quantified health score per contact and account, with trends and drill-down. Used well, it surfaces risks and opportunities reps would otherwise miss; used badly, it becomes a gamed metric.
## The relationship health score
A single number per account or contact:
- **Healthy** — green; relationship is active and positive.
- **Fair** — yellow; some concerns.
- **Poor** — red; relationship needs attention.
The score is computed from multiple inputs:
- **Activity frequency** — how often emails, calls, meetings happen with the customer.
- **Sentiment** — derived from email and conversation analysis.
- **Engagement breadth** — how many people on the customer side are engaged.
- **Pipeline activity** — open opportunities, momentum.
- **Communication recency** — when was the last meaningful touch.
The model is opaque (an ML black box from the user's perspective) but the contributing signals are transparent.
## Trends
A single point-in-time score is information; a trend is insight. Relationship Analytics tracks score over weeks/months. A score declining from healthy to fair to poor is a leading indicator of risk — usually 1–2 months ahead of pipeline impact.
**The conversation it enables.**
- **Account review:** "These three accounts are declining; what's happening?"
- **Quarterly planning:** "Half my book is yellow; I need a coverage plan."
- **Manager 1:1:** "Your top 5 accounts are healthy, your tail 20 are red — should we restructure your time?"
**Signals in detail.**
- **Emails** — counted; sentiment scored; reply velocity tracked. Captured via Outlook integration or server-side sync.
- **Meetings** — frequency from calendar; participants counted.
- **Phone calls** — if a dialler is integrated, calls logged automatically.
- **Customer responses** — explicit responses to outreach factored in.
Without the capture layer, signals are blind. The richer the activity capture, the more accurate the analytics.
**Engagement KPIs surfaced.**
- **Last meaningful interaction** — date of last in-person meeting or substantive email exchange.
- **Number of decision-makers engaged** — count of contacts at the account.
- **Stakeholder coverage** — are all key roles touched?
- **Response time** — how quickly does the customer respond to us?
These KPIs are visible per account; reps drill into them to understand the score.
## Combining with predictive opportunity scoring
Relationship health and opportunity score are complementary:
- **High health + high opportunity score** — sweet spot; double down.
- **High health + low score** — relationship is strong, deal is stalling; the deal might be wrong but the customer is worth retaining.
- **Low health + high score** — vulnerable; risk of competitor displacement.
- **Low health + low score** — disengagement; consider account triage.
This 2x2 framing is useful for territory reviews.
**Setup requirements.**
- **Email** — Server-side sync or Outlook integration capturing emails to/from customer addresses.
- **Calendars** — calendar appointments synced to Dynamics activities.
- **Account-contact linkage** — contacts mapped to the right account; emails routed to the right relationship.
- **Sales Premium licence** — Relationship Analytics is Premium-only.
Without these, the data is sparse and scores meaningless.
**Data hygiene matters.**
- **Contact role classification** — knowing who's a decision-maker vs influencer makes engagement coverage analysis meaningful.
- **Account membership accuracy** — contacts wrongly linked to accounts distort scores.
- **Activity capture discipline** — reps logging activities manually adds signal beyond automated capture.
The analytics are only as good as the data. A rep who diligently logs calls and meetings gets a meaningful score; a rep who doesn't gets noise.
**Operational adoption patterns.**
- **Score visible on the account card** — reps see it in their daily flow.
- **Score in the "my accounts" view** — sortable; manage by risk.
- **Manager dashboards** — book health summary by rep.
- **Triggers** — score drops below threshold → alert manager.
The data has value when it flows into specific operational decisions. Score on a dashboard nobody reviews is wasted.
**Common pitfalls.**
- **Score gamed.** Reps log fake activities to inflate scores. Mitigation: use customer-side response data heavily.
- **Score believed without checking signals.** Score is low — reps blame the model, ignore the signal underneath. Always drill: what's actually missing?
- **Capture gaps.** No email integration; score artificially low because no signal. Fix capture before measuring.
- **Threshold definitions unclear.** Healthy / Fair / Poor cutoffs not aligned with the team's reality; recalibrate per segment.
- **Comparisons across segments.** Enterprise accounts have fewer activities than mid-market by nature; comparing scores cross-segment is misleading.
## Strategic positioning
Relationship Analytics is a coaching and triage tool, not a replacement for rep judgment. The best use: surface the questions ("why is this dropping?") rather than dictate the answers. Combined with conversation intelligence and predictive opportunity scoring, it forms a complete account-health picture — but only for teams with the capture and adoption discipline to make it real.
---
# Release management for Dynamics 365
How to manage releases for Dynamics 365 — release cycles, change advisory, version control, deployment runbook.
Source: https://www.solvingdynamics365.com/guides/release-management-for-dynamics-365
Section: Implementation / Operations & support
Published: 2026-05-01
A Dynamics 365 environment that goes from configuration to production needs a release management process that handles change governance, testing, deployment, and rollback. The process scales from a small team shipping weekly to an enterprise programme shipping monthly to multiple customers. The structure of the process matters less than its consistency.
## Why release management
Without process:
- Changes happen ad-hoc; nobody knows what's in production.
- Defects re-emerge because fixes weren't promoted to upstream environments.
- Deployments fail because dependencies weren't included.
- Audits fail because change isn't tracked.
A release management process imposes structure: what gets released, when, with what review, by whom, with what fallback.
**Release types.**
- **Major release** — significant new functionality, breaking changes, training required.
- **Minor release** — smaller features, configuration changes.
- **Patch / hotfix** — urgent bug fixes; smaller scope.
- **Microsoft platform updates** — handled by Microsoft per the release wave cadence.
Each type has different governance overhead — major releases get full review, hotfixes get expedited path.
**Release cadence patterns.**
- **Weekly** — small-scope team; high agility; production-ready every Friday.
- **Bi-weekly** — common for mid-size teams; matches sprint cadence.
- **Monthly** — common for enterprise; allows full regression testing.
- **Quarterly** — heavy enterprise; aligns with budget and planning cycles.
The cadence should be a deliberate choice based on team capability, business tolerance, and risk profile. Faster isn't better universally — small teams can ship faster; large teams benefit from slower, batched cadence.
## Microsoft's release waves
Microsoft ships two annual waves:
- **Wave 1** — April / May.
- **Wave 2** — October / November.
Plus continuous minor updates monthly. Customers can defer wave updates by one cycle but not indefinitely. Coordinate customer releases with Microsoft's calendar — avoid heavy customer-side release work during Microsoft wave application.
**Release planning.**
- **Roadmap** — items in scope for upcoming releases (next 1–3 releases visible).
- **Backlog** — prioritised items not yet scheduled.
- **Release content** — final list for a specific release, frozen N days before deployment.
Content freeze is a discipline — once frozen, no new items added without exception process. Without freeze, releases bloat and slip.
**Change advisory.**
- **Change Advisory Board (CAB)** — stakeholders reviewing proposed changes.
- **Change ticket** — every change documented with risk assessment, testing plan, rollback plan.
- **Approval gates** — major changes need formal approval before promotion.
For regulated industries, formal CAB is mandatory; for less regulated, lightweight equivalents work.
**Version control.**
- **Solutions** stored in source control.
- **Configuration data** versioned alongside.
- **Documentation** in same repo.
- **Branching strategy** — feature branches; main always deployable.
Every release tagged in source control; reconstructible at any time.
**Testing strategy.**
- **Unit tests** — for plug-ins, low-code plug-ins, Power Fx.
- **Integration tests** — flows, end-to-end scenarios.
- **UAT** — business user acceptance.
- **Regression tests** — automated suite re-run for every release.
- **Performance tests** — for load-sensitive changes.
- **Security tests** — for access-control changes.
Test depth scales with risk; hotfixes get minimal testing, major releases get comprehensive.
## Deployment runbook
Per release, a detailed runbook:
- Pre-deployment checks (downstream environment state, backup taken).
- Deployment steps in order.
- Validation per step.
- Rollback procedures.
- Communication plan.
- Post-deployment validation.
The runbook is rehearsed in pre-production; deployment to production should feel anticlimactic.
**Deployment windows.**
- **Off-hours** — common for high-availability production (nights, weekends).
- **Business hours** — for low-impact changes with rollback safety.
Communicate windows in advance; expect users to plan around.
## Rollback strategy
Every release has documented rollback:
- Restore from pre-deployment backup.
- Re-install previous managed solution version.
- Re-apply previous configuration.
Untested rollback is worse than no rollback — rehearse in pre-production.
**Communication.**
- **Pre-release** — what's coming, when, who's affected.
- **During deployment** — status updates.
- **Post-deployment** — success / issues; quick acknowledgment of any problems.
Communication transparency builds trust; silence during incidents breeds anxiety.
**Post-deployment monitoring.**
- Health checks immediately after deployment.
- Error rate monitoring vs baseline.
- User-reported issues.
- Performance metrics.
The window after deployment is high-risk; monitoring catches issues that automated tests missed.
**Common pitfalls.**
- **No release calendar.** Random deployments; teams blindsided.
- **Hotfixes accumulate.** Each emergency change bypasses process; total drift between environments grows.
- **No rollback rehearsal.** First time rolling back is during a real incident.
- **Heavy process for small changes.** CAB for typo fix; productivity dies.
- **Light process for big changes.** Major release pushed without testing; production breaks.
- **Communication absent.** Users frustrated by surprise downtime.
- **Documentation rot.** Release notes promised but never written; institutional memory in heads only.
**Operational rhythm.**
- **Daily** — backlog grooming, in-progress work.
- **Weekly** — release planning, CAB if relevant.
- **Per release** — content freeze → testing → deployment → post-deployment review.
- **Quarterly** — process retrospective; improve based on incidents and friction.
## Strategic positioning
Release management is one of the highest-leverage process investments in any production Dynamics 365 deployment. Good release management makes change cheap and safe; bad release management makes change expensive and risky. The discipline isn't glamorous — checklists, runbooks, CAB meetings — but the alternative (constant fire-fighting, lost trust, failed audits) is much worse. Build it early; refine continuously; measure with cycle time, failure rate, and rollback frequency.
---
# Reminders and finance charges in Business Central
How Business Central handles customer payment reminders and finance charge memos — terms, levels, escalation, and the integration with collections.
Source: https://www.solvingdynamics365.com/guides/reminders-and-finance-charges-in-business-central
Section: Business Central / Finance & accounting
Published: 2026-05-01
For any business that sells on credit terms, some customers pay late. Chasing them — sending reminders, escalating to formal demands, charging interest on overdue balances — is unglamorous but essential. Business Central's **reminders** and **finance charges** capabilities give finance teams the structured process to do it efficiently.
## Reminder terms
A **reminder term** defines an escalation ladder. Each term has multiple **reminder levels**, each with:
- **Grace period** — days after due date before this reminder applies.
- **Due date calculation** — when the reminder itself is due (typically a short window).
- **Calculate interest** — yes / no for this level.
- **Additional fee** — flat fee added to the reminder (administrative charge).
- **Suggest line description / text** — boilerplate text for the reminder document.
A typical setup might have three levels:
- **Level 1** — friendly reminder, 7 days past due, no interest, small fee.
- **Level 2** — formal reminder, 21 days past due, interest charged, larger fee.
- **Level 3** — pre-legal notice, 60 days past due, interest accrued, escalation flagged.
Different reminder terms can apply to different customer segments — *Standard*, *Strategic*, *Government* — each with its own escalation logic. Customers carry a default reminder term on their card.
## Generating reminders
The **Create Reminders** routine scans open customer ledger entries past their due date, identifies entries eligible for each reminder level, and proposes a reminder document per customer. The user reviews proposals, edits text or excludes entries on a case-by-case basis, and posts.
A posted reminder:
- Records the reminder action on the customer ledger.
- Increments the reminder level for the next time.
- Optionally posts a *fee* line that adds to the customer's outstanding balance.
- Generates a printable / emailable reminder document — typically a Word-templated layout with the overdue invoices listed.
## Finance charge memos
Beyond reminders, **finance charge memos** specifically post **interest** on overdue balances:
- A **finance charge term** defines the interest rate, calculation method (interest by day, by period), grace period.
- The **Create Finance Charge Memos** routine identifies eligible overdue entries and proposes memos with calculated interest amounts.
- Posted memos add interest entries to the customer ledger, payable by the customer.
## Integration with collections
Beyond the basic mechanics, mature collections processes:
- **Hold further sales** — block new sales orders to customers at advanced reminder levels.
- **Manager escalation** — Power Automate flows notify the account manager and CFO when customers reach Level 3.
- **Collections workflow** — assign overdue customers to a collections specialist for active follow-up.
- **Payment promise tracking** — record customer commitments to pay; reminder routines respect the promised date.
Specialist collections ISVs (Cashbook, Continia Collections Management) add the deeper workflow — payment-promise tracking, dunning escalation matrices, call logging, dispute management.
## Document layouts
Reminder and finance charge memo layouts are Word templates; the company brand, tone, and detail level are configurable per layout. Multi-language reminders to international customers honour the customer's language code.
## Compliance
Some jurisdictions regulate maximum interest rates, mandatory grace periods, and reminder content. Check local regulations; the system supports configuration, but compliance is the customer's responsibility.
## Operational reality
Reminders work when run consistently — weekly or biweekly, not "when someone remembers". Schedule the routine; review proposals; send. The system handles the mechanics; the operational discipline produces the cash flow.
---
# Reporting tools in Dynamics 365 Finance
The reporting stack in Dynamics 365 Finance — Financial Reporting, electronic reporting, Power BI, and where each one fits.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-finance-reporting-tools
Section: Finance & SCM / Finance
Published: 2026-05-01
Dynamics 365 Finance ships with several reporting tools that overlap on the edges. Picking the right tool for each job is the difference between a clean reporting stack and a sprawl of one-off reports nobody trusts.
## Financial Reporting
A row-and-column reporting engine descended from Management Reporter (and FRx before it), built specifically for financial statements: P&L, balance sheet, cash flow, statutory disclosures. Reports are designed in a web UI inside F&O, executed against the GL with full dimension support, and rendered on screen or exported to PDF/Excel. The right tool for management accounts and statutory reporting, period.
## Electronic Reporting (GER)
Microsoft's **Globalization Studio / Electronic Reporting** is a configurable, no-code framework for generating structured outputs in fixed formats — XML, JSON, fixed-width — and consuming the same in. It's used for **statutory e-invoicing**, country tax filings, SAF-T exports, payment file generation (SEPA, BACS, ACH), and bank statement imports. ER configurations are sourced from a global repository so customers and partners can share country implementations.
## Power BI
Self-service interactive analytics. F&O ships pre-built **Power BI apps** for finance, supply chain, sales, and retail. Customers extend or replace them with their own datasets. Power BI is the right tool for dashboards, exploratory analytics, and any visualisation that goes beyond tabular financial reports.
## Microsoft Fabric and Synapse Link
**Synapse Link for Dataverse** and **Microsoft Fabric** stream F&O data into a lakehouse where it can be combined with non-Microsoft sources, transformed with notebooks, and consumed by Power BI or other tools. The right pattern when reporting needs F&O data joined with non-Dynamics data, or when transformations exceed what Power BI's model can do directly.
## SSRS reports
The legacy **SQL Server Reporting Services** reports inside F&O (invoices, packing slips, statements) still exist. They're typically used for transactional documents printed and emailed at posting time. Customisation of standard SSRS reports is done in Visual Studio.
## Where it stops
Workforce analytics, complex consolidation reporting, and demand sensing usually combine **Power BI + Fabric + an analytical model** rather than relying on F&O's built-in tools alone. Treat F&O's built-ins as the source of truth and Fabric/Power BI as the analytical surface.
## Practical guidance
Statutory financials → Financial Reporting. Country filings → Electronic Reporting. Operational dashboards → Power BI. Customer documents → SSRS. Cross-system analytics → Fabric.
---
# Requirements gathering for Dynamics 365 implementations
How to gather requirements effectively for a Dynamics 365 implementation — workshop techniques, business process analysis, prioritisation.
Source: https://www.solvingdynamics365.com/guides/requirements-gathering-for-dynamics-365
Section: Implementation / Project execution
Published: 2026-05-01
Requirements gathering is the foundation of every Dynamics 365 implementation. Done well, it produces clear functional designs and confident scoping; done badly, it leads to discovery surprises, rework, and budget overruns. The methodology matters less than the discipline applied.
**The output goals.**
- Clear understanding of as-is processes.
- Defined to-be processes.
- Specific functional requirements.
- Non-functional requirements (performance, security, etc.).
- Prioritisation (must-have, should-have, nice-to-have).
- Documented assumptions and risks.
- Stakeholder consensus.
The output feeds FDDs, TDDs, and project planning.
## Workshop-based approach
Most common:
- Facilitated workshops per business area.
- Stakeholders engaged in person or virtually.
- Documented in real-time.
- Iterative validation.
The workshop format produces alignment alongside requirements.
**Workshop preparation.**
- Pre-read materials sent.
- Specific agenda.
- Right participants invited.
- Workshop length appropriate (half-day to multi-day).
- Logistics organised.
Unprepared workshops waste senior time; preparation matters.
**Discovery techniques.**
- **Process mapping** — walk through current state step by step.
- **Pain point analysis** — what's broken in current process?
- **Aspirational visioning** — what would the future look like?
- **Quick-win identification** — what's easy and high-impact?
- **Edge case discussion** — what unusual scenarios occur?
Combine techniques to draw out comprehensive requirements.
**As-is vs to-be.**
- **As-is** — current state documentation.
- **To-be** — desired future state.
The gap analysis between them is the implementation scope.
## Why document as-is
Tempting to skip:
- Saves time.
- Future-focused.
But:
- Reveals dependencies on legacy.
- Surfaces process knowledge held by individuals.
- Provides context for to-be design.
Always document as-is, even briefly.
**To-be process design.**
- Reflect best practices.
- Match Dynamics 365 standard processes where appropriate.
- Customise only where business genuinely demands.
- Validate with stakeholders.
The "fit-gap" analysis identifies where standard fits and where it doesn't.
**Functional vs non-functional requirements.**
- **Functional** — what the system does (e.g., "create sales order").
- **Non-functional** — quality attributes (performance, security, scalability, usability).
Both essential; non-functional often overlooked until late.
**Common non-functional requirements.**
- **Performance** — response time targets.
- **Availability** — uptime requirements.
- **Scalability** — user count, data volume.
- **Security** — encryption, access control, audit.
- **Compliance** — regulatory requirements.
- **Accessibility** — WCAG, Section 508.
- **Localisation** — multi-language, multi-currency.
These shape architecture and implementation.
**Prioritisation methods.**
- **MoSCoW** — Must, Should, Could, Won't.
- **High / Medium / Low.**
- **Value vs effort matrix.**
- **Cost / benefit analysis.**
Force ranking — be explicit about trade-offs.
**Stakeholder management.**
- **Executive sponsors** — strategic direction.
- **Business owners** — process accountability.
- **Subject matter experts** — operational detail.
- **Power users** — daily use perspective.
- **IT team** — technical integration.
Engage appropriate level for each requirement type.
**Documentation formats.**
- **Process narrative** — text describing flow.
- **Flow diagrams** — visual.
- **User stories** — "As a [role], I want [action], so that [benefit]."
- **Use cases** — formal scenarios.
- **Requirements catalogue** — structured list.
Different audiences prefer different formats; multiple representations may help.
**Tools.**
- **Microsoft Word / Excel** — common.
- **Microsoft Loop / OneNote** — collaborative.
- **Confluence** — for development-led teams.
- **DevOps Boards** — user stories tied to development.
- **Specialised requirements tools** — IBM DOORS, others.
Tool choice less important than discipline.
**Validation cycles.**
- **Draft** requirements.
- **Review** with stakeholders.
- **Revise** based on feedback.
- **Validate** with final readers.
- **Sign-off** at design completion.
Iteration is healthy; first-draft signed off rarely matches reality.
**Common pitfalls.**
- **Wishlist syndrome.** Every nice-to-have included; scope explodes.
- **Anchoring on current.** "Same as today but in Dynamics" — misses opportunity.
- **Missing edge cases.** Happy path documented; exceptions emerge in test.
- **No prioritisation.** Everything's a "must"; budget impossible.
- **Stakeholder absence.** Key person missed; requirements gap.
- **Verbal-only agreement.** Documented vaguely; interpretation differs.
**Discovery anti-patterns.**
- **Boil-the-ocean discovery.** Months of analysis paralysis.
- **Insufficient discovery.** Rush to build; discoveries come later as change orders.
- **Wrong abstraction level.** Either too detailed too early or too vague throughout.
## Time-boxing
Discovery shouldn't be indefinite:
- Plan phase duration.
- Acknowledge some unknowns won't resolve until later.
- Document what's known and assumed.
- Move forward; refine during build.
## Iterative discovery
For agile implementations:
- High-level requirements upfront.
- Detailed per-sprint discovery.
- Backlog grooming.
Suitable for some projects, not all; depends on scope clarity.
## Standard vs custom
Important judgement:
- **Adopt standard** wherever possible — easier maintenance.
- **Customise** only where business value clearly justifies.
The "we always do it this way" reflex often hides opportunities to adopt better-fitting standards.
## Strategic positioning
Requirements gathering is investment in clarity. Spent well, it produces confident designs; spent poorly, it produces brittle specifications that don't survive contact with build. Mature implementations balance enough discovery to design confidently with enough humility to refine during build.
For project leaders:
- Plan discovery time deliberately.
- Engage right stakeholders.
- Document candidly, not aspirationally.
- Prioritise ruthlessly.
- Iterate; don't expect first pass to be final.
The discipline is constant attention to clarity and stakeholder engagement; the payback is build phases that proceed smoothly without constant re-questioning of requirements.
## Where to go next
Requirements feed [fit-gap analysis](https://www.solvingdynamics365.com/guides/fit-gap-analysis-for-dynamics-365), sit on [business process maps](https://www.solvingdynamics365.com/guides/business-process-mapping-for-dynamics-365), and become [functional design documents](https://www.solvingdynamics365.com/guides/functional-design-documents-for-dynamics-365). The gaps raise the [build vs buy](https://www.solvingdynamics365.com/guides/build-vs-buy-in-the-dynamics-365-ecosystem) question, and the same requirements return as scenarios in [user acceptance testing](https://www.solvingdynamics365.com/guides/user-acceptance-testing-for-dynamics-365).
---
# Resource management in Dynamics 365 Project Operations
How Project Operations matches people to projects — resource roles, skills, fulfillment requests, schedule board, and the resource manager workflow.
Source: https://www.solvingdynamics365.com/guides/project-operations-resource-management
Section: Customer Engagement / Project Operations
Published: 2026-05-01
Resource management — getting the right people on the right projects at the right time — is the operational heartbeat of a services firm. **Project Operations** provides the data model, the matching engine, and the workflows to make resource assignment systematic rather than ad-hoc spreadsheet-driven. The capability is there; the discipline to use it well is the differentiator.
**Resource model.**
- **Bookable Resource** — anyone who can be scheduled. Internal employees, contractors, sub-contractors.
- **Resource Role** — what kind of resource (Senior Consultant, Project Manager, Solution Architect).
- **Resource Skill** — specific competencies (.NET, Power Platform, SAP integration).
- **Skill Proficiency** — level (Beginner, Intermediate, Expert).
- **Certifications** — formal credentials.
- **Availability** — calendar of bookings, time-off, capacity.
A resource has one or more roles, multiple skills with proficiency levels, and a calendar. The matching engine uses all of this.
## Project resource requirements
When a project manager builds a team:
- Specify required roles per task or phase.
- Specify required skills (mandatory and preferred).
- Specify time period and percentage allocation.
Each requirement is a **resource requirement** record waiting to be filled.
**Fulfillment process.**
1. **Resource Request** raised against the requirement.
2. **Resource manager** (or auto-fulfillment) reviews requests.
3. **Search for matching resources** with required skills, availability, location.
4. **Propose** specific resources; PM accepts or counters.
5. **Book** the resource on the project.
The resource manager is a key role — they balance demand across projects, allocate scarce skilled people, advocate for re-allocation when priorities shift.
## Schedule board
Visual resource scheduling:
- Time-grid view (days, weeks).
- Resources as rows, time as columns.
- Bookings as blocks.
- Drag-and-drop to assign or move.
- Filters: skills, role, location.
- Conflict warnings.
For 20–50 resources, manual scheduling on the board works. For larger pools, optimisation helps.
## Resource Scheduling Optimization (RSO)
ML-driven auto-scheduling:
- Reads open requirements.
- Considers resource availability, skills, location, cost.
- Produces optimised assignments.
Configurable per organisation; can be advisory or automatic. Effective for high-volume scheduling (Field Service) and growing for Project Operations.
**Soft vs hard book.**
- **Soft book / proposed** — resource tentatively allocated; not committed.
- **Hard book / confirmed** — resource committed; counts against availability.
Soft books reserve while details are negotiated; once confirmed, they convert. Soft books expire if not confirmed within a configurable window.
## Conflict and overbook
System warns when:
- Booking exceeds resource capacity.
- Skills missing.
- Time-off conflict.
- Travel time tight between projects.
Overbooking is sometimes intentional (resource will work overtime); explicit overbook is allowed with reason.
## Demand forecasting
Beyond current bookings, **resource demand forecast**:
- Roles needed in coming quarters.
- Skill gaps emerging.
- Hiring or contractor decisions.
Generated from the pipeline (open opportunities likely to land) plus committed projects.
**Resource utilisation.**
- **Billable utilisation** — billable hours / capacity. The headline metric.
- **Variance vs target** — over- and under-utilised.
- **Trend over weeks** — patterns of overload or slack.
Utilisation drives staffing and hiring decisions.
**Cost vs bill rate.**
- **Cost rate** — what the resource costs (loaded labour cost).
- **Bill rate** — what the customer pays.
- **Margin** — bill - cost.
Each role has standard cost and bill rates; specific projects can override. Resource manager balances assigning the right rate-margin combination.
## Contractor management
Contractors are bookable resources with:
- External vendor relationship.
- Different cost structure (rates per agreement).
- Limited internal access (no proprietary IP).
- Per-contract availability.
Many services firms blend FTE and contractor resources; the model supports both natively.
## Cross-location resourcing
Geographic factors:
- Time zone — meetings hours overlap.
- Travel cost — if on-site work needed.
- Compliance — visa, tax, regulations.
- Cultural — language, workflows.
The matching engine considers location; the resource manager applies judgment.
**Common pitfalls.**
- **Skills data stale.** Resource grew but skills profile didn't update; not found by skill match.
- **Soft books that never become hard.** Pipeline of proposed assignments; never confirmed; demand artificial.
- **Overbooking ignored.** Warnings dismissed; resource burns out; PTO request blocked.
- **No demand forecast.** Hiring decisions reactive; staffing always behind.
- **Schedule board chaos.** Hundreds of resources, complex view; usability collapses; people work from spreadsheets again.
## Operational rhythm
Weekly resource managers meeting — review pending requests, debate priorities, confirm assignments. Monthly review — utilisation trends, demand forecast, hiring decisions. Quarterly — re-baseline rates, refresh skills profiles.
## Strategic positioning
Resource management is where competitive services firms win or lose. The firms that consistently allocate the right people to the right projects build reputations and margins. The firms that scramble produce slow project starts, mismatched skills, and burned-out resources. The system supports the discipline; the discipline must come from leadership and the resource management function. Without that, no software fixes the problem.
---
# Resource Scheduling Optimization (RSO)
How Microsoft's Resource Scheduling Optimization works for Dynamics 365 Field Service and Project Operations.
Source: https://www.solvingdynamics365.com/guides/resource-scheduling-optimization
Section: Customer Engagement
Published: 2026-05-01
**Resource Scheduling Optimization (RSO)** is the AI-driven scheduling engine for Dynamics 365 Field Service and Project Operations. It takes the human-intensive task of assigning work orders to technicians (or project tasks to consultants) and runs it as an optimisation problem, producing schedules that respect skills, calendars, travel time, SLAs, and many other constraints — at a speed and quality humans can't match for fleets above a few dozen resources.
## The optimisation problem
Given:
- N work orders (or project assignments), each with required skills, location, duration, time window, priority, SLA.
- M resources, each with skills, calendar, working location, working hours.
- Travel time between locations.
- Constraints — overtime allowed?, regulations on driving time?, preference for same technician returning?
…find the assignment of work orders to resources, in what order, with what start times, that maximises a multi-objective goal: meet SLAs, minimise travel, maximise utilisation, respect priorities. This is an NP-hard combinatorial problem; humans solve it heuristically (and badly at scale); RSO solves it computationally.
## The optimisation engine
Microsoft's RSO uses heuristic optimisation algorithms with configurable weights. The optimisation **objectives** are user-configurable: e.g. "75% meet SLA, 20% minimise travel, 5% maximise utilisation". Adjusting weights changes the schedule's character — high SLA weight pushes urgent jobs to the front even at the cost of more travel; high utilisation weight squeezes more jobs into fewer days.
## Optimisation scope
Each RSO run is configured with:
- **Schedule range** — the time horizon to optimise (next 7 days is common).
- **Resource pool** — which resources are eligible.
- **Work order pool** — which orders to schedule (typically all unscheduled + reschedulable).
- **Constraints** — must-respect rules (skill match, customer preference, geographic boundary).
- **Objectives and weights** — what to optimise for.
## Running RSO
A run is launched manually by a dispatcher or scheduled on a recurring basis (e.g. nightly run for the next day's plan). Results are previewed in the schedule board before being committed; dispatchers can selectively accept, reject, or modify.
## Live re-optimisation
Beyond scheduled runs, RSO supports **real-time optimisation** triggered by events — a new high-priority work order arrives, a technician calls in sick, traffic delays push back the morning route. RSO recomputes the affected slice and proposes adjustments.
## Constraints — the configuration depth
RSO supports dozens of constraints:
- Skill match (required vs preferred, proficiency level)
- Customer preferences (preferred technician, blacklisted technician)
- Geographic boundaries (driving distance limits, route territories)
- Resource time windows (working hours, breaks, lunch, end-of-shift home location)
- Multi-day jobs spanning days
- Crew jobs requiring multiple technicians
- Customer arrival windows (commit to 2-hour window, not just "today")
- Inventory on truck (technician must have the right parts)
- Travel mode (driver-bound vs flying)
**Operational realities.**
- RSO produces dramatically better schedules than manual at scale (50+ resources). The gain is real — first-time-fix rate, on-time arrival, technician utilisation all improve materially.
- RSO requires *clean* underlying data. Wrong skills, wrong calendars, wrong locations on resources sabotage the engine.
- RSO is part of the broader Field Service licence; check the SKU when planning.
## Limits
Very large fleets (1,000+ resources) or unusual industry constraints sometimes need partner schedulers (ClickSoftware, IFS, ServicePower) integrated alongside or in place of RSO.
## Where to start
Pilot RSO with a single team or region. Measure travel reduction and SLA meet rate. Tune objective weights against business priorities. Expand.
---
# Retail channel data management in Dynamics 365 Commerce
How D365 Commerce manages data flows between HQ and channels — channel databases, sync jobs, distribution schedules, and operational reliability.
Source: https://www.solvingdynamics365.com/guides/retail-channel-data-management
Section: Finance & SCM / Retail & commerce
Published: 2026-05-01
In Dynamics 365 Commerce, **channel data management** is the discipline of keeping store, POS, and online channels synchronised with the headquarters (F&O) master data and transactional records. The architecture is distributed; each channel has its own database; data flows in defined patterns. Mastering this is essential for any Commerce deployment.
**The architecture refresher.**
- **HQ** — F&O instance with master data and consolidated reporting.
- **Commerce Scale Unit (CSU)** — cloud (or on-premise) mediator.
- **Channel database** — per-store (or per-pool); local data store.
- **POS / online clients** — access channel database.
Data flows: master from HQ → CSU → channel; transactions from channel → CSU → HQ.
**What flows from HQ to channels.**
- **Products and prices** — current catalog.
- **Customers** — customer master.
- **Employees** — store associates with their permissions.
- **Tax rates and tax groups.**
- **Channels and store configurations.**
- **Promotions and discounts.**
- **Loyalty programs and customer balances.**
- **Currency and exchange rates.**
Each data type has its own sync job.
## Distribution schedules
Per-data-type schedules:
- **1010 (Channel configuration)** — infrequent.
- **1020 (Customer)** — every few hours.
- **1040 (Discounts)** — frequent (promotions change often).
- **1050 (Loyalty)** — frequent.
- **1070 (Tax)** — moderate.
- **1090 (Bar codes)** — infrequent.
The schedule configured per job; frequencies tuned to data volatility.
**What flows from channels to HQ.**
- **Sales transactions** — every sale.
- **Tender entries** — payment details.
- **Inventory movements** — receipts, transfers.
- **Customer additions** — new customers created at store.
- **Audit events** — operator activities.
The **P-job (1090 transaction collection)** pulls transactional data from CSU to HQ.
**Pull vs push.**
- **Push** — HQ initiates; sends to CSU; CSU stores; channel pulls when online.
- **Pull** — channel asks CSU; CSU asks HQ.
Most flows are push (HQ to channel). Transactional flow is pull-based (channel to CSU, then HQ pulls from CSU).
## Real-time service (RTS)
Some operations need real-time HQ:
- **Customer lookup** — current balance.
- **Inventory check** — real-time stock.
- **Order status** — cross-channel.
RTS bypasses the channel DB for live HQ queries. Slower than channel DB but always current.
**Offline mode resilience.**
- Channel DB has enough data for autonomous operation.
- Lost connection to CSU → channel runs from local DB.
- Transactions captured locally.
- Reconnection → transactions sync up.
The offline pattern is critical for retail uptime.
## Job execution
Sync jobs in F&O batch processing:
- **Job groups** — bundle related jobs.
- **Schedule** — cron-like.
- **Logging** — job execution history.
- **Error handling** — retry on failure.
Most stores have specific job groups they participate in.
## Initial download / channel reload
When a channel is first set up:
- Bulk download of all required data.
- Can take hours for large catalogs.
- Subsequent updates incremental.
For a new store, initial reload is a planned event.
**Common scenarios.**
- **New product added at HQ** — distribution job runs; appears in channel after few minutes.
- **Promotion activated** — distribution to all stores within configured frequency.
- **Price changed** — same.
- **Customer makes purchase** — captured at POS; transferred via P-job to HQ.
- **HQ receives the transaction** — posts customer ledger, item ledger, financial entries.
**Latency considerations.**
- Master data → channel: minutes to hours depending on job.
- Channel → HQ: minutes via P-job.
- Online → channel: real-time-ish.
- Real-time queries (RTS): seconds.
For end customers, "current" data within minutes is usually acceptable; not all data is real-time.
**Common pitfalls.**
- **Job schedule too infrequent.** Prices change but stores see old prices for hours.
- **Channel DB drift.** Manual changes at channel diverge from HQ; resolution painful.
- **Failed jobs unnoticed.** Sync stops; data stale; customers see wrong prices.
- **P-job backlog.** Channel-to-HQ flow stalls; transactions accumulate.
- **Initial load takes too long.** Storeopen delayed.
- **Wrong channel configuration.** Store has wrong job groups; missing data.
**Monitoring.**
- **Job execution dashboard** — last run, success / failure.
- **Channel database state** — heartbeat from each channel.
- **Transaction backlog** — pending sync.
- **RTS availability** — uptime metric.
Without monitoring, sync issues surface as user-reported problems hours or days late.
**Performance considerations.**
- **Heavy product catalogs** stress sync — design with locale / channel filtering.
- **Frequent promotion changes** drive heavy job traffic.
- **Channel database size** — for large catalogs, channel DB can be large; SSD recommended.
**Operational rhythm.**
- **Daily** — monitor sync health.
- **Weekly** — review failed jobs; fix root causes.
- **Monthly** — review job schedule appropriateness.
- **At store open** — verify channel data fresh.
## Strategic positioning
Channel data management is the operational core of D365 Commerce. The patterns are mature; the discipline is constant. Mature retail operations have dashboards, alerts, and runbooks for sync issues. The investment in setup and monitoring pays back continuously through smooth store operations and accurate cross-channel commerce. Skip this and the operations suffer in subtle, customer-visible ways — old prices, stale promotions, missed loyalty.
---
# Retail loyalty programs in Dynamics 365 Commerce — a deep dive
How D365 Commerce models loyalty — schemes, tiers, points, rewards, redemption, and the integration across channels for unified loyalty experience.
Source: https://www.solvingdynamics365.com/guides/retail-loyalty-program-deep-dive
Section: Finance & SCM / Retail & commerce
Published: 2026-05-01
Loyalty programs are central to modern retail strategy — driving repeat purchases, increasing basket size, capturing customer identity for marketing. **Dynamics 365 Commerce** has a flexible loyalty engine supporting tiered programs, multi-currency points, partner redemptions, and unified cross-channel experience. Implementing it well requires understanding both the configuration and the operational details.
**Core loyalty entities.**
- **Loyalty Program** — the named program (e.g., "VIP Rewards").
- **Loyalty Schemes** — earning rules.
- **Loyalty Tiers** — Silver / Gold / Platinum levels.
- **Reward Points** — the points/currency earned.
- **Loyalty Card** — customer's identifier in the program.
- **Loyalty Customer** — customer participating.
## Earning rules
Configurable schemes:
- **Points per dollar** — 1 point per $1 spent.
- **Tier-based earning** — Gold members earn 2× points.
- **Category-based** — bonus points on specific products / categories.
- **Promotional periods** — temporary multipliers.
- **Birthday bonus** — extra points on customer birthday month.
- **Sign-up bonus** — initial points for joining.
Each scheme has criteria (channel, product, customer attribute) and a points formula.
## Tiers
Status levels:
- Tier qualification — typically annual spend or points threshold.
- Tier benefits — earning rate, access to exclusive products, free services.
- Tier maintenance — minimum activity to retain status.
- Tier expiration — points expire if customer inactive.
Tiers create aspirational dynamics — customers strive for next tier.
## Redemption
How points become rewards:
- **Discount at POS** — points reduce purchase price.
- **Free items** — redeem points for specific products.
- **Tier upgrades** — temporary higher tier.
- **Partner rewards** — points redeemed at partner vendors.
- **Charitable donation** — points converted to charity.
The redemption catalog is configurable; rewards added and removed seasonally.
## Cross-channel
Loyalty must work seamlessly:
- **Store POS** — earn and redeem at register.
- **Online** — at e-commerce checkout.
- **Mobile app** — track points, browse rewards.
- **Call center** — agent applies points.
D365 Commerce's channel architecture ensures loyalty state synchronises across channels.
## Loyalty card
Identifies the customer:
- Physical card with number / barcode.
- Mobile app digital card.
- Phone number / email as identifier.
At POS, scan card → loyalty profile loaded → earn / redeem applied.
## Anonymous customers
Pre-registered customers:
- Earn points to a temporary card.
- Activate by registering later.
- Points carry over.
Captures customer identity from non-loyalty members.
## Promotions and loyalty interaction
Loyalty earning often interacts with promotions:
- Promotion gives discount; do customers earn points on pre- or post-discount price?
- Configurable per scheme.
- Best practice: earn on post-discount; customers grumble otherwise.
## Multi-program
A customer can be in multiple programs:
- Standard rewards program.
- Premium credit-card-linked program.
- Partner programs.
Each program has its own points; customer sees combined.
**Points expiration.**
- **Rolling expiration** — points expire 12 months after earning.
- **Annual cycle expiration** — points expire at year-end.
- **Tier-dependent expiration** — higher tiers get longer expiration.
Expiration drives engagement but frustrates if too aggressive.
## Reward catalog
Items / discounts customers can redeem:
- Stocked items with point prices.
- Vouchers (10% off).
- Experiences (free coffee, free shipping).
- Charity options.
Catalog management is operational work — keeping rewards fresh and aspirational.
**Reporting and analytics.**
- **Active loyalty members** — engaged in last 90 days.
- **Tier distribution** — % at each tier.
- **Points liability** — outstanding points × redemption value (a balance sheet item).
- **Redemption rate** — % of earned points redeemed.
- **Lift analysis** — loyalty members vs non-members spend.
These metrics drive program design decisions.
## Integration with Customer Insights
Loyalty data flows to Customer Insights:
- Profile enriched with loyalty status.
- Segments by tier, by activity.
- Journey orchestration triggered by loyalty events (tier upgrade, points expiring).
The combination of Commerce + Customer Insights produces personalised loyalty marketing.
**B2C considerations.**
- **GDPR compliance** — loyalty data is personal data.
- **Right to forget** — anonymise loyalty history on request.
- **Consent** — explicit opt-in.
**Common pitfalls.**
- **Overcomplicated tier structure.** Too many tiers; customers confused.
- **Reward catalog stale.** Same rewards for years; engagement drops.
- **Points liability ignored.** Significant balance sheet item; financial reporting must account.
- **Cross-channel sync fails.** Customer earns online but POS doesn't see it; frustration.
- **Tier requalification surprises.** Customer drops tier unexpectedly; complaints.
- **Promotion / loyalty interaction unclear.** Earning rate ambiguous; trust eroded.
**Operational rhythm.**
- **Daily** — monitor for anomalies (point gaming, fraud).
- **Monthly** — segment analysis, marketing campaigns.
- **Quarterly** — catalog refresh.
- **Annual** — tier recalibration; expiration runs.
## Strategic positioning
Loyalty is one of retail's strongest competitive tools when done well. D365 Commerce's loyalty engine is configurable and capable; the design (tier structure, earning rules, rewards) matters more than the underlying mechanics. Invest in research before launching: customer preferences, competitive benchmarks, financial modelling of liability. A well-designed program drives material revenue uplift; a poorly designed one frustrates customers and produces a balance sheet headache without commercial benefit.
---
# Retry policies with Azure services for Dynamics 365 integrations
How to implement retry policies in Azure-based Dynamics 365 integrations — exponential backoff, idempotency, circuit-breaker integration.
Source: https://www.solvingdynamics365.com/guides/retry-policies-with-azure-services
Section: Integrations / Resilience & ops
Published: 2026-05-01
Network blips, rate limiting, downstream slowness — transient failures are inevitable in distributed systems. **Retry policies** absorb these failures by trying again with appropriate backoff. Implemented well, they make integrations resilient; implemented badly, they amplify failures into incidents.
**Transient vs permanent failures.**
- **Transient** — temporary; succeeds on retry. Network glitch, rate limit, brief downstream outage.
- **Permanent** — won't succeed however many retries. Schema mismatch, auth failure, business validation failure.
Retry only transients; permanent failures need different handling (alert, dead-letter, manual).
## Failure classification
Decide per error type:
- **HTTP 5xx** — usually transient.
- **HTTP 429 Too Many Requests** — definitely transient; respect Retry-After.
- **HTTP 4xx** — usually permanent (validation, auth).
- **HTTP 408 Request Timeout** — transient.
- **Connection errors** — transient.
- **Specific application errors** — depends.
The classifier is critical; misclassifying causes infinite retry of permanent failures.
**Backoff strategies.**
- **Fixed delay** — wait N seconds, retry.
- **Linear backoff** — N, 2N, 3N seconds.
- **Exponential backoff** — N, 2N, 4N, 8N seconds.
- **Exponential with jitter** — exponential + random variance.
Exponential with jitter is modern default; prevents thundering herd.
**Why jitter.**
- Without jitter, all retries synchronise.
- Many clients failing simultaneously retry at the same moment.
- Spike overwhelms the recovering downstream.
Random jitter spreads retries; smoother recovery.
**Max retries.**
- **Bounded** — give up after N attempts.
- **Unbounded** — retry forever (rare; usually wrong).
Bounded count protects against permanent failures masquerading as transient.
## Retry-After header
When server says how long to wait:
- HTTP response includes `Retry-After: 30` (30 seconds) or absolute time.
- Honour it; don't retry sooner.
- Common in 429 (rate limit) responses.
Ignoring Retry-After can extend the throttling.
**Implementation libraries.**
- **Polly (.NET)** — declarative retry policies.
- **Resilience4j (Java)** — similar.
- **AxiosRetry (Node)** — for axios HTTP client.
- **Azure SDK** — built-in retry on many operations.
Choose mature library; rolling your own retry is error-prone.
**Polly example.**
```csharp
var retryPolicy = Policy
.Handle()
.Or()
.WaitAndRetryAsync(
retryCount: 5,
sleepDurationProvider: attempt =>
TimeSpan.FromSeconds(Math.Pow(2, attempt)) +
TimeSpan.FromMilliseconds(jitterer.Next(0, 1000))
);
await retryPolicy.ExecuteAsync(async () =>
await client.PostAsync(url, content));
```
Five retries with exponential backoff and jitter; handles common transient cases.
## Idempotency
Critical for retries:
- Retry might succeed after thinking it failed.
- Duplicate processing on receiving side.
- Idempotency means same input → same outcome, regardless of count.
Patterns:
- **Idempotency-Key header** — receiver dedupes by key.
- **Natural keys** — operation tied to unique business identifier.
- **State-based** — set state idempotently.
Without idempotency, retries cause data corruption.
## Retry + circuit breaker
Combined patterns:
- **Retry** handles individual call failures.
- **Circuit breaker** handles sustained failure patterns.
Wrap retry inside circuit breaker:
- Retries happen within circuit-closed state.
- When too many failures total, circuit opens; retries stop.
- Periodic test to re-open if downstream recovered.
Covered in [[circuit-breakers-in-dynamics-365-integrations]].
**Per-service retry policies.**
- **Dataverse** — handle 429s, 5xx; respect Retry-After.
- **Service Bus** — built into SDK; configurable.
- **Azure Storage** — built-in retries; can override.
- **External APIs** — per-API characteristics.
Each service may need tuned policy.
## Retry budget
Limit total retry effort:
- Per-request retry count (5 attempts).
- Per-time-window total retries (1000 retries per minute across all requests).
Without budget, retry storms exhaust resources.
**Retry observability.**
- **Retry count metric** — how often retries happen.
- **Success-after-retry rate** — what % succeed.
- **Failures after exhausted retries** — what truly fails.
These metrics reveal integration health beyond just success/failure.
**Distributed retry.**
- Multiple consumers each retry.
- Aggregate retry traffic significant.
- Coordination via shared rate limiter helpful.
For high-scale, single-client retry isn't enough.
## Dead-letter on exhaustion
When all retries fail:
- Message → dead-letter queue.
- Alert raised.
- Operator inspects.
- Manual resubmission or remediation.
Closes the loop on retry-failed messages.
**Common pitfalls.**
- **No retry.** First transient failure becomes user-visible.
- **Naive retry.** No backoff; tight retry loop hammers downstream.
- **Retry permanent failures.** Forever; resource exhaustion.
- **Idempotency forgotten.** Retries cause duplicates.
- **Throttling ignored.** Retries faster than allowed; permanently throttled.
- **No timeout** on individual attempts. Stuck retry; resource leak.
- **Retry on wrong layer.** Application retries when SDK already retried; effective retry count multiplies.
**Best practices.**
- **Use library** — Polly, Resilience4j, etc.
- **Classify errors** — transient vs permanent.
- **Exponential + jitter.**
- **Bounded count.**
- **Timeout per attempt.**
- **Observable metrics.**
- **Dead-letter on exhaustion.**
- **Idempotent receivers.**
## Strategic positioning
Retry policies are foundational reliability infrastructure. Mature integrations have considered retry policies per integration; immature ones have ad-hoc or no retries. The investment is modest — using libraries, classifying errors, building monitoring. The benefit is integrations that survive transient issues without operational intervention.
For architects:
- Default to library-based retry.
- Document policy per integration.
- Monitor retry metrics.
- Combine with circuit breaker, dead-letter, idempotency.
Production-grade integration architecture has all these patterns working together. Skipping any one weakens the whole. Invest in the foundation; benefit through every integration thereafter.
---
# Revenue recognition for services firms on Dynamics 365
How revenue recognition works for professional services on Dynamics 365 — time-and-materials, fixed-price, and retainer contracts.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-for-professional-services-revenue-recognition
Section: Industries / Professional services
Published: 2026-09-02
Services firms recognise revenue as work is performed, not when the invoice goes out. Under IFRS 15 and ASC 606 that principle is formal: identify the performance obligations, allocate the transaction price, and recognise as each obligation is satisfied — over time for most services. Dynamics 365 supports this well or barely depending on which product and which deployment mode a firm is on, and that choice is often made by the delivery team before finance has seen it. This guide sets out what each option actually does.
## The three contract shapes
**Time and materials.** Revenue equals approved hours times the contract rate. Recognition follows delivery; the only timing question is whether to accrue revenue on approved-but-uninvoiced time at period end.
**Fixed price.** The firm commits to an outcome for a price. Revenue is recognised over time by progress — percentage of completion based on cost or hours — or, less often, at milestones. This is where systems differ most.
**Retainers and subscriptions.** A fixed fee per period for a capacity or a service. Recognised evenly over the period regardless of hours delivered, with deferred revenue for advance billing.
Most firms have all three, often on the same client.
## Project Operations: it depends on the deployment
**Lite deployment** (Dataverse only, with a separate accounting system) manages contracts, time, expense, and invoicing. It does not do revenue recognition. Invoices are the only financial output, so a fixed-price project billed at three milestones shows three lumps of revenue in whatever ledger the invoices land in. Firms on Lite that need over-time recognition do it in the accounting system or in a spreadsheet from Project Operations' actuals. That is workable for a small firm with mostly T&M work and unacceptable for one with material fixed-price revenue and an auditor.
**Project Operations with Finance and Operations** (the resource-based and stocked deployments) posts actuals into the F&O project accounting module, and that is where recognition lives:
- **T&M**: revenue accrues when time and expense post, on the accrue-revenue setting of the project group, and reverses when the invoice posts. Unbilled revenue sits on the balance sheet between the two. Works out of the box.
- **Fixed price**: the project uses an estimate project with a completion method — completed contract or percentage of completion, with the percentage derived from cost or from a manually entered completion. Period-end estimate runs post revenue, WIP, and cost of sales. This is the real percentage-of-completion engine and it is capable, but it needs finance to configure cost templates, define which cost lines count as progress, and run the estimates as part of close.
- **Retainers**: modelled as fixed-price with on-account billing, or increasingly through F&O's **subscription billing** feature, which handles deferrals and recurring invoices and is Microsoft's direction after the older revenue recognition feature was marked for deprecation.
The [deployment types](https://www.solvingdynamics365.com/guides/project-operations-deployment-types) guide covers the choice; the recognition requirement should be one of the inputs to it, and often is not.
## Business Central
Business Central's projects (formerly jobs) have **WIP methods** per project: cost value, sales value, cost of sales, percentage of completion, and completed contract. The WIP calculation batch posts the accounting entries at period end. It is a proper over-time recognition mechanism for an SMB firm and the [WIP and recognition for jobs](https://www.solvingdynamics365.com/guides/wip-and-recognition-for-jobs-in-bc) guide walks it. Its limits: one method per project, progress driven by cost or a manually entered percentage, and no concept of performance obligations below the project. Firms whose contracts bundle several obligations at different progress rates split them into separate projects or tasks with separate WIP treatment.
## What the standards change about contract design
IFRS 15 and ASC 606 are usually treated as an accounting problem. In Dynamics 365 they are a data-model problem, because recognition is driven by the structure of the contract lines.
- **One performance obligation per contract line.** In Project Operations, the contract line is the unit that carries billing method, price, and the mapping to project tasks. A fixed-price line covering two deliverables with different completion profiles cannot be recognised correctly; split it.
- **Allocation of discounts.** A bundled discount must be allocated across obligations. Neither Project Operations nor BC allocates automatically across lines; the allocation is done when the contract is priced and entered per line.
- **Variable consideration** — success fees, penalties — has no first-class home. Treat it as a separate line with its own recognition treatment, or hold it outside the system until it is probable.
- **Contract modifications** are the hard case. A change order that adds scope to an existing fixed-price line changes the percentage of completion retrospectively. Project Operations handles it through the contract line's revised value and the estimate project picking up the new total; it does not restate prior periods, which is usually correct under the standard but needs finance to be looking.
## Month-end sequence
For firms on Project Operations with F&O, the close order that avoids rework: approve all time and expense, post them to F&O, run project invoicing, run the estimate process for fixed-price projects, review WIP and unbilled revenue by project, then close the period. Running estimates before all time is posted understates progress and creates a correction next month.
For BC firms: post all project journals, run WIP calculation, review, post WIP to GL, close.
## What needs a partner or a spreadsheet
Multi-element arrangement allocation with standalone selling prices, automated contract modification accounting, and disclosures such as remaining performance obligations are not in any Dynamics 365 product for services contracts. Larger firms use a revenue-management ISV or handle it in the consolidation layer. Smaller firms keep a schedule. Either way, the decision to do fixed-price work at scale is a decision to run the estimate process properly, and firms that skip it discover the gap at their first audit rather than their first month-end.
---
# Reverse and undo in Business Central
How Business Central handles corrections — undo shipment, undo receipt, reversing journals, correcting credit memos, and the audit trail they leave.
Source: https://www.solvingdynamics365.com/guides/reverse-and-undo-in-business-central
Section: Business Central / Finance & accounting
Published: 2026-05-01
Mistakes happen. A sale gets posted at the wrong price; a shipment goes out incomplete; a journal entry hits the wrong account; an invoice is sent to the wrong customer. Business Central offers several mechanisms to correct posted transactions while maintaining an audit trail — but the right mechanism per scenario isn't always obvious.
## Posted documents are immutable
A foundational principle: once a sales invoice, shipment, journal, or other transaction is posted, the original record cannot be edited. Corrections happen through reversing or correcting transactions that preserve history.
## Undo shipment
Posted sales shipments and posted purchase receipts can be *undone* under certain conditions. The **Undo Shipment** action on a posted sales shipment line reverses the inventory movement, returns the items to stock, and marks the line as undone. The original posted shipment remains visible in history; the undo creates a counter-entry. Conditions:
- Item hasn't been invoiced yet (still open inventory entry).
- Item hasn't been further processed (sold to another customer, transferred, etc.).
- No item charge has been applied.
Undo Receipt works the same way on the purchase side.
## Cancel posted invoice
A posted sales invoice or purchase invoice has a **Cancel** action that creates a corresponding credit memo and applies it, effectively reversing the financial transaction. The original invoice remains; the credit memo is its formal reversal. Audit trail shows both with cross-references.
## Correct posted invoice
A more powerful pattern. The **Correct** action on a posted sales invoice:
1. Creates a credit memo reversing the original.
2. Creates a *new* unposted sales invoice as a copy of the original.
3. The user edits the copy to the correct values.
4. The user posts the corrected invoice.
The result: the original (wrong) invoice, a credit memo that reverses it, and a new (right) invoice. Three documents in the audit trail tell the full story.
## Reversing journal entries
Posted G/L journals can be reversed:
- **Reverse Transaction** — creates a journal entry that exactly negates the original.
- **Reverse Register** — reverses an entire batch of journal entries posted in one run.
Both leave the original visible and add the reversal as a separate posting. Useful for misclassified entries, wrong amount, wrong account.
## Recurring vs reversing journals
Different concept: a **reversing recurring journal** is configured to automatically post the reverse next period (the standard accrual pattern). Not a correction tool — it's a normal accounting mechanism.
## Reversing customer / vendor applications
When a payment was applied to the wrong invoice (or wrong customer), the **Unapply Customer / Vendor Entries** action reverses the application without reversing the underlying payment. Re-apply correctly afterwards. Useful for AR/AP cleanup.
**What can't be reversed easily.**
- **Cost-adjustment cascades** — once Adjust Cost — Item Entries has propagated cost into many outbound entries, reversing the originating inbound requires substantial work.
- **VAT-period-closed transactions** — corrections may require special VAT correction journals per country regulation.
- **Statutory-locked period** — reversing transactions in a closed period is restricted; may require period re-opening (audit-trail event) or posting the reversal in the current period.
## Audit trail
Every reversal, undo, and correction is logged. The **Change Log** (if enabled) records the actions; posted documents carry references to their reversals; the GL register shows the original and the reversal side by side. Auditors can reconstruct what happened cleanly.
**Common pitfalls.**
- **Deleting unposted documents thinking they're posted** — unposted documents can be deleted outright, but a deleted draft leaves no trail. Be sure of the state before deleting.
- **Reversing the wrong way** — posting a credit memo to "fix" an invoice but not applying it to the original leaves both open. Use Cancel / Correct for proper linkage.
- **Reversing in a closed period** — runs into period-control errors. Reverse in the current period instead.
## Operational discipline
Train users on the right mechanism per scenario. Mistakes are normal; messy mistakes are avoidable.
---
# Ribbon and command bar customisation
How to add, remove, and modify commands on the model-driven app command bar — the modern command designer and the ribbon-XML legacy.
Source: https://www.solvingdynamics365.com/guides/ribbon-and-command-bar-customisation
Section: Customer Engagement / Dataverse platform
Published: 2026-05-01
The **command bar** (formerly called the **[ribbon](https://www.solvingdynamics365.com/glossary/ribbon)**) is the row of actions at the top of every model-driven app page — Save, New, Delete, Email, Export, custom actions specific to the app. Customising it lets you surface organisation-specific functions in the right place. The modern path is friendly; the legacy ribbon-XML pattern is still relevant for older customers.
## The modern command designer
Microsoft now provides a graphical **command designer** inside the modern maker portal. From the maker portal, navigate to a table's command bar; the designer shows the existing commands and lets you:
- **Add a command** — name, icon, label, and the action it performs.
- **Edit a command** — change label, icon, visibility, action.
- **Delete or hide** an existing command (without affecting other apps).
- **Set visibility rules** — show / hide the command based on field values, user role, or business state.
- **Set enabled rules** — grey out the command unless conditions are met.
- **Sort the order** in which commands appear.
## Action types
A command can do one of several things:
- **Run a JavaScript function** — the classic ribbon pattern; calls a custom function in a web resource.
- **Run a Power Fx formula** — newer pattern; the action is expressed in Power Fx (the same language as canvas apps).
- **Run a Power Automate flow** — trigger a cloud flow with the current record context.
- **Open a Power App** — launch a canvas or custom app with parameters.
- **Open a URL** — navigate to an external page.
## Visibility and enabled rules
Both rules are Power Fx expressions evaluating in the form's context:
- **Visibility** — `Self.Selected.AllItems.Status = "Active"` shows the command only for active records.
- **Enabled** — `User().Email = "..."` enables only for specific users (rare; usually role-based instead).
- **Run command** — what happens when clicked.
The Power Fx integration replaces what previously required JavaScript display rules and enable rules.
## Where commands appear
The same table can have commands in different contexts:
- **Main form** command bar — on the record-level view.
- **List view** command bar — at the top of the table's grid.
- **Subgrid** command bar — embedded in a parent form's subgrid.
- **Associated view** command bar — when viewing related records.
Each context has its own command set; you can have a command on the main form but not in the list view, or vice versa.
## App-specific commands
Modern command customisation can be **app-scoped** — a command appears in App A but not App B, even on the same table. Useful when multiple apps share a table but need different actions.
## The ribbon-XML legacy
Older customisations use **ribbon XML** — verbose XML files defining commands, display rules, enabled rules, library references. Ribbon XML is still supported but no longer recommended for new work; migrate to the modern command designer when possible.
**Common patterns.**
- **One-click custom action** — "Generate Quote PDF", "Send to ERP", "Mark as VIP", "Calculate Discount" — buttons that run a flow or script.
- **Hide standard commands** — for security or simplification (hide Delete from non-admin users).
- **Conditional surface** — "Approve" button visible only when status is Pending Approval AND user is in Approvers role.
- **App-specific surfacing** — "Send Quote" in the Sales app but not in the Service app on the same Quote record.
**Limits.**
- **No nested submenu beyond one level** — keep commands flat.
- **Custom icons** are limited to predefined icon set; uploading bespoke icons is supported but with effort.
- **Performance** — many commands with complex Power Fx rules slow form load. Audit.
**Common pitfalls.**
- **Hiding standard commands that users need** — users complain "I can't find Save anymore". Always test as the user.
- **Visibility rules that don't account for record states** — commands invisible when they should be visible.
- **Cross-app surprises** — adding a command in one app accidentally affects another. Use app-scoped commands.
## Operational discipline
Document the command catalogue per app per table. Audit annually — retire commands that aren't used; surface new ones for emerging workflows. Train users when adding meaningful new commands.
---
# Risk management on Dynamics 365 projects
How to identify, track, and mitigate risks on Dynamics 365 implementations — the risk register, scoring framework, escalation.
Source: https://www.solvingdynamics365.com/guides/risk-management-on-dynamics-365-projects
Section: Implementation / Project execution
Published: 2026-08-11
Dynamics 365 implementations fail in predictable ways. Data migration that's harder than scoped. Integration complexity discovered too late. Change management neglected. Customisation that breaks at the next release wave. Scope creep that eats the budget. Each failure mode is preventable; collectively, ignoring risk management is the dominant cause of project disappointment.
**The risk register.**
A **risk register** is the central document tracking risks:
- **Risk title** — short description.
- **Category** — technical, organisational, financial, scope, resource, vendor.
- **Description** — what could happen?
- **Likelihood** — Low / Medium / High.
- **Impact** — Low / Medium / High.
- **Risk score** — likelihood × impact, expressed as Low/Medium/High/Critical.
- **Mitigation** — what we're doing to reduce likelihood or impact.
- **Contingency** — what we'll do if it happens anyway.
- **Owner** — accountable person.
- **Status** — Open, In Mitigation, Closed, Realised.
- **Next review date** — when to revisit.
The register lives in a shared location (Azure DevOps, SharePoint, project tool); it's reviewed in every steering committee meeting.
**Common Dynamics 365 risks.**
**Data migration.**
- Source data is dirtier than initially assessed.
- Volume is higher than estimated.
- Country-specific data quality variances.
- Inability to extract historical detail from legacy.
Mitigation: deep dive into source data early; pilot migration cycles; involve data quality team from kick-off.
**Integration complexity.**
- Late discovery of integration requirements.
- Partner system APIs are weaker than expected.
- Performance at production scale.
- Vendor APIs change during the project.
Mitigation: integration discovery in the analysis phase; performance testing at scale before UAT; vendor contracts that include API stability commitments.
**Customisation depth.**
- More customisations needed than estimated.
- Customisations conflict with release-wave updates.
- Per-tenant extensions vs AppSource trade-off late.
Mitigation: rigorous fit-to-standard analysis; commit to Power Platform-first; budget for release-wave validation.
**Resource availability.**
- Key partner consultant leaves mid-project.
- Customer SME unavailable during critical phase.
- Specialist skills (specific localisation, complex finance) hard to find.
Mitigation: identify single-point-of-failure individuals; ensure backup; cross-train.
**Change management.**
- User adoption resistance.
- Training delivered too early / too late.
- Sponsor disengagement.
- Communication gaps.
Mitigation: explicit change management workstream; sponsor accountability; user-centric design throughout.
**Scope creep.**
- Stakeholders adding requirements during build.
- "Just one more" customisations.
- Re-org changes scope mid-project.
Mitigation: rigorous change-control process; sponsor sign-off on scope changes; budget contingency.
**Vendor dependency.**
- ISV solution doesn't deliver promises.
- Partner exits the engagement.
- Microsoft platform deprecates a feature you depend on.
Mitigation: vendor due diligence; contractual remedies; backup vendors identified; exit clauses.
**Scoring framework.**
A simple 3×3 likelihood × impact matrix:
- **High likelihood × High impact** = **Critical** — daily focus.
- **High × Medium** or **Medium × High** = **High** — weekly focus, mitigation in progress.
- **Medium × Medium** = **Medium** — monthly review; mitigation as bandwidth allows.
- **Low** in any combination = **Low** — tracked but minimal active work.
Critical risks dominate steering committee discussion. Realised risks (a risk that's happened) get explicit incident response, with lessons captured for future projects.
**Risk lifecycle.**
- **Identification** — risks identified continuously; not just at kick-off. New phases reveal new risks.
- **Assessment** — scored against likelihood and impact.
- **Mitigation** — actions assigned to owners; mitigation work tracked.
- **Monitoring** — periodic review; status updates.
- **Closure** — risks resolved get closed; documentation captured.
- **Realisation** — when a risk happens, it transitions to incident response; lessons feed back into risk practice.
**Steering committee involvement.**
The risk register is on every steering committee agenda. Top risks discussed; mitigation status reviewed; escalations made to leadership. Without steering involvement, risks are noted but not acted on.
**Mitigation vs contingency.**
- **Mitigation** — actions taken to *reduce likelihood or impact* before the risk happens.
- **Contingency** — actions to take *if* the risk happens.
Both matter. A risk with strong mitigation may not need contingency; a risk with no mitigation absolutely needs contingency.
**Risk communication.**
- **Transparency with sponsors** — sponsors who hear about risks late, after they realised, lose trust. Communicate early and often.
- **Risk-adjusted timelines and budgets** — contingency reserves explicitly allocated for risks.
- **No surprises** — sponsors should never be surprised by realised risks; the risk register should have flagged them.
**Common pitfalls.**
- **No risk register** — risks are tribal knowledge; nothing tracked.
- **Risk register without review** — file maintained but never opened.
- **Mitigation as documentation only** — risks listed but no actual mitigation work happening.
- **Politeness over honesty** — risks downplayed to avoid difficult conversations.
- **Late identification** — risks recognised only after they realised.
## Operational reality
Risk management is unglamorous discipline. Adopt it from kick-off; maintain it through go-live; review it in steady-state operations. The cost is small; the value compounds across every meaningful surprise prevented.
---
# Risk register for Dynamics 365 projects
How to maintain an effective risk register for a Dynamics 365 implementation — risk identification, scoring, mitigation, monitoring.
Source: https://www.solvingdynamics365.com/guides/risk-register-for-dynamics-365-projects
Section: Implementation / Project execution
Published: 2026-05-01
Every Dynamics 365 implementation has risks — data quality, scope creep, key person dependence, integration complexity. A **risk register** systematically captures these, tracks mitigation, and surfaces what needs attention. Done well, it's a working tool; done poorly, it's a forgotten document.
**Risk vs issue.**
- **Risk** — something that might happen.
- **Issue** — something that has happened.
Risks become issues when they materialise. The register tracks risks; an issue log tracks issues. They flow into each other.
**Common Dynamics 365 project risks.**
- **Data quality** — migration data dirty.
- **Stakeholder availability** — SMEs over-allocated.
- **Scope creep** — requirements keep growing.
- **Integration complexity** — external system integration harder than expected.
- **Customisation overruns** — code more complex than estimated.
- **Vendor performance** — partner under-delivers.
- **Key person dependency** — one person knows critical area.
- **Change resistance** — users won't adopt.
- **Compliance gaps** — regulatory needs missed.
- **Performance under load** — slow at scale.
- **Skill gaps** — team lacks specific expertise.
Most projects share many of these.
## Risk register structure
Per risk:
- **ID** — unique identifier.
- **Description** — what could go wrong.
- **Category** — technical, business, operational, etc.
- **Probability** — how likely (1-5 or H/M/L).
- **Impact** — how severe (1-5 or H/M/L).
- **Risk score** — Probability × Impact.
- **Mitigation strategy** — how to reduce probability or impact.
- **Contingency** — what to do if it happens.
- **Owner** — accountable person.
- **Status** — Open, Mitigated, Closed, Realised.
- **Last updated.**
Standard columns; consistent across projects.
**Risk identification techniques.**
- **Brainstorming** — team session listing concerns.
- **Lessons learned** — from prior projects.
- **Industry knowledge** — common Dynamics 365 risks.
- **Pre-mortem** — "imagine the project failed; why?"
- **Stakeholder interviews** — different perspectives.
Identification isn't one-time; ongoing throughout project.
**Risk scoring.**
- **Probability** — 1 (rare) to 5 (almost certain).
- **Impact** — 1 (minor) to 5 (catastrophic).
- **Score** — multiplied; 1-25 range.
Color coding:
- **Red** (15-25) — critical; active management.
- **Amber** (5-14) — significant; monitor.
- **Green** (1-4) — low; awareness only.
The colour coding helps prioritisation.
**Mitigation strategies.**
- **Avoid** — change plan to eliminate the risk.
- **Reduce** — actions to lower probability or impact.
- **Transfer** — insurance, contractual.
- **Accept** — acknowledge; no action.
Most risks get reduced; some accepted; few avoided entirely.
## Per-risk action
What specifically:
- "Engage data quality team early."
- "Hire backup architect for redundancy."
- "Build integration prototype in Week 4."
- "Include compliance review in design phase."
Vague mitigations don't change anything; specific actions do.
**Risk review cadence.**
- **Weekly** at PMO level — full register.
- **Monthly** at steering — top risks.
- **Per phase transition** — comprehensive review.
- **Ad-hoc** when new risks identified.
Without cadence, register becomes static.
**Trending.**
- **New risks** — what surfaced this period.
- **Closed risks** — what's resolved.
- **Escalating risks** — increasing in score.
- **De-escalating** — getting better.
Trend tells more than snapshot.
## Top 10
Focus mechanism:
- The top 10 risks (by score) discussed each meeting.
- Lower-scored risks listed but not focal.
- Movement in / out of top 10 is itself signal.
Manageable scope for attention; comprehensive coverage maintained.
## Risk owners
Each risk has a person:
- Responsible for mitigation execution.
- Accountable for status updates.
- Has authority and resources to act.
Without owners, risks have no one acting on them.
## Materialised risks
When risk becomes issue:
- Move to issue log.
- Mitigation becomes resolution plan.
- Track separately as issue.
- Post-incident learn for future projects.
**Communicating risks.**
- **Steering committee** — top risks, status, trends.
- **Stakeholders** — risks affecting them.
- **Partners** — joint mitigation discussion.
Risk transparency builds trust; hiding risks always backfires.
**Risk register tools.**
- **Excel / spreadsheet** — common, fine for small projects.
- **Azure DevOps** — integrated with backlog.
- **Project management tools** — Smartsheet, Jira, etc.
- **Risk-specific tools** — for enterprise.
Tool less important than discipline.
**Common pitfalls.**
- **Register not maintained.** Created once; ignored.
- **All risks scored "amber".** No prioritisation.
- **No owners.** Risks float; nobody acts.
- **Mitigations vague.** "We'll watch this" isn't a mitigation.
- **No escalation.** High-score risk stays at PMO; steering surprised.
- **Closure without verification.** "Mitigated" without confirming.
- **Risk theatre.** Performative discussion; no real action.
**Risk culture.**
- **Reward risk surfacing** — don't shoot messenger.
- **Open discussion** — risks aren't fault.
- **Honest scoring** — don't downplay to look good.
- **Action on top risks** — visible response.
The culture determines whether the register is a useful tool or a checkbox.
## Lessons learned
Post-project:
- Which risks materialised? Why didn't mitigation work?
- Which risks didn't? Was mitigation good or risk overstated?
- What risks weren't on register? Why not identified?
Inputs to next project's risk identification.
## Strategic positioning
Risk management is one of the strongest predictors of project success. Mature implementations have active risk registers; struggling projects have either no register or a register that exists but doesn't drive action.
For project leaders:
- Build register early.
- Maintain weekly.
- Drive mitigation actions.
- Surface top risks visibly.
- Reward honest reporting.
The investment is meeting time and tool maintenance; the benefit is fewer surprises and earlier intervention on issues. The teams that take risk management seriously have boring delivery; the teams that don't have dramatic delivery — and not in a good way.
---
# Role centers and personalization in Business Central
How Business Central's role-tailored experience works — role centers, profiles, personalization, and tenant-wide customisation.
Source: https://www.solvingdynamics365.com/guides/role-centers-and-personalization-in-business-central
Section: Business Central / Admin & ops
Published: 2026-05-01
One of the things that makes Business Central feel different from generic enterprise software is its **role-tailored experience**. Every user opens to a *role center* — a home page curated for what they do. Behind it sits a layered customisation model that lets each user, each role, and the whole tenant shape the interface.
## Role centers
A **role center** is a Business Central page customised as the user's home screen, showing what matters for their job: relevant cues (open orders, overdue invoices, items below safety stock), shortcut actions, embedded charts, frequently-used reports, and notifications. Microsoft ships role centers for common roles — Business Manager, Accountant, Order Processor, Sales Manager, Purchasing Agent, Production Planner, Warehouse Worker, Project Manager, IT Manager — and customers extend or build their own.
## Profiles
A **profile** is the assignment of a role center to a category of users. Each profile has a code, a role center, default permissions, default settings, and a description. Users are assigned a profile through the user setup; switching profile changes the role center and the available menu.
## Personalization
Within their assigned role, individual users **personalize** their experience: hide columns on lists they don't use, reorder columns, change column widths, hide fields on cards, hide cues on the role center, add favourites to navigation. Personalization is per-user and per-page; it doesn't affect other users.
## Designer
A more powerful customisation tool, **Designer**, lets users with appropriate permissions:
- Add or hide fields, columns, parts, FactBoxes on pages.
- Move items between sections.
- Add custom captions.
- Save as a tenant customisation (affecting all users of the page) or as a personal customisation.
Designer customisations are stored as **page metadata extensions** that survive upgrades. Heavy customisation is better delivered as an AL extension; Designer is for lightweight tweaks.
## Tenant customisation
A super-user can take their personalized layout and **save it as a tenant default** — every user of that profile inherits the change. This is how administrators tune the standard experience for their company without involving a developer.
## Cues and headlines
The role center features prominently:
- **Cues** — large numeric tiles showing key counts (open orders, items needing approval, overdue invoices). Each cue is filterable and clickable to drill into the underlying list.
- **Headlines** — a horizontal banner showing personalised notifications, AI insights, or business-specific alerts.
- **Charts** — small embedded Power BI or built-in chart visualisations.
- **Activities** — task lists showing pending items.
## Mobile
Role centers render on mobile through the Business Central mobile app. The layout reflows for small screens; cues and key actions remain visible.
## The boundary
Role centers and personalisation are *configuration*. For genuinely new business logic — calculated fields, custom workflows, new tables — write an AL extension. The two layer cleanly: extensions add the structure, role centers and Designer expose it the way users want to see it.
## Operational discipline
Most BC implementations underuse the role-center investment. Spend deliberate time per role configuring the cues, charts, and shortcuts that match daily work. Adoption improves dramatically.
---
# Routing rules in Dynamics 365 Customer Service
How cases and conversations route to agents in Customer Service — basic routing, Unified Routing, classification, and skill-based assignment.
Source: https://www.solvingdynamics365.com/guides/customer-service-routing-rules
Section: Customer Engagement / Customer Service
Published: 2026-05-01
How a case or conversation gets to the right agent is the question every Customer Service implementation grapples with. Dynamics 365 ships two routing engines — a simple, legacy one and a modern, AI-aware one — and customers should adopt the modern one.
## Basic routing rules
The legacy mechanism is a list of **basic routing rule sets** with conditional logic that assigns incoming cases to queues based on attributes (priority, channel, product line). Basic rules are easy to set up, run synchronously on case creation, and don't consider agent capacity or skills. They're still in use on simpler tenants but are increasingly being replaced.
## Unified Routing
The modern engine. Unified Routing handles **cases**, **conversations** (chat, voice, SMS, social), **records** of any other entity, and **emails** through a single configuration. It runs in three phases:
1. **Classification.** Incoming work is enriched with derived attributes: priority based on customer tier, language detected by AI, sentiment from the email body, product category from the subject. Classification rules are configured per channel and can call AI models.
2. **Routing rule sets.** A set of rules evaluates the classified work and assigns a **queue** — typically a queue per skill area, region, or service tier.
3. **Assignment.** Within the queue, an **assignment method** picks an agent: longest-idle, round-robin, highest-priority-first, or **percentage-based** for blended skills. Assignment honours **agent capacity** (how many active items each agent can handle), **operating hours**, and **presence status**.
## Skills
A skills hierarchy is configurable; agents are tagged with skills and proficiency levels. Routing rules can require a skill match — only Spanish-speaking agents handle Spanish chats; only senior agents handle escalations. Skills are also AI-recommended based on conversation analysis.
## Capacity profiles
A **capacity profile** declares how much work an agent can hold simultaneously per channel — typically 1 voice call, 3 chats, 5 cases. Routing respects the profile and queues work that exceeds capacity.
## Overflow and escalation
Time-based overflow re-routes work that's waited too long; manual reassignment by supervisors covers the edge cases.
## Telemetry
Real-time supervisor dashboards show queue depths, longest waits, agent occupancy, and SLA risk, with the ability to intervene.
## Migration
Microsoft is gradually deprecating basic routing in favour of Unified Routing. New implementations should configure Unified Routing from day one.
## Configuration discipline
Routing complexity grows quickly — one rule turns into twenty. Start with a small skill taxonomy, a flat queue topology, and a handful of routing rules; add complexity only when measured queue wait times or quality metrics demand it.
---
# Routings and capacity centers in Business Central manufacturing
How Business Central models manufacturing operations — routings, work centers, machine centers, capacity calendars, and cost flow into production.
Source: https://www.solvingdynamics365.com/guides/routings-and-capacity-centers-in-bc-manufacturing
Section: Foundations
Published: 2026-05-23
Manufacturing in Business Central Premium centres on three master data objects: **production BOMs** (what to make from what), **routings** (the steps to make it), and **work / machine centers** (where the steps happen). The routings and capacity model is what turns inventory operations into a manufacturing system.
## Work centers
A **work center** is an organisational unit that performs operations — a department, a cell, or a logical grouping of capacity. Each carries:
- **Code and Name** — the identifier.
- **Capacity** — how many parallel runs can happen (e.g. 2 simultaneous operations).
- **Efficiency** — productivity adjustment (90% means 90% of nominal).
- **Shop Calendar Code** — when the work center is open (Mon-Fri 8am-5pm, etc.).
- **Direct Unit Cost** — internal cost rate per time unit.
- **Indirect Cost %** — overhead applied to direct cost.
- **Posting groups** — for GL accounting of consumed capacity.
- **Unit of Measure** — how time is measured (typically minutes or hours).
## Machine centers
A **machine center** is a more granular capacity unit — a specific machine, lathe, oven, packaging line. Machine centers belong to a parent work center; the work center can have multiple machine centers under it (an assembly cell with three workstations). Operations can be planned against a work center (any machine within) or a specific machine center.
Machine centers carry the same fields as work centers plus:
- **Parent Work Center** — the work center this machine belongs to.
- **Maintenance Calendar** — scheduled downtime.
## Shop calendars
A **shop calendar** is a weekly schedule of working / non-working time:
- **Working days** of the week.
- **Working hours** per working day (e.g. 8am-5pm with a 1-hour lunch).
- **Holidays** — closed days even if normally working.
- **Special overtime** — extended hours on specific dates.
Calendars roll up to work centers and down to machine centers. Capacity planning honours the calendar — operations can't be scheduled outside the working window.
## Routings
A **routing** describes the sequence of operations to make an item. Each operation specifies:
- **Operation No.** — the step sequence.
- **Type** — Work Center or Machine Center.
- **No.** — which work / machine center.
- **Description** — what's being done.
- **Setup Time** — per-run setup independent of quantity.
- **Run Time** — time per unit.
- **Wait Time** — between operations (cooling, drying, queue).
- **Move Time** — between work centers.
- **Send-Ahead Quantity** — if subsequent operation can start before this one completes for the full lot.
- **Concurrent Capacities** — if multiple workers can run in parallel.
Routings can be **serial** (operation 1 must finish before operation 2 starts) or **parallel** (operations can overlap). Most are serial.
## Routing versions
Routings are versioned the same way as BOMs — multiple versions per finished item with effective dates. Changes to the manufacturing process activate as a new routing version with a future effective date; planning honours which version applies for which dates.
**Cost flow.**
- **Setup time + Run time × Quantity** = total time on the work / machine center.
- Time × Direct Unit Cost = direct capacity cost.
- Indirect Cost % adds overhead.
- The total capacity cost is consumed into WIP, then absorbed into the finished item's cost.
For standard-cost items, the standard captures the expected capacity cost; variances post to variance accounts when actual differs.
## Subcontracted operations
A routing operation can be marked **Subcontracted** — done by an external vendor rather than internally. Subcontracted operations auto-create purchase orders to the vendor when the production order releases. The vendor's invoice maps back to the operation's cost flow.
## Capacity planning
Master planning considers work / machine center capacity:
- The planning engine calculates load — minutes / hours required per period.
- Compares load against available capacity from the calendar.
- Suggests rescheduling when load exceeds capacity (in finite mode) or warns (in infinite mode).
Business Central's capacity planning is functional but less sophisticated than Dynamics 365 SCM's; complex finite scheduling typically requires an APS add-on.
**Reports.**
- **Capacity load** — load per work center per period.
- **Routing cost** — cost analysis per item per routing.
- **Variance reports** — actual vs standard capacity cost.
**Common pitfalls.**
- **Incorrect setup / run times** — production orders schedule wrong; floor planning becomes unreliable.
- **Shop calendar mismatches** — actual operations don't reflect the configured calendar; capacity planning is wrong.
- **Routings without versions** — process changes overwrite history; historical production orders look wrong.
## Operational reality
Routings and capacity centers reward attention to detail. The data is the operational model of manufacturing; sloppy data makes the system unusable.
---
# Run book operations after Dynamics 365 go-live
How to run Dynamics 365 in steady-state — daily, weekly, monthly, and release-wave operations, with the run book that captures who does what when.
Source: https://www.solvingdynamics365.com/guides/run-book-operations-after-dynamics-365-go-live
Section: Implementation / Operations & support
Published: 2026-08-13
Go-live is the start, not the finish. A Dynamics 365 system needs ongoing operation — monitoring, periodic maintenance, release-wave updates, capacity management, security review, user support. The **operations run book** captures who does what when. Without it, operational work happens ad-hoc; with it, the system stays healthy at a known cost.
**The run book's role.**
A run book is a documented set of recurring procedures, each with:
- **Procedure name** — what's done.
- **Trigger** — when it happens (daily, weekly, monthly, on event).
- **Owner** — accountable role / person.
- **Steps** — detailed how-to.
- **Validation** — how to know it succeeded.
- **Escalation** — what to do if something goes wrong.
- **Last updated** — when the procedure was reviewed.
The run book lives in a shared location accessible to the operations team — typically Confluence, SharePoint, an Azure DevOps wiki, or a similar collaboration tool.
**Daily operations.**
- **Application Insights review** — check tenant telemetry for errors, slow operations, anomalies. 10 minutes of dashboard glance.
- **Job queue / batch failures** — review failed jobs; investigate top failures.
- **Integration health** — verify cross-system flows running successfully. Webhook deliveries, Service Bus queues, scheduled imports.
- **User support tickets** — triage incoming. New tickets categorised; high-priority assigned for same-day work.
- **Service health** — Microsoft service status; any incidents affecting your tenant.
Total daily ops effort: 30 minutes to an hour for a mid-sized tenant in steady state.
**Weekly operations.**
- **Capacity review** — Dataverse storage, API call usage, AI Builder credit consumption. Trend against thresholds.
- **License review** — newly-added users; license alignment; unused licenses.
- **Power Platform inventory review** — new apps, flows; orphaned assets from departed users.
- **Solution health review** — any failed deployments; release pipeline status.
- **Security review** — access changes; privileged role grants; suspicious activity logs.
- **Bulk delete jobs** — verify scheduled cleanup is running.
- **User training metrics** — adoption / engagement statistics; gaps identified.
Total weekly ops effort: 1-2 hours.
**Monthly operations.**
- **Period close support** — finance close is monthly; ops team supports with batch monitoring, error resolution, escalation handling.
- **Compliance review** — audit logs reviewed; any access or change anomalies investigated.
- **Backup verification** — point-in-time restore drill to a sandbox; verify the restore process actually works.
- **Performance review** — slow operations; high-load pages; query analysis.
- **DR scenario rehearsal** — once a quarter or every 6 months; full DR procedure tested.
- **Power Platform governance review** — new apps deployed; compliance status; risk apps flagged.
- **Vendor invoices / contract review** — license invoices reconciled; contract terms revisited.
Total monthly ops effort: half a day to a day.
**Release-wave operations.**
Every 6 months when a Microsoft release wave (Wave 1 in April, Wave 2 in October) approaches:
- **8 weeks before**: review Microsoft's published Release Plan; identify features to enable, deprecations affecting our tenant.
- **6 weeks before**: install preview build in a sandbox; run regression suite; verify extensions / customisations.
- **4 weeks before**: brief business stakeholders on changes; update documentation.
- **2 weeks before**: training users on new features they'll see.
- **Wave week**: verify production update; immediate post-update validation; user-facing communication.
- **2 weeks after**: post-update review; bug fixes / configurations adjusted.
Total release-wave effort: 2-3 days spread across the 8-week window.
**Incident response.**
When something breaks:
- **Severity 1 (system unusable for many users)** — immediate response. Escalate to partner; engage Microsoft Support if needed; alert leadership.
- **Severity 2 (significant impact for some users)** — same-day response. Internal investigation; partner engagement if needed.
- **Severity 3 (minor inconvenience)** — within-day response. Standard ticket handling.
Documented in the run book; everyone knows the playbook.
**Quarterly operations.**
- **Risk register review** — operational risks identified; mitigation status.
- **Roadmap planning** — features in pipeline; capacity for build work.
- **Steering committee** — leadership review of system health, costs, value.
- **Annual cost review** (when in scope) — license costs vs value; renegotiation opportunities.
**Annual operations.**
- **Full DR drill** — complete disaster recovery rehearsal.
- **Security audit** — full review of access, configurations, policies.
- **Vendor performance review** — partner, ISV evaluations.
- **Strategic review** — does the system still fit the business? Major changes warranted?
- **License optimisation** — comprehensive license audit (see the license optimisation guide).
**Who runs operations.**
- **Customer's internal IT** — typically owns operations day-to-day.
- **Implementation partner** — provides escalation and specialist support.
- **Microsoft Support** — for platform-level incidents (often escalated through the partner).
Roles documented in the run book — who calls Microsoft, who calls the partner, who handles incidents.
**Common pitfalls.**
- **No run book** — operations happen ad-hoc; key procedures rely on tribal knowledge.
- **Run book without ownership** — procedures listed but no clear owner; nothing happens.
- **Run book unmaintained** — procedures from go-live still listed; current procedures undocumented.
- **Tool sprawl** — different procedures live in different places; ops team can't find them.
## Operational reality
Run book operations are the unglamorous infrastructure of running a Dynamics 365 system well. Build the run book during hypercare; mature it across the first six months; treat it as a living document. The cost is small; the system's reliability over years is substantial.
---
# Sales and purchase agreements in F&O
How Dynamics 365 Supply Chain handles sales and purchase agreements — commitments, releases, fulfilment tracking, and the integration with planning.
Source: https://www.solvingdynamics365.com/guides/sales-and-purchase-agreements-in-f-and-o
Section: Finance & SCM / Supply chain & inventory
Published: 2026-05-01
**Sales agreements** and **purchase agreements** in Dynamics 365 Supply Chain Management are the formal mechanism for long-term commitments between two parties — frame agreements where a quantity, period, and price are fixed, and individual orders are "released" against them over time. They replace the older Business Central concept of *blanket orders* with a richer commitment model.
## The shape of an agreement
A **sales agreement** is a parent record carrying:
- **Customer** — who's committing to buy.
- **Effective period** — start and end dates of the commitment.
- **Default fields** — payment terms, delivery terms, currency, etc.
- **Lines** — what's being committed to:
- **Product Quantity Commitment** — "buy 1000 units of Product A over the period".
- **Product Value Commitment** — "buy €100,000 worth of Product A".
- **Product Category Quantity Commitment** — quantity across a category.
- **Product Category Value Commitment** — value across a category.
- **Value Commitment** — overall value across all products.
**Purchase agreements** mirror the structure on the procurement side.
## Releases
Against an agreement, **release orders** are created — standard sales orders (or purchase orders) referencing the agreement. Each release decrements the agreement's remaining quantity or value. The system enforces:
- Cannot release more than the committed amount.
- Cannot release outside the effective period.
- Pricing comes from the agreement (overriding the customer's standard price list).
- Other terms (payment, delivery) default from the agreement.
## Fulfilment tracking
The agreement view shows progress: committed, released, delivered, invoiced, remaining. Visibility for both sides:
- The customer-facing salesperson knows how much of the customer's commitment is still to release.
- The supply-chain side plans against the *expected* releases, not against ad-hoc orders.
## Integration with planning
Master planning honours sales agreements — the planning engine can forecast against open agreement quantities, ensuring supply is in place to meet the commitment. The forecast pattern: if the customer committed to 1000 units over the year, the planner expects ~250 per quarter and pre-positions supply.
## Purchase-side mirror
Purchase agreements work the same. A frame deal with a key supplier — "we'll buy 50,000 units of raw material A this year at €5/unit" — creates a purchase agreement; individual purchase orders release against it; supplier price honoured for the duration regardless of market movement.
## Pricing
Agreement pricing can be:
- **Fixed** — the agreed price holds for the duration.
- **Discount %** — discount off the standard price list at release time.
- **Markup %** — for cost-plus arrangements.
- **Tiered** — different prices at different volume bands within the commitment.
## Renewals
Agreements expire on the end date. Renewal workflows in Power Automate can prompt the salesperson 30/60/90 days before expiry to negotiate the next year's commitment.
## Reporting
Sales agreement reports:
- **Customer commitment summary** — what every customer is committed to.
- **Fulfilment progress** — % consumed across active agreements.
- **At-risk agreements** — agreements where the customer hasn't released enough to consume the commitment, suggesting expiry without full delivery.
- **Pricing analysis** — actual vs committed price across the portfolio.
**Common pitfalls.**
- **Agreements that drift** — released against but never tracked to closure; expire silently.
- **Pricing misalignment** — agreement price changed after creation; some releases at old price, some at new.
- **Multi-currency complications** — agreement in customer currency but cost in supplier currency; FX swings between commitment and fulfilment.
## Operational reality
Agreements demand discipline — formal commitment management, active tracking, scheduled renewals. The reward is predictable revenue and supply, and tighter customer/supplier relationships. The cost is the operational discipline; ignored, the agreements become bureaucratic noise.
---
# Sales and purchase returns in Business Central
How Business Central handles returns — return orders, credit memos, exact cost reversal, the difference between return-receipt and credit-memo flows.
Source: https://www.solvingdynamics365.com/guides/sales-and-purchase-returns
Section: Foundations
Published: 2026-05-01
Returns processing is one of those areas everyone hopes won't matter and that always does. Business Central handles returns through dedicated **return order** and **credit memo** document types, with cost reversal mechanics that keep inventory value and the GL straight.
## Sales returns — the typical flow
A customer wants to return goods. The seller's sequence:
1. Create a **Sales Return Order** (a return-flavoured sales document). The user can manually enter the items being returned, or pull from a previously-posted shipment using **Copy Document** which fills in the original items, quantities, prices, and references.
2. **Get Posted Document Lines to Reverse.** When tied to a specific historical sale, this function pulls the exact lines and ensures cost reversal matches the original cost — not the current average. This is critical for FIFO and Specific costing items.
3. The return order is **released** and the **return receipt** is posted when the goods physically arrive back. Inventory goes up; item ledger entries are inbound with the *exact* cost from the linked outbound.
4. A **sales credit memo** is posted (either from the return order directly or as a separate document) to credit the customer. The customer ledger is reduced; GL revenue is reversed; COGS is reversed.
## Two-step vs one-step
The above is the **two-step return** flow (return receipt + credit memo). It's the right pattern when:
- Goods physically come back.
- The credit memo timing differs from the receipt timing.
- Inspection or refurb of the returned goods is required before credit.
A **one-step** alternative is to post a **sales credit memo** directly without a return receipt. Used for credits that don't involve physical returns — pricing adjustments, billing corrections, customer service goodwill. No inventory impact; just AR and GL.
**Purchase returns — the mirror image.**
1. Create a **Purchase Return Order**.
2. **Get Posted Document Lines to Reverse** from the original purchase receipt to ensure cost reversal at the exact landed cost.
3. Post the **return shipment** (inventory leaves the seller's warehouse heading back to the vendor) and the **purchase credit memo** (vendor balance reduced).
Or, for pure billing corrections without physical movement, post a **purchase credit memo** alone.
## Exact cost reversal
This is the non-obvious feature that matters. Standard inventory accounting under FIFO would value a returned item at the *next FIFO layer* cost when it comes back — which is wrong if the original sale was at an older, different cost. **Exact Cost Reversing** option, set on the return order header, forces the return to inherit the exact cost of the original outbound (or inbound) transaction, restoring inventory value to where it was before the original transaction.
Always use Exact Cost Reversing for genuine returns. The setting is on by default when **Get Posted Document Lines to Reverse** is used.
## Return reasons
Return orders carry a **return reason code** that classifies the return — defective, wrong item, customer error, no longer needed. Reason codes feed quality reporting and supplier scorecards.
## Restocking charges
A sales credit memo can carry a restocking charge line — a small additional charge to the customer for processing the return — posted to a configured GL account.
## Reporting
Returns analysis reports show return volume, value, reason codes, and supplier-side patterns. The data is invaluable in supplier reviews and product quality programmes.
---
# Sales and purchasing in Business Central
How the order-to-cash and procure-to-pay flows work in Business Central — quotes, orders, invoicing, requisitions, and approvals.
Source: https://www.solvingdynamics365.com/guides/business-central-sales-and-purchasing
Section: Business Central / Sales & purchasing
Published: 2026-05-01
Updated: 2026-08-30
The sales and purchasing modules are where most day-to-day Business Central users spend their time. Both follow the same document-driven pattern — quote → order → shipment/receipt → invoice → posting — which keeps the system consistent and easy to learn. Understand the pattern once and you understand half the application: the same logic that turns a sales order into a posted shipment turns a purchase order into a posted receipt, a transfer order into a transfer shipment, and a return order into a reversal.
## Sales (order-to-cash)
Sales starts with a customer card carrying credit terms, prices, currency, and posting groups. From there, salespeople create **sales quotes**, which convert to **sales orders** once accepted. Orders can be partially or fully shipped (creating posted shipments and inventory transactions), and partially or fully invoiced (creating posted invoices and ledger entries). Standalone sales invoices and credit memos exist for transactions that don't need order tracking. Sales returns are handled through return orders that reverse inventory and value.
Two document types deserve more attention than they usually get. **Blanket sales orders** hold a negotiated quantity over a period and release call-off orders against it — the right tool for contract customers, and much cleaner than cloning orders month after month. **Drop shipments** and **special orders** link a sales line directly to a purchase line, so goods ship from your vendor to your customer without touching your warehouse; the requisition worksheet picks these up and creates the linked purchase orders for you.
## Pricing and discounts
Pricing is driven by **price lists**, customer-specific prices, line and invoice discounts, and customer/item discount groups. The practical guidance: keep the structure as flat as you can. Every layer of customer-specific pricing you add is a layer someone has to maintain and a layer that makes "why did this order get that price?" harder to answer. Line discounts and invoice discounts also post differently — see the [line vs invoice discount comparison](https://www.solvingdynamics365.com/guides/sales-line-discounts-vs-invoice-discounts) before you design commission or margin reporting around them.
## Purchasing (procure-to-pay)
Purchasing mirrors sales: vendor cards, **purchase quotes**, **purchase orders**, partial receipts and invoices, and posted credit memos for returns. The **requisition worksheet** plans purchases based on demand from sales, projections, or minimum stock, suggesting POs to release. A built-in **vendor item catalog** lets you map your item numbers to a vendor's, and price/discount agreements can be time-bounded.
**Item charges** are the piece new implementations most often miss: freight, duty, and insurance invoices can be allocated across received lines — by amount, quantity, weight, or volume — so landed cost actually lands in inventory value rather than sitting in a freight expense account distorting margins. If your business imports, set this up on day one; retrofitting correct landed cost after months of posting is painful.
The gap between "received" and "invoiced" matters in purchasing more than people expect. Goods received but not yet invoiced sit in the **GR/IR-style interim accounts** defined by posting setup, and month-end close includes reconciling them. Three-way match — order, receipt, invoice — is the default behaviour, not an add-on.
## Approvals
Both sides support **workflow-driven approvals** — sales quotes over a threshold, purchase orders over a vendor limit, customer credit-limit overrides — configured in the workflow designer and routed through users or roles. Approvers can act from Outlook, Teams, or the web client. Keep approval chains short: every additional mandatory approver is a place where an order sits still. The most successful setups approve on the exception (over threshold, new vendor, credit override), not on every document. For deeper chains and delegation rules, see [approval workflows in Business Central](https://www.solvingdynamics365.com/guides/business-central-approval-workflows).
## Documents and reporting
Posted documents are immutable and can be reprinted, emailed, or sent as PDFs — and increasingly as e-invoices where the country localization or an ISV connector supports the local format. Each posted document writes to the relevant **vendor ledger**, **customer ledger**, **item ledger**, and **value entry** tables, which are the foundation for AR/AP ageing, sales analytics, and inventory valuation.
## Where implementations go wrong
Three patterns account for most of the mess we see in running systems. First, **posting groups configured in a hurry**: general business and product posting group combinations decide which GL accounts every sale and purchase hits, and untangling a wrong mapping after a year of posting is a project. Second, **open orders never closed**: partially shipped orders that will never complete should be closed, or they haunt the planning engine and the order lists forever. Third, **using invoices where orders belong** — standalone invoices skip inventory reservation and warehouse handling, which is fine for services and fatal for stocked goods.
Get the document flow, posting groups, and item charges right at the start, and sales and purchasing in Business Central largely runs itself; the daily work becomes exceptions and approvals rather than data entry.
---
# Sales forecasting in Dynamics 365
How forecasting works in Dynamics 365 Sales — hierarchies, submitted values, AI-predicted forecasts, snapshots, and management cadence.
Source: https://www.solvingdynamics365.com/guides/sales-forecasting-in-dynamics-365
Section: Foundations
Published: 2026-05-01
Forecasting is where sales-management discipline gets tested. Dynamics 365 Sales ships a configurable forecasting module that fits the cadences most B2B sales organisations actually run.
## The model
A **forecast configuration** defines the dimensions of the forecast: the sales **hierarchy** (org chart, territory, product line), the **period** (monthly, quarterly), and the **measures** to surface for each cell of the grid. Default measures: *Submitted* (the seller's committed number), *Best case*, *Pipeline*, *Won*, *Quota*. Custom measures (rollups, calculated columns) can be added.
## Hierarchy
A forecast is most useful when it rolls up. The standard rollup is the **manager hierarchy** (your team aggregates into you), but **territory-based** and **product-line-based** hierarchies are equally common — and configurable on the same data. Multiple forecasts per organisation are normal.
## Predicted forecast
Beyond seller-submitted numbers, Dynamics 365 Sales runs an **AI-predicted forecast** based on historical close rates, opportunity attributes, stage progress, and engagement signals. The predicted forecast appears alongside the submitted forecast in the grid, giving managers a number to compare against.
## Snapshots
Forecasts are **versioned and snapshotted** — daily by default — so you can see how the forecast for next quarter has drifted week over week. The snapshot history is the basis for forecast accuracy analysis and for spotting drift early.
## Manager adjustments
A manager can override an aggregated number with a **manager judgment**. Both the original rolled-up value and the override are stored, so audit and accuracy analysis can see where overrides happened and how they panned out.
## Workflow
Forecasts have **submission states** — Draft, In Review, Submitted — and can be locked at a snapshot deadline so the team commits to a number at a moment in time.
## Inline editing
Sellers and managers work directly in the forecast grid; clicking an opportunity opens a slide-out for in-place editing without leaving the forecast.
## Copilot
Generative AI explains the forecast: why is this quarter trending down, which deals are slipping, which late-stage opportunities lack required actions. Natural-language queries return data without the seller leaving the grid.
## Integration
Forecasts can publish to Power BI for executive dashboards, and to Excel for finance integration. Many companies still take the final number to a separate budget/forecast process in finance.
## Operational reality
The mechanics are easy; the discipline is hard. Forecasting only works if pipeline hygiene is real — stale opportunities, optimistic close dates, and dead leads pollute the forecast as much as the AI predictions can correct.
---
# Sales forecasting in Dynamics 365 Sales — a deep dive
How Dynamics 365 Sales forecasting works — forecast configurations, hierarchies, manual adjustments, predictive forecasting.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-sales-forecasting-deep-dive
Section: Customer Engagement / Sales
Published: 2026-05-01
A sales forecast is the executive team's bet on next quarter. It drives capacity decisions, hiring, expense management, and external commitments. Dynamics 365 Sales has a multi-layered forecasting capability — from manual quota-driven dashboards to ML-powered predictive forecasts. The operational discipline around it matters more than the technical configuration.
**Three flavours of forecasting.**
- **Forecast** — the configurable forecast type; the workhorse. Hierarchical, period-based, role-based.
- **Premium forecast** — adds AI predictive lines, premium analytics.
- **Custom forecast scenarios** — additional rollups (revenue, ACV, units) per opportunity.
## Forecast configuration
Admin defines:
- **Forecast type** — usually by territory hierarchy or manager hierarchy.
- **Time periods** — monthly, quarterly.
- **Currency** — usually a single currency for the forecast, with FX conversion at source.
- **Layouts** — what columns visible per period (Committed, Best Case, Pipeline, Closed Won).
- **Rollup columns** — which opportunity fields aggregate (estimated revenue, weighted revenue, ACV).
- **Forecast hierarchy** — who reports to whom for rollup purposes.
Setup is non-trivial; expect 1–2 weeks for an initial configuration with stakeholder alignment on what's measured.
## Hierarchy
A typical sales org has SDR → Account Executive → Manager → Director → VP → CRO. Forecast rolls up this hierarchy:
- AE's forecast = sum of their opportunities, manually committed amount.
- Manager's forecast = sum of AE forecasts, with manager's manual adjustment.
- Director's forecast = sum of manager forecasts, with director's adjustment.
At each level, the user sees their team's roll-up and can override (add or subtract from the rolled-up number). The override captures the leader's judgment about deals beyond the system's view.
## Forecast categories
Each opportunity carries a **forecast category**:
- **Pipeline** — early; not committed.
- **Best Case** — could win, not confident.
- **Commit** — confident it'll close in the period.
- **Closed Won** — done.
- **Omitted** — excluded from forecast.
Rep updates the category as deals progress. The forecast aggregates per category: pipeline view shows total pipeline; commit view shows what reps have promised.
## Manual adjustments
Critical and frequently misunderstood. The manager sees the rolled-up commit of their reps. They believe the actual commit number should be different (some reps over-call, others under-call). They enter a manual adjustment: +$50K (I'll bring in $50K more than they're showing) or –$30K (I doubt their pipeline). The adjustment passes up the hierarchy as part of the manager's commit.
This is the human judgment layer. A forecast without manual adjustments is just the sum of rep optimism.
## Underlying data
Forecast pulls from opportunities. The fields that matter:
- **Estimated revenue** — the deal value.
- **Estimated close date** — which period the deal lands in.
- **Probability** — implicit in the forecast category.
- **Forecast category** — manual category.
- **Owner** — who's the rep.
A clean forecast requires clean opportunity data. Garbage in → garbage out is the dominant failure mode.
## Predictive forecasting (Premium)
Uses ML to score:
- **Win probability** — likelihood the deal closes won.
- **Predicted close date** — when (revised vs rep's manual date).
- **Predicted revenue** — what's likely to come in.
The system aggregates predictions across the team and presents a "predicted forecast" alongside the manually-committed number. Comparing the two reveals where rep judgment systematically over- or under-calls.
## Quotas
Each rep, manager, etc. has a quota for the period. The forecast overlay shows commit vs quota:
- **% to quota** — how much of the goal is in commit.
- **Gap to quota** — how much more is needed.
Forecast doesn't drive quotas directly (quotas come from sales ops processes) but the comparison drives the conversation.
**Forecast operational rhythm.**
- **Weekly forecast call** — managers review with their reps; reps update categories.
- **Manager review** — managers' commits roll up, leaders make adjustments.
- **Monthly close-of-period** — actual closed vs forecast; variance analysis.
- **Quarterly recalibration** — quotas adjusted, hierarchies refreshed.
This rhythm is the management process; the system supports it but doesn't replace it.
## Snapshots and historical forecast
Forecasts can be snapshotted weekly to compare "what I committed in Week 1" vs "actual." Variance analysis (commit accuracy by rep, by team) drives coaching.
**Common pitfalls.**
- **Forecast as a vanity dashboard.** Numbers entered, no leadership review; no behavioural impact.
- **Category meanings drift.** Reps interpret "Commit" loosely; some include best case. Standardise definitions and enforce in coaching.
- **Hierarchy not maintained.** Reps reorganise but the forecast hierarchy doesn't; rollups wrong.
- **Opportunity hygiene poor.** Stale opportunities clogging pipeline; forecasts based on dead data.
- **Predictive forecast vs manual divergence ignored.** ML says $X, reps commit $Y, leaders don't reconcile; insight wasted.
## Where it sits in the broader stack
Beyond Dynamics, large sales organisations layer Clari, BoostUp, Outreach Commit on top for additional analytics. Dynamics forecasting is the system of record; specialist tools add coaching workflows, scenario modelling, and external data overlays. Whether to add layers depends on the org's sophistication; Dynamics's native forecasting is sufficient for most mid-market sales teams.
---
# Sales line discounts vs invoice discounts in Business Central
How the two discount mechanisms in Business Central differ — line-level vs document-level — and the configuration choices that make them coherent.
Source: https://www.solvingdynamics365.com/guides/sales-line-discounts-vs-invoice-discounts
Section: Foundations
Published: 2026-05-17
Business Central has two distinct discount mechanisms — **line discounts** and **invoice discounts** — that look similar at first glance but compute and post differently. Understanding the difference and configuring them coherently is the difference between predictable margin reporting and constant reconciliation surprises.
## Line discounts
A **line discount** is applied to a single sales line. It can come from:
- A manual override on the line (the seller types 10% in the *Line Discount %* field).
- A **sales discount** in a price list that intersects customer + item + quantity criteria.
- A **customer-specific discount** on a price list bound to the customer's group.
- A **campaign discount** active for the customer.
The discount reduces the *line amount* before VAT and posting. The system records both the original price and the discounted amount on the posted document; the GL posting reflects the discounted revenue.
## Invoice discounts
An **invoice discount** is applied to the *whole document* — a percentage off the document total, or a fixed amount across the whole invoice. It comes from:
- **Invoice discount table** — customer-specific minimum amount tiers ("If invoice over 10,000, give 5% off the whole invoice").
- **Manual entry** at posting time by the seller.
The invoice discount is calculated *after* line discounts. It distributes proportionally across all lines, posting to a designated *Sales Invoice Discount Account* in the GL — separate from regular sales revenue. This separation makes the management view of revenue vs discount transparent.
## The interaction
A single sales document can have both:
- Each line's amount = unit price × quantity × (1 − line discount %).
- The sum of line amounts is the *Total Excluding VAT before invoice discount*.
- Invoice discount applies to that total.
- The final invoice amount reflects both reductions.
The GL posts:
- Revenue at the line discount level (to standard sales accounts).
- The invoice discount portion to the dedicated invoice discount account.
This lets finance see "we discounted X via line, Y via invoice" without conflating them.
**Configuration choices.**
- **Calculate Invoice Discount** field on customers — toggles whether invoice discount applies automatically.
- **Customer invoice discount table** — configurable thresholds and percentages per customer or customer group.
- **GL accounts** for invoice discount — typically separate from line discount accounts.
- **Posting setup** — whether discounts post net (reducing revenue) or gross (revenue full, discount as expense).
Most implementations post net — revenue shows after discount.
**When to use which.**
- **Line discount** — for product-specific or quantity-based discounts. "20% off Item X for Customer Y" goes on the line. "Volume tier of 100+ units gets 10% off" goes on the line via price-list configuration.
- **Invoice discount** — for whole-order incentives. "Spend over 10,000, get an additional 5% off the whole order". The customer sees a single line discount on the invoice that doesn't depend on individual items.
**Reporting implications.**
- **Sales by product** — line discounts directly affect product-level revenue. A product with heavy line discounts shows lower per-unit margin.
- **Discount analysis** — separating line vs invoice discount lets finance see which sales tactics drive margin erosion.
- **Customer profitability** — both discount types reduce the customer's contribution; combined view is the meaningful one.
**Common pitfalls.**
- **Stacking unintended discounts.** A customer-specific line discount plus a campaign discount plus an invoice discount can cumulate to give away more than intended. Audit periodically.
- **Wrong GL account configuration.** Invoice discount posting to the same account as revenue obscures the distinction.
- **Manual overrides without policy.** Sellers manually entering discounts at posting without managerial discipline erodes margin over time.
## Operational discipline
Define the discount policy at customer-group level; use price lists for systematic discounts; reserve manual line discounts for exceptions; use invoice discount tables for whole-order incentives. Review quarterly.
### Frequently asked questions
**What is the difference between a line discount and an invoice discount?**
A line discount reduces a single sales line — from a manual override, a price list, a customer-specific discount, or a campaign. An invoice discount applies a percentage or fixed amount to the whole document, is calculated after line discounts, and distributes proportionally across lines.
**How do the two discounts post to the general ledger?**
Line-discounted revenue posts to the standard sales accounts; the invoice discount portion posts to a dedicated Sales Invoice Discount account, so finance can see how much was given away at line level versus order level.
**How do I make invoice discounts apply automatically?**
Set Calculate Invoice Discount on the customer and configure the customer invoice discount table with minimum-amount thresholds and percentages per customer or customer group.
**What is the most common discount mistake?**
Unintended stacking — a customer-specific line discount plus a campaign discount plus an invoice discount can give away far more than intended. Define policy at customer-group level, use price lists for systematic discounts, and audit quarterly.
---
# Sales mobile and offline in Dynamics 365
The Dynamics 365 mobile experience for sellers — Power Apps mobile, offline sync, conflict handling, and what works well vs what doesn't.
Source: https://www.solvingdynamics365.com/guides/sales-mobile-offline
Section: Customer Engagement / Sales
Published: 2026-05-01
The Dynamics 365 mobile experience for sellers runs primarily through the **Power Apps mobile app** on iOS and Android. The same app that hosts model-driven Power Apps also hosts the Dynamics 365 Sales, Customer Service, and Field Service apps. For sellers in the field — visiting customers, working between meetings, attending events — mobile is the primary work surface.
## The Power Apps mobile app
Available free from the Apple App Store and Google Play. Sign in with the user's Microsoft Entra ID; the app discovers which Dynamics 365 model-driven apps the user has access to and lists them. Tap an app, and the experience renders forms, views, and dashboards in a mobile-friendly layout.
## Form design for mobile
Model-driven forms render on mobile through the same form designer; mobile-specific properties let the form-designer hide non-critical columns, reorder fields, and use **mobile-only forms** where the desktop and mobile experiences should diverge. Best practice:
- Show the seller's *next actions* first — open opportunities, today's meetings, recent activities.
- Hide configuration-style fields that sellers rarely change.
- Keep forms short — three to five sections, not fifteen.
## Offline mode
A serious differentiator. The Sales mobile experience supports **offline access** for configured tables — the seller can browse, edit, and create records without connectivity, syncing when online. The configuration determines:
- **Offline profiles** per security role — which tables, which views, which related tables, how many records, how recent.
- **Filtering** — only customer-owned accounts, only opportunities for this seller, only the next 30 days of appointments.
- **Storage** — bounded by device storage and a configurable limit.
## Sync behaviour
Offline data syncs:
- When connectivity returns.
- Periodically in the background.
- On user request from the app.
Sync is incremental — only changes since the last sync are transferred — and uses Dataverse change tracking for efficiency.
## Conflict resolution
If the same record is edited offline by the seller and online by someone else, sync detects the conflict and surfaces it for resolution. Default policies (last-writer-wins, client-wins, server-wins) are configurable; complex policies (field-level merge) require custom code.
## Outlook and Teams integration
The seller's mobile email and meetings are in Outlook; the Sales app coordinates: opening an email or meeting from a tracked customer shows related CRM context inline. Teams calls and meetings on mobile capture activity records back to CRM if Server-Side Sync and the Dynamics 365 App for Outlook are configured.
## Mobile push notifications
Configured Power Automate flows can push notifications to the mobile app — new high-priority lead, opportunity stage change, contract due for renewal, customer satisfied survey response.
## Copilot on mobile
Mobile-aware copilot features summarise records, draft replies, and answer questions from the app. The mobile UI is more constrained than desktop; the most valuable copilot uses are short-form (summarise this customer, draft this reply).
**Limits.**
- Some complex form controls and custom PCF controls don't render identically on mobile; test before assuming parity.
- Offline-mode performance degrades with very large offline data sets; bound the offline profile carefully.
- Some integrations (embedded Power BI, complex iframes) are unfriendly on small screens.
## Operational reality
The seller's mobile experience is the seller's daily reality. Spend serious form-design and offline-profile-design time on it — far more than typical for the desktop experience.
---
# Sales prices and price lists in Business Central
How Business Central handles pricing — the modern price list model, prioritisation, discounts, and the migration from the old per-customer pricing tables.
Source: https://www.solvingdynamics365.com/guides/sales-prices-and-price-lists-in-business-central
Section: Business Central / Finance & accounting
Published: 2026-05-01
Pricing in Business Central went through a substantial redesign a few years ago. The old per-customer / per-item discount-and-price tables — scattered across multiple objects, hard to maintain at scale — were replaced by a unified **price list** model. Most new tenants run the new model exclusively; some upgraded tenants still carry historic structures. Understanding the modern model and how prices resolve at the line is essential.
## The price list
A **price list** is a header carrying a code, a description, a status (Draft, Active, Inactive), a currency, a start/end date, a definition (Sales or Purchase, Price or Discount), and a *source* — Customer, Customer Price Group, Campaign, All Customers, or specific Salesperson. Underneath the header are **price list lines**, one row per item-and-variant-and-unit-of-measure with the price or discount.
## Price vs discount
A price list can be a **price list** (sets the absolute unit price) or a **discount list** (applies a percentage discount on top of an underlying price). The two compose: a customer-specific discount list applies on top of the standard price list.
## Source priorities
When a sales line is created, the system finds the best applicable price by checking sources in priority order:
1. **Customer-specific** price lists (highest priority).
2. **Customer Price Group** the customer belongs to.
3. **Campaign** active for the customer.
4. **All Customers** (lowest priority, the default catalogue).
Within each source, the most-specific item / variant / UoM line wins. Higher-priority sources override lower; an active customer-specific price beats the catalogue price.
## Effective date
Price list lines respect start and end dates, so promotional pricing can be set in advance and expires automatically. The system uses the *order date* (configurable to *posting date*) to decide which prices are valid.
## Customer Price Groups
A **customer price group** is a tag attached to customers (or defaulted from a customer template) used by price lists to apply the same prices to many customers without listing each one. Common: "Distributors", "End-Customers", "Strategic Accounts", with different price lists.
## Currency
A price list is currency-specific. A customer transacting in EUR uses the EUR price list; the same customer in USD uses a separate one.
## Migration from old structures
Older BC tenants may still have the legacy *Sales Price* and *Sales Line Discount* tables in addition to price lists. The *Feature Management* page lets administrators enable the new model and run a migration that converts the old data into price lists.
**Operational discipline.**
- **One catalogue price list** for All Customers. Maintain it cleanly.
- **A handful of customer-price-group lists** for major customer segments.
- **Customer-specific lists** only for genuine exception pricing — strategic accounts, contracted prices.
- **Time-bounded promotions** as separate lists with start/end dates.
Avoid scattering customer-specific prices across many sources. The clearer the source hierarchy, the easier troubleshooting and audit.
---
# Sales tax setup in Dynamics 365 Finance
How to configure US-style sales tax in F&O — tax authorities, tax codes, tax groups, item tax groups, and the integration with Avalara / Vertex.
Source: https://www.solvingdynamics365.com/guides/sales-tax-setup-in-f-and-o
Section: Finance & SCM / Finance
Published: 2026-05-01
US-style **sales tax** is fundamentally different from European-style VAT. Where VAT is harmonised across countries with standard rates, sales tax in the US is fragmented — 45 states, thousands of local jurisdictions (county, city, special districts), each with their own rates, taxable categories, and exemptions. Dynamics 365 Finance supports US sales tax natively and integrates with **Avalara** and **Vertex** for the deep complexity most US operations face.
## The F&O native engine
The native sales tax engine works through:
- **Sales tax authorities** — the regulator (state, county, city). Each has a tax-payment recipient configured.
- **Tax codes** — specific rates for specific authorities. e.g. NY State 4%, NYC City 4.5%, NY MCTD 0.375%.
- **Tax groups** — bundles of tax codes that combine for a given customer / location. A New York City customer gets the NY State + NYC + MCTD group.
- **Item sales tax groups** — bundles of tax codes that apply to a given item. Most goods are taxable; some (groceries, prescription drugs in many states) are exempt.
- **Intersection** — the customer's tax group × the item's item tax group = which tax codes actually apply.
- **Settlement periods** — when each authority's tax is settled and remitted.
## The challenge of US sales tax
Sourcing — which jurisdiction applies — depends on whether the state uses **origin-based** sourcing (where the seller is located) or **destination-based** sourcing (where the customer receives). Most states are destination-based; this means a single seller must compute tax based on the customer's address, with potential exposure across thousands of jurisdictions.
## Nexus
A seller has **tax nexus** in a state — and must collect tax there — if they have physical presence, economic presence (revenue / transaction thresholds, post-**South Dakota v Wayfair** 2018), or specific business activities. Determining nexus is a tax-advisory question; F&O collects tax in jurisdictions configured to be in scope.
## Why Avalara / Vertex
The native engine handles tax computation if you maintain the rates and rules manually. For a seller selling into 5 states with 10 jurisdictions, manual maintenance is feasible. For a seller selling nationwide, with rates that change frequently, with product-specific taxability rules, and with exemption certificate management — manual maintenance is infeasible. **Avalara** and **Vertex** are tax-engine SaaS platforms that maintain the rates / rules and provide API-level tax computation.
**The integration pattern with Avalara / Vertex.**
1. F&O has a configured Avalara / Vertex connector.
2. At sales-order creation (and re-validation at posting), F&O calls Avalara / Vertex with the transaction details: ship-to address, ship-from address, products, customer category, exemption certificate ID.
3. Avalara / Vertex returns the tax computation: which authorities, which rates, which exemptions, total tax.
4. F&O stores the tax computation on the transaction.
5. At posting, the tax posts to the standard sales tax accounts but with the Avalara / Vertex breakdown.
6. Periodic returns: Avalara / Vertex can file directly to authorities (Avalara Returns) or provide return-prep data for the seller's tax team.
## Exemption certificates
Many B2B transactions are exempt — wholesalers, manufacturers, resellers, non-profits, government. Exemption certificates document the buyer's exempt status. Avalara CertCapture / Vertex Returns / similar tools manage the certificate lifecycle — capture, verification, expiry, renewal, audit.
**Special rules.**
- **Tax holidays** — states declare temporary exemptions for specific products in specific periods (back-to-school, hurricane preparedness).
- **Tax-included pricing** — some B2C scenarios price tax-inclusive; F&O supports though most B2B is tax-exclusive.
- **Marketplaces** — sellers via Amazon / eBay / Walmart marketplaces typically have the marketplace collect tax on their behalf; the seller's F&O records the marketplace-collected tax separately.
- **Digital goods** — taxability varies wildly by state for digital products and services.
## Compliance and audits
US sales tax audits are rigorous. Documentation requirements:
- Every taxable transaction with full breakdown.
- Every exempt transaction with the supporting certificate.
- Periodic returns filed on time per authority.
- Reconciliation between collected tax and paid tax.
## Operational reality
US-based F&O implementations almost always integrate with Avalara or Vertex. The native engine is functional but isn't built for nationwide US complexity at scale. Plan for the integration from day one.
---
# Sales territories and quotas in Dynamics 365
How territory management and quotas work in Dynamics 365 Sales — assignment rules, hierarchy, and the integration with forecasting.
Source: https://www.solvingdynamics365.com/guides/sales-territories-and-quotas
Section: Customer Engagement / Sales
Published: 2026-05-01
Once a sales team is larger than a handful of people, **territories** and **quotas** become essential structural elements: who's responsible for which prospects and accounts, what's expected of them in revenue, and how performance is tracked. Dynamics 365 Sales models both with first-class objects and integrates them into forecasting and reporting.
## Territories
A **territory** in Dynamics 365 Sales is a defined slice of the market:
- **Geographic** — by country, region, postal code.
- **Industry** — by industry vertical.
- **Account-size** — by revenue band, employee count.
- **Named account** — a specific list of accounts.
- **Hybrid** — combinations of the above.
Each territory has a manager and a set of assigned sellers (one seller can belong to multiple territories; one territory can have multiple sellers).
## Territory assignment
Accounts and leads are tagged with a territory either:
- **Manually** — the salesperson or admin assigns at record creation.
- **Auto-assigned** — via Power Automate flow or routing rules that evaluate the record's attributes (country, industry, size) and set the territory accordingly.
- **Via Customer Insights – Data** — for sophisticated enterprises with complex assignment rules.
## Territory hierarchy
Territories support parent-child relationships, so reporting rolls up: Country → Region → Local Territory. A manager at the regional level sees aggregated pipeline across local territories.
## Quotas
A **quota** is the revenue or unit target assigned to a seller (or a territory, or a team) for a period — quarterly, annually, or both. Dynamics 365 Sales models quotas through:
- **Goal** records — the entity that holds the target value.
- **Goal metric** — what's measured (revenue, won opportunity count, new logos).
- **Goal hierarchy** — quotas can roll up from individual sellers to managers to regions.
- **Actual calculation** — automated rollups from opportunity / order data based on configurable rules.
## Quota cadence
Most organisations set quotas annually with quarterly cadences, often with split targets per quarter to handle seasonality. Quotas can be:
- **Fixed** — same amount per quarter regardless.
- **Time-weighted** — Q4 is 30%, Q1 is 20%, reflecting fiscal seasonality.
- **Manually adjusted** — for mid-year re-orgs or one-off changes.
## Integration with forecasting
**Sales forecasting** in Dynamics 365 Sales rolls up opportunity pipeline by seller and compares to quota: pipeline coverage ratio, gap to quota, predicted close vs target. Forecasts snapshot weekly; managers see drift over time.
## Commission integration
Quotas often link to commission calculations — sellers earn rate X up to quota, rate Y above. Dynamics 365 Sales doesn't ship a full commission engine; partners offer commission ISVs (Spiff, Performio, CaptivateIQ, Iconixx) that integrate with the quota and actual data.
**Operational discipline.**
- **Quota-setting cadence** — annual quotas set 4–6 weeks before the year starts, with manager sign-off. Late quotas demotivate.
- **Mid-year adjustment** — re-orgs, market changes, major customer changes warrant quota adjustments. Document and approve.
- **Coverage targets** — pipeline coverage of 3× to 5× the quota is healthy; lower means at-risk, higher means inflated pipeline.
- **Win-rate analysis** — quotas without honest win-rate context are fantasy. Calibrate quota to historical conversion.
## Where it stops
Very sophisticated incentive compensation, multi-currency quotas across multi-entity groups, or complex split-credit scenarios (one deal credited 60% to inside sales, 40% to field) usually need specialist commission/quota tools. For mainstream quota tracking, Dynamics 365 Sales's built-ins are sufficient.
---
# Sales territory design in Dynamics 365 — a deep dive
How to design and manage sales territories in Dynamics 365 Sales — territory hierarchies, account assignment rules.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-sales-territory-design-deep-dive
Section: Customer Engagement / Sales
Published: 2026-05-01
Sales territories define who owns which customers. **Dynamics 365 Sales** models territories as a hierarchical structure with account / lead assignment rules. Done well, territories give clear ownership and balance workload; done badly, they create disputes and gaps in coverage.
**Territory model.**
- **Territory** — named region (US-Northeast, EMEA-North, etc.).
- **Manager** — the territory's leader.
- **Members** — sales reps in the territory.
- **Hierarchy** — territories nest under parent territories.
**Territory criteria.**
- **Geographic** — by country, region, state, city, postal code.
- **Industry** — vertical-based.
- **Account size** — enterprise vs SMB.
- **Product line** — sales focused on specific products.
- **Hybrid** — combination.
Most organisations combine multiple dimensions; matrix territories common.
**Account assignment.**
- **Manual** — sales ops assigns each account to a territory.
- **Rule-based** — territory determined by account attributes.
- **Auto-assignment** — system applies rules on account creation.
For thousands of accounts, manual is impractical; rule-based essential.
**Assignment rules.**
```
IF AccountAddress.Country = "Sweden"
AND AccountSize = "Mid-Market"
THEN Territory = "EMEA-Nordic-MidMarket"
```
Rules expressed as conditions; complex hierarchies of rules supported.
**Lead routing.**
- New lead created.
- Auto-assignment runs.
- Rule matches → routed to territory's leads queue.
- Specific rep picks up.
For high-volume inbound, automation crucial.
**Quotas.**
- Each territory has a quota.
- Cascaded from regional / company quota.
- Member quotas roll up to territory quota.
- Track attainment.
Quota structure aligns with territory structure; misalignment causes confusion.
## Territory changes
Periodic redesign:
- **Annual rebalance** — equalise workload across territories.
- **Acquisition adjustment** — new accounts integrated.
- **Reorg** — major restructure.
Each change has operational impact: customers reassigned, open opportunities transferred, history maintained.
**Operational implications of changes.**
- **Customer relationship continuity** — long-time rep transition.
- **Forecast adjustments** — pipeline owners change.
- **Commission complications** — who gets credit for in-flight deals.
- **Customer surprise** — "Why is someone new calling me?"
Mature reorgs include change management — communications, transition periods, dual coverage during handoff.
**Coverage gaps.**
- Account created but no matching territory rule.
- Customer in a "gap" — falls outside any defined territory.
- Lead languishes unassigned.
Periodic gap audits surface these; rules adjusted.
**Overlapping territories.**
- An account matches multiple territories.
- Conflict — which territory owns?
- Resolution rules or manual intervention.
Cleanest: rules unambiguous. Reality: some accounts have rationale for multiple territories (mother company in one region, subsidiary in another).
## Multi-dimension matrix
Modern sales orgs:
- Geographic territory + product specialist.
- Account exec (relationship) + solution specialist (product depth).
- Two reps on one account.
Dynamics supports through multiple roles per account but the policy clarity matters more than the system flexibility.
**Hunter / farmer split.**
- **Hunter** — pursues new logos in a geo.
- **Farmer** — manages existing accounts in same geo.
- Hunter passes won deal to farmer for ongoing.
Territories with this split need clear handoff protocols.
## Quota relief and protection
When territories change:
- Reps may lose accounts they prospected — credit for in-flight deals.
- Quota protection during transition periods.
- Commission grace.
Without protections, reorgs hurt rep motivation.
**Reporting by territory.**
- Revenue by territory.
- Pipeline by territory.
- Quota attainment.
- Win rate.
Standard sales reporting decomposes by territory; managers compare and coach.
**Common pitfalls.**
- **Manual assignment.** Doesn't scale; inconsistent.
- **Stale rules.** Reality changes; rules don't.
- **No conflict resolution.** Overlapping rules; deals disputed.
- **Reorg without transition.** Customers and reps both unhappy.
- **No quota alignment.** Territory model says one thing; quotas reflect old structure.
**Best practices.**
- **Document the model** — what territories, why, how assigned.
- **Periodic review** — annually at minimum.
- **Coverage audit** — every account has clear ownership.
- **Change management** — reorgs include comms and transitions.
- **Quota alignment** — structure matches.
## Territory and forecasting integration
Forecasting hierarchy typically aligns with territory hierarchy:
- Rep → Manager → Director → VP.
- Same path for quota cascade and forecast roll-up.
## Strategic positioning
Territory design is the structural decision affecting daily sales execution. Get it right and the team operates smoothly; get it wrong and disputes consume management attention. The investment in clean rules, regular review, and disciplined change management pays back in sales execution clarity. Treat territories as a strategic asset; the alternative — ad-hoc assignment and constant reorgs — costs material productivity.
---
# Salesperson configuration and commissions in Business Central
How Business Central tracks salesperson assignments and computes basic commissions — and where the limits are for serious incentive compensation.
Source: https://www.solvingdynamics365.com/guides/salesperson-and-commissions-in-business-central
Section: Business Central / Finance & accounting
Published: 2026-05-01
Business Central has built-in **salesperson / purchaser** master records and a basic **commission** calculation tied to them. The functionality covers simple flat-percentage commissions cleanly; complex incentive compensation needs an external tool.
## The salesperson master
A **salesperson / purchaser code** is a Dataverse-like record representing an internal salesperson or buyer. Each carries:
- **Code** — short identifier.
- **Name** — human-readable.
- **Commission %** — flat percentage for simple commission calculation.
- **Email** — for routing notifications.
- **Team / Phone / Job Title** — operational fields.
- **Dimension defaults** — financial dimensions to attach to transactions where this salesperson is involved.
The salesperson code is *not* a Microsoft 365 user account — it's a sales-team-role record. A salesperson can map to a user account through configuration, but doesn't have to.
## Assignment to customers
Each customer card has a **Salesperson Code** field — the default salesperson responsible for that customer. New sales documents (quotes, orders, invoices) default the salesperson from the customer; users can override at the line level if needed.
## Per-document overrides
Documents can carry a salesperson different from the customer's default — useful for splits, joint sales, internal handovers. Each posted document records the salesperson at posting time, locked for audit.
## Commission calculation
The basic approach:
- Each salesperson has a flat **Commission %**.
- Posted sales documents accumulate commission based on the salesperson code and the percentage.
- The **Salesperson Statistics** view shows commission earned per period.
- Commission amounts can be posted to GL accounts through the General Posting Setup.
## Limits
Real-world commission schemes are usually more complex:
- **Tiered rates** — different % at different revenue bands.
- **Product-specific rates** — higher commission on strategic products.
- **Margin-based commission** — commission as % of gross margin, not revenue.
- **Splits** — multiple salespeople sharing a deal at configured percentages.
- **Accelerators** — commission rates increase above quota attainment.
- **SPIFs (Sales Performance Incentive Funds)** — one-time bonuses for specific products / campaigns.
- **Clawbacks** — commission reversed if the customer doesn't pay or returns goods.
- **Multi-currency** — different rates per region or currency.
- **New-vs-renewal** — different rates for new business vs renewal.
The built-in BC commission engine handles none of this beyond the flat percentage. For complex schemes, the options are:
1. **External commission engines** integrated with BC — Spiff, Performio, CaptivateIQ, Iconixx, regional ISVs. These pull sales data from BC and compute commission externally; payouts feed back to payroll or AP.
2. **Custom AL extensions** — for moderate-complexity schemes that don't justify external tools.
3. **Excel models** outside BC — for small organisations where formality isn't worth the tool cost.
## Multi-salesperson allocation
Some businesses split sales between two salespeople (inside seller, field seller, or by territory ownership). BC's built-in supports a single salesperson per document; splits typically use custom fields and reporting logic in Power BI.
## Reporting
Salesperson-keyed reports cover:
- Revenue by salesperson.
- Margin by salesperson.
- Open opportunities (if using BC's Relationships module).
- Commission earned (basic flat-rate calculation).
Power BI dashboards extend with team views, attainment-vs-quota, trend analysis.
## Operational reality
For very simple commission schemes (single flat rate, no splits, no tiers), the BC built-in suffices. The moment the scheme has tiers, products, or splits, plan for an external commission engine. Trying to bend BC's flat percentage into complex logic creates fragile customisations.
---
# Seasonal forecasting for retail on Dynamics 365
How to forecast seasonal retail demand with Dynamics 365 — Demand Planning for store-SKU seasonality, Commerce replenishment for allocation.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-for-retail-seasonal-forecasting
Section: Industries / Retail
Published: 2026-09-02
Retail forecasting has a shape that generic ERP forecasting handles badly: strong seasonality, short product lifecycles, promotions that move demand rather than create it, and a store-times-SKU matrix large enough that nobody can review it line by line. Dynamics 365 has three different tools that touch this problem, each aimed at a different size of retailer, and none of them is a complete merchandise planning suite. This guide is about choosing the right one and knowing where it stops.
## The three tools
**Demand Planning** (part of Supply Chain Management, with its own app experience) is the current statistical forecasting product. It ingests historical demand at whatever grain you load — item, site, warehouse, customer group, calendar — runs a choice of models including ones that fit seasonality, and lets planners adjust the result in a worksheet before publishing it back as a demand forecast for master planning. This is the tool for mid-to-enterprise retailers on the Finance and Operations stack. The [Demand Planning overview](https://www.solvingdynamics365.com/guides/dynamics-365-demand-planning) covers the mechanics.
**Commerce replenishment** is not a forecasting engine. It is an allocation and distribution engine: buyer's push to distribute a purchase across stores by weight, cross-docking to route inbound stock straight to stores, and replenishment rules that top stores up against minimums and maximums. It consumes a plan; it does not produce one.
**Business Central's Sales and Inventory Forecast extension** is a lightweight monthly forecast driven by an Azure AI model. It gives a small retailer a reasonable per-item forecast for reorder decisions with essentially no setup. It does not do store-level, weekly, or promotion-aware forecasting, and it should not be asked to.
## Forecast at the grain you can actually manage
The first mistake retailers make with Demand Planning is forecasting every SKU at every store every week because the tool allows it. The result is millions of series, most with sparse, noisy history, and a planner who cannot review any of it.
The pattern that works:
- **Forecast at category or sub-category by store cluster** — stores grouped by format, size, or climate zone — at weekly grain. The history is dense enough for the seasonal models to find a real pattern.
- **Disaggregate to store-SKU** using recent sales mix, which Demand Planning does when you publish at a lower level than you forecast. Accept that the disaggregation is mechanical.
- **Review exceptions, not rows.** Configure the worksheet to surface series where the model's forecast diverges from last year's actuals or the planner's override by more than a chosen band.
Store clusters are also the natural unit for Commerce's buyer's push, so the forecast grain and the allocation grain line up.
## Seasonality, promotions, and new items
Seasonal patterns are what the statistical models are good at, provided the history is long enough — a minimum of two full cycles, three is better. Retailers migrating from another system should load at least that much history rather than starting the clock at go-live.
Promotions are where most retail forecasts go wrong. A model that sees last Easter's promoted volume as baseline demand will over-forecast this Easter's unpromoted week. Demand Planning's approach is to let you separate the history into baseline and promotional components and handle the uplift as an adjustment, but it depends on the retailer having tagged promotional periods in the history. Commerce discount data can supply the tags; wiring that up is a project step, not a checkbox.
New items have no history. The standard technique is like-item modelling — copy the seasonal profile of a comparable item and scale it — which Demand Planning supports through profile assignment. Fashion retailers with hundreds of new SKUs a season will find the effort per item too high and typically need a merchandise planning ISV that handles attribute-based new-item forecasting.
## What is not in the product
Be clear with the merchandising team before they see a demo:
- **Open-to-buy** — the financial budget that constrains purchasing by category and period — is not a Dynamics 365 feature. It is a spreadsheet, a Power BI model over the forecast and commitments, or a merchandise financial planning ISV.
- **Assortment planning and range building** are merchandising decisions the product records but does not optimise.
- **Markdown optimisation** is ISV or data-science territory.
- **Size-curve and pack optimisation** for apparel is ISV territory.
The forecast tools produce a demand number; turning it into a buy that fits the budget and the range is still human and partner work.
## From forecast to orders
Once a forecast is published, Supply Chain Management's master planning consumes it to generate planned purchase and transfer orders, netted against on-hand and open orders, with the forecast-reduction rules deciding how actual sales consume the forecast. For retailers, the useful configuration is forecasting at the distribution centre and letting Commerce replenishment handle store distribution, rather than planning every store as an independent demand point. Planning at every store produces thousands of tiny transfer orders and a warehouse that hates the planning team.
On Business Central, the forecast extension feeds the item's reorder logic and the planning worksheet. It is adequate for a retailer with one or two locations and a few thousand items. Beyond that, the honest advice is that BC retailers use their POS ISV's replenishment features or an external planning tool; BC is the ledger and inventory record, not the planning brain.
## Measuring whether it works
Forecast accuracy metrics are built into Demand Planning, but the retail measure that matters is stock-out rate on seasonal lines during the season and residual stock at season end. Track both by category and cluster in Power BI against the forecast that was published. A forecast that is statistically accurate but published too late to influence the buy has done nothing.
---
# Segment builder in Customer Insights — Journeys
How the segment builder in Customer Insights — Journeys lets marketers define audiences — visual designer, query language, dynamic vs static.
Source: https://www.solvingdynamics365.com/guides/customer-insights-journeys-segment-builder
Section: Customer Engagement / Customer Insights / Marketing
Published: 2026-05-01
A segment in Customer Insights — Journeys is the audience for a campaign or journey. Building good segments — focused, accurate, dynamic — is the foundation of marketing effectiveness. The **segment builder** is the visual interface that lets marketers compose segment definitions without writing query code, while supporting advanced expressions when needed.
**The segment concept.**
- A named audience.
- Defined by criteria filtering profiles.
- Members computed at refresh time.
- Used by journeys, campaigns, analytics.
**Visual designer.**
- Drag-and-drop attribute selection.
- Build conditions: equals, greater than, contains, etc.
- Combine with AND / OR.
- Group conditions for complex logic.
The visual designer covers most common cases without query language.
## Attribute sources
Available attributes include:
- **Profile fields** — demographic, contact information.
- **Behavioural** — engagement history (opened emails, clicked links).
- **Transactional** — purchases, total spend.
- **Inferred** — propensity scores, lifecycle stage.
- **Custom** — anything from Customer Insights — Data or Dataverse.
The richer the unified profile, the more segmentation possibilities.
**Conditions.**
- **Demographic** — "Country = Sweden AND Age > 30".
- **Behavioural** — "Opened email in last 30 days".
- **Transactional** — "Total purchases > $1000".
- **Engagement** — "Visited website in last 7 days".
- **Negative** — "NOT in opt-out list".
**Composing complex segments.**
```
(Country = Sweden OR Country = Norway)
AND TotalPurchases > $500
AND NOT InOptOutList
AND LastEngagement < 90 days ago
```
The visual designer supports this; complex segments need clear naming and documentation.
**Segment types.**
- **Static** — snapshot; doesn't update.
- **Dynamic** — recalculated at refresh.
- **Compound** — combination of other segments.
Most production segments are dynamic.
## Compound segments
Combine existing segments:
- "VIP Sweden" = "Sweden segment" AND "VIP customers segment"
- "Promotable Spaniards" = "Spain segment" AND NOT "Recent purchasers"
This composability prevents duplicate segment logic.
**Refresh patterns.**
- **Continuous refresh** — near real-time as profiles change.
- **Scheduled refresh** — daily / hourly batch.
- **On-demand refresh** — operator-triggered.
Different segments have different needs; choose based on use case.
**Segment size.**
- Visual indicator of estimated count.
- Real count after refresh.
- Track over time for trend.
A segment dropping unexpectedly signals data issue or audience shrinkage.
## Profile attribute completeness
Segments depend on data:
- Missing data → smaller segments than expected.
- Data quality issues → segments wrong.
Audit profile data completeness; fill gaps where impactful.
## Negative segments
Exclude:
- Suppression lists (opt-outs, complaints, deceased).
- Already-converted (don't re-message).
- In other journeys.
Negative criteria essential for clean targeting.
**Time-based criteria.**
- **Within last N days** — recent activity.
- **More than N days ago** — dormancy.
- **Specific date range** — campaign-relative.
Time is a critical segmentation dimension; "active in last 30 days" segment behaves very differently than "active in last 365 days".
## Lookalike segments
AI-derived:
- Seed audience (e.g., VIP customers).
- Find profiles similar to seed.
- Useful for finding prospects.
Built on Customer Insights — Data ML capabilities.
**Segment in journey vs segment alone.**
- **Segment alone** — used for one-off campaigns or analytics.
- **Segment as journey audience** — drives journey membership.
When used as journey audience:
- Profiles entering segment → enter journey.
- Profiles leaving segment → may exit journey or stay.
The journey designer specifies entry/exit behaviour.
**Performance considerations.**
- **Complex queries** — refresh slower.
- **Large data sets** — refresh duration.
- **Frequent refresh** — system load.
For high-volume marketers, segment performance affects journey responsiveness.
**Common pitfalls.**
- **Segment criteria too broad.** Sends generic message to wrong people.
- **Segment criteria too narrow.** Tiny audience; doesn't justify campaign effort.
- **Segments don't respect opt-outs.** Compliance violation.
- **No segment lifecycle management.** Stale segments accumulating.
- **Refresh schedule mismatch.** Segment computed daily but journey triggers hourly; lag matters.
- **No documentation.** Segment definitions evolve; rationale lost.
**Best practices.**
- **Naming convention** — purpose, owner, refresh frequency.
- **Description field** populated.
- **Ownership** — each segment has a named owner.
- **Periodic audit** — segments inactive 90+ days flagged for retirement.
- **Suppression always applied** — opt-outs subtracted from every segment.
## Strategic positioning
Segment design is one of the highest-leverage marketing activities. The segment builder makes the mechanics easy; the strategic work is understanding the audience, choosing the right criteria, and maintaining segment quality over time. Mature marketing operations treat segments as managed assets — designed, monitored, retired. The teams that take segmentation seriously have measurably better campaign performance than teams that just blast everyone with everything.
---
# Sequences in the Sales accelerator
How sales sequences automate seller cadence in Dynamics 365 Sales — steps, conditions, branching, and the role in inside-sales workflow.
Source: https://www.solvingdynamics365.com/guides/sequences-in-the-sales-accelerator
Section: Customer Engagement / Sales
Published: 2026-05-01
The **sales accelerator** in Dynamics 365 Sales prioritises a seller's day with a queue of leads and opportunities ranked by AI-driven signals. **Sequences** are the cadence engine inside the accelerator — defined, repeatable sets of seller actions (calls, emails, follow-ups, LinkedIn outreach) that move a lead or opportunity forward predictably. They're how inside-sales teams turn ad-hoc prospecting into a process.
## The model
A **sequence** is a list of ordered **steps**, each defining one seller activity:
- **Activity type** — phone call, email, LinkedIn connection, LinkedIn message, task, custom activity.
- **Wait** — a delay before the next step (1 day, 2 days, etc.).
- **Branching condition** — optional logic that picks the next step based on signal (e.g. *if email was opened, go to step 5; if not opened, go to step 6*).
- **Email template** — for email steps, the pre-written template (with merge fields) the seller will send.
- **Notes / script** — for call steps, the script or talking points the seller should follow.
A typical sequence for outbound prospecting might look like:
1. Day 1: send connection email (template A).
2. Day 2: call.
3. Day 4: send follow-up email if no response.
4. Day 6: LinkedIn connection request.
5. Day 9: second follow-up email.
6. Day 12: call.
7. Day 15: closing email — "still interested?".
## Branching on signals
Sequences can branch based on detected behaviour: if the prospect opened the email, follow up sooner with a call; if they replied, move to opportunity creation; if they didn't engage, suppress further sends to avoid being marked as spam.
## Sequence assignment
Leads, opportunities, accounts, or contacts can be **assigned to a sequence** — either manually by the seller or automatically by routing rules. Once assigned, the next-action queue surfaces the relevant step at the right time, so the seller never has to remember the cadence.
## The seller's daily work
Inside the accelerator workspace, the seller sees:
- **Today's tasks** — every sequence step due today across their assignments.
- **Step details** — the relevant template, script, or notes inline.
- **Quick actions** — execute the step (send email, log call, skip) with one click.
- **Outcome tracking** — record outcomes that influence next step routing.
## Why sequences work
Sales cadence research is consistent: the difference between sellers who close consistently and sellers who don't is usually disciplined follow-up. The average prospect needs 6–10 touches before responding; most untrained sellers give up after 2. Sequences enforce the cadence and remove the willpower problem.
**Sequence design discipline.**
- **Start with the team's best practices** — what do top sellers actually do? Codify that.
- **Vary the channel** — calls, emails, LinkedIn alternated produce better engagement than all-email.
- **Personalise within structure** — templates with merge fields and customisation room, not robotic generic sends.
- **Measure outcomes per step** — which steps drive conversions? Which are noise?
- **Iterate quarterly** — sequences age; refresh based on what's working.
## Copilot integration
Generative AI suggests sequence step content (email phrasings, call scripts) based on the prospect's profile and the seller's intent. The seller reviews and personalises before sending. Combines structure with adaptive content.
## Where it stops
Very high-volume B2C prospecting belongs in dedicated cadence tools (Outreach, SalesLoft, Apollo). For B2B inside-sales teams with hundreds of accounts each, the sales accelerator with sequences is the right answer.
---
# Service Management in Business Central
Business Central's service module — service items, contracts, work orders, dispatch, and where the limits sit.
Source: https://www.solvingdynamics365.com/guides/business-central-service-management
Section: Business Central / Service & projects
Published: 2026-05-01
Updated: 2026-08-25
Service Management is a module in the **Premium** SKU of Business Central, aimed at companies that install, maintain, and repair equipment for customers — typical fits include equipment dealers, lifts and HVAC, IT hardware service, and similar after-sales operations.
## Service items
A **service item** is a serialised installation at a customer site: the equipment, its location, warranty terms, service history, and any contract that covers it. Service items can be created from sales of inventory items (so when you sell a serial-numbered machine, a service item record auto-generates), or registered manually for items installed before BC went live.
## Service contracts
A **service contract** binds a set of service items to a customer with agreed pricing, periodicity, response time, included visits, and renewal terms. Contract invoicing is run in a cycle (monthly, quarterly, annually) and produces sales invoices automatically. Contract renewals can be price-adjusted in bulk.
## Service orders
A **service order** records customer requests — symptoms, fault codes, required parts and labour, dispatch information, and the resolution. Orders link to one or more service items, capture allocated resources, and post both consumed inventory and labour resource time on completion.
## Service quotes and price agreements
Customers can be issued service quotes for non-contracted work; service price groups offer discounted rates per customer or contract.
## Dispatch
The **dispatch board** shows service orders against resources with drag-and-drop scheduling. It's a planning tool rather than a full route-optimisation engine — for serious field operations, customers step up to **Dynamics 365 Field Service**.
## Mobile
Business Central's service mobile experience is modest — companies with heavy field activity layer Field Service on top of, or instead of, Service Management.
## Posting and reporting
Posted service orders create item ledger entries (parts consumed), resource ledger entries (labour), and service ledger entries (revenue and cost). Standard reports cover service profitability, contract margins, response times, and recurring revenue.
## Where the limits sit
Service Management is excellent at depot, dealer, and contract-driven service models. It is *not* a full field-service-management platform with route optimisation, IoT-driven work orders, customer-facing self-service, or a first-class mobile experience. Companies that need those move to Field Service while keeping BC as the back office.
---
# SharePoint document management for Dynamics 365
How Dynamics 365 stores documents — the SharePoint integration model, folder structure, permissions, and operational gotchas.
Source: https://www.solvingdynamics365.com/guides/sharepoint-document-management-for-dynamics-365
Section: Customer Engagement / Dataverse platform
Published: 2026-05-01
Documents in Dynamics 365 don't live in Dataverse — they live in **SharePoint Online**. The integration is configured per record type, automatic per record, and almost always the right choice. Understanding how it actually works prevents the surprises that catch new admins out.
## The model
When an admin enables SharePoint integration for a Dataverse table (say, Account), every record of that table automatically associates with a **folder** in a configured SharePoint site. Users see a Documents tab on the record that shows the contents of the folder; uploads, downloads, and edits happen through the SharePoint experience, but inline with the CRM record.
## The folder structure
By default the structure is:
```
// ()/
```
So Account "Contoso Ltd" gets a folder named "Contoso Ltd (a1b2…)" inside the Accounts library. The GUID suffix is what disambiguates two records with the same name and what keeps the link stable if the name changes.
## Hierarchical folders
A common configuration nests folders to follow a hierarchy — e.g. Contacts under their Account, Opportunities under their Account. This requires *folder-based document management* to be enabled per table.
## Permissions
Documents inherit SharePoint permissions, not Dataverse permissions. By default the SharePoint site is shared with all Dynamics 365 users, so anyone with CRM access sees the documents. For finer-grained control, customers configure SharePoint at the library or folder level. This is the most common cause of "I can see the record but not the documents" support tickets.
## Search
Dataverse search indexes document metadata and titles but not always the document content; SharePoint search indexes content. Cross-system search is improving but isn't seamless yet.
## Co-authoring and check-in/check-out
All standard SharePoint features apply: simultaneous editing in Office on the web, versioning, check-in/check-out for sensitive documents.
**Limits.**
- 5 GB per file (SharePoint limit, occasionally tighter on tenants).
- 30 million items per SharePoint library before list-view performance degrades.
- Renaming the underlying record doesn't rename the folder (it keeps the original name to maintain link stability).
## Migration
Moving existing documents into a freshly-configured SharePoint integration is a structured task — migrate documents while preserving folder structure, then run the metadata mapping job to associate them with Dataverse records. Third-party tools (ShareGate, Metalogix, Power Automate flows) speed this up considerably.
## Why SharePoint, not Dataverse
Dataverse storage is expensive; SharePoint storage is cheap, included generously with Microsoft 365 licences, and built for document collaboration. The integration gives you both: relational data in Dataverse, documents in SharePoint, unified at the record level.
---
# Shop floor control patterns in Dynamics 365 Supply Chain Management
How shop floor execution works in Dynamics 365 Supply Chain Management — the production floor execution interface, job registrations and feedback.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-for-manufacturing-shop-floor-control
Section: Industries / Manufacturing
Published: 2026-09-02
Shop floor control is where a manufacturing ERP either earns its keep or gets ignored. If operators can start a job, report quantity, and log scrap in a few taps on a shared tablet, the production data in the system is real and the costing is trustworthy. If they cannot, supervisors key it in at the end of the shift from paper, and the ERP becomes a slightly delayed record of what a whiteboard already knew. Supply Chain Management has a genuine shop-floor layer; this guide covers what it does, how to configure it so operators tolerate it, and where a dedicated MES still wins.
## Two ways to feed back production
There are two modes for reporting production in Supply Chain Management, and choosing between them is the first decision.
**Journal-based feedback.** Supervisors or operators post route card and job card journals for time and quantity, picking lists for material, and report-as-finished journals for output. Simple, no clock-in concept, and no shop-floor terminal. Fine for small operations with few operations per order and a supervisor who owns the data.
**Manufacturing execution** (the production floor execution interface). Workers sign in on a shared device, see their jobs, start and stop them, register quantities and scrap, and the system computes elapsed time, splits it across parallel jobs, and generates the journals automatically. Costing gets actual labour hours from actual registrations. This is the mode meant by "shop floor control", and it is what the rest of this guide is about.
## The production floor execution interface
The current interface is a touch-first, configurable app that runs in a browser on a tablet or a mounted screen at the workstation. Workers badge in with a badge ID or pick their name, and the screen shows the job list for their resource or resource group. Available tabs cover starting jobs, reporting progress, reporting as finished, registering indirect activities such as maintenance or meetings, and viewing job details including attached documents and BOM lines.
Configuration lives in a few places:
- **Configurations of the interface** decide which tabs and buttons appear per device or per production unit. The strongest advice is to remove everything a station does not need. A screen with four large buttons is used; a screen with twenty is bypassed.
- **Calculation parameters and registration workflows** on the production parameters and time-and-attendance parameters decide whether multiple jobs can run in parallel on one worker (bundled jobs), whether time is split evenly or by estimate, whether approval is required before registrations are transferred, and how rounding works.
- **Production units and resource groups** map physical areas to devices, so a worker at the paint line sees paint-line jobs.
What operators register is deliberately small: start, quantity good, quantity scrapped with a reason, finished. Material consumption is usually auto-flushed on start or finish rather than registered by the operator, which is right for most discrete shops and wrong for process shops where actual consumption varies — those use the pick-list registration or a weighing integration.
## Time and attendance, and where payroll is not
The same registrations feed the **Time and attendance** module, which computes worked hours, breaks, overtime, and flex balances against profiles and pay agreements, and produces pay items for export. It is a capable time-capture system for a factory workforce.
What it is not is payroll. Supply Chain Management does not calculate or pay wages. The pay items are exported to a payroll system, and the mapping from pay agreement to that system's codes is an implementation task that takes longer than expected because every union agreement has a special case. If the manufacturer does not need time and attendance for payroll — only for job costing — the module can run in a lighter configuration where registrations are approved for costing but pay calculation is ignored.
## Machine data and IoT
Operators are one source of truth; machines are another. The **Sensor Data Intelligence** add-in ingests IoT signals into Supply Chain Management for scenarios such as machine status, production delays, and quality deviations, and can raise notifications or create records from them. It is a lightweight bridge, not a historian or SCADA system. Manufacturers with serious machine data run it into an industrial platform first and surface only the operationally relevant events into the ERP.
## When to use a dedicated MES
Supply Chain Management's shop-floor layer covers execution reporting well. It does not do detailed work-instruction management with revision control at the station, electronic batch records with full 21 CFR Part 11 signature trails, real-time OEE from machine signals, or genealogy at the level regulated industries require. Those are the domain of a manufacturing execution system.
For that case there is a first-party **MES integration framework**: production orders and their operations are published to the MES, and the MES sends back start, quantity, scrap, material consumption, and finish messages through defined message types and a queue. It means the ERP owns planning and costing while the MES owns execution, without a custom integration. The framework covers the common messages; anything exotic still needs extension work.
The rule of thumb: if the shop needs to know what is running and how much came out, use the built-in floor execution. If the shop needs to control *how* it is made — instructions, interlocks, signatures, machine parameters — put an MES in front and integrate.
## Business Central manufacturers
Business Central has no shop-floor terminal. Output journals, consumption journals, and capacity ledger entries are posted by people, and it works for a shop where a supervisor keys in the day's output. Manufacturers wanting operator-level start/stop, badge sign-in, and a tablet at every station use a shop-floor ISV from AppSource, of which there are several mature ones. Evaluate them on how they post to BC — direct capacity and output entries against production order routing lines is right; a nightly batch of journal lines is a red flag — and on how they handle a job that spans a shift change.
## Rollout advice
Pilot on one line with the smallest possible interface. Measure two things: the share of production orders whose actual time comes from registrations rather than estimates, and the gap between reported and physically counted output. When both are stable, add the next line. Manufacturers that switch the whole plant to floor execution on day one with a full-featured screen generally switch it off again by week three.
---
# Sitemap customisation in model-driven apps
How to customise the navigation of model-driven Power Apps — areas, groups, subareas, role-based visibility, and the user-experience impact.
Source: https://www.solvingdynamics365.com/guides/sitemap-customisation-in-model-driven-apps
Section: Customer Engagement / Dataverse platform
Published: 2026-05-01
The **site map** of a model-driven app — the left-side navigation menu users see — is the structural backbone of how they experience the app. Customising it well makes the app feel coherent and on-purpose; leaving it as Microsoft's default leaves users with menu items they don't recognise and missing items they need.
**The hierarchy.**
- **Area** — top-level grouping. A button at the bottom of the navigation lets users switch areas. Example areas: *Sales*, *Service*, *Marketing*, *Settings*.
- **Group** — a label within an area, dividing related items. Example groups within Sales: *My Work*, *Customers*, *Sales*, *Marketing Lists*, *Goals*, *Tools*.
- **Subarea** — the actual navigation items users click. Each subarea points to a destination: a table's main page (showing default view), a specific view, a dashboard, a URL, a custom page, a web resource.
The maker designs the area / group / subarea structure to match how users think about the app.
**Design principles.**
- **Mirror the work, not the data model.** Group by what users do, not by the tables underneath. *My Work* (combining Activities, Tasks, Appointments) is more user-friendly than separate menu items per Dataverse table.
- **Limit depth** — three levels (area / group / subarea) is enough. Don't over-nest.
- **Frequency-ordered** — most-used items at the top of each group.
- **Verb-noun phrasing** — *My Open Opportunities* beats *Opportunities (Mine)*.
- **Icon consistency** — use the platform icon library; bespoke icons can be uploaded but rarely worth the maintenance burden.
- **Avoid orphan tables** — every important table should be reachable from the navigation without searching.
## Role-based visibility
Sitemap items can be visible only to specific security roles:
- Managers see *Forecast* and *Team Performance*.
- Sellers don't see *Settings* or *Administration*.
- Service agents don't see Sales-specific tabs.
Configured per subarea; the platform respects the user's roles automatically.
## Customising the standard Dynamics 365 sitemaps
Sales Hub, Customer Service Hub, Field Service all ship with predefined sitemaps. Customisation typically:
- Adds custom tables to relevant groups.
- Hides Microsoft's defaults that aren't in use.
- Reorders items to match the customer's process.
- Adds external links (intranet pages, knowledge base URLs).
- Adds dashboards that match the customer's KPI structure.
## Multi-app sitemaps
Different apps in the same environment have different sitemaps. The Sales app's site map has Sales tables; the Service app's has Service tables. Same Dataverse, different navigations per persona.
## The modern site map designer
Microsoft has been migrating from the older site map designer (in the classic UI) to the **modern designer** in the Power Apps maker portal. The modern designer offers:
- Drag-and-drop reordering.
- Visual preview.
- Inline editing of labels, icons, destinations.
- Role-based visibility configuration.
- Validation against the current solution.
Older XML-based customisations remain supported but new work should use the modern designer.
## Mobile rendering
The site map renders on Power Apps mobile differently — typically as a hamburger menu with the same hierarchy. Areas appear as top-level navigation; groups and subareas inside. Test on mobile during design — a beautiful desktop site map can be unusable on mobile.
## Customised landing experience
Beyond the site map, the app's landing experience can be tuned:
- **Default landing area / subarea** — the page users see when they open the app.
- **Personalised home dashboard** — combining cues, charts, and shortcuts.
Configured per app or per profile.
**Common patterns.**
- **My Work** as the top group with Activities, Open Records, Recent — the "today" view.
- **Customers** group with Accounts, Contacts.
- **Sales / Service** group with Leads, Opportunities, Quotes / Cases, Knowledge.
- **Reports & Dashboards** group at the bottom.
- **Admin / Settings** area restricted to admin roles.
**Common pitfalls.**
- **Too many items per group** — 15 subareas per group is unusable; split into multiple groups.
- **Wrong default landing** — users open the app to an irrelevant page and immediately have to click elsewhere. Set sensibly.
- **Bottom-of-menu critical items** — important items below the fold get ignored. Surface them higher.
- **Stale references** — site map links to deleted dashboards or removed tables produce broken navigation.
## Operational discipline
Treat the site map as UX investment. Iterate based on user feedback; A/B test if changes are substantial. The site map is the daily face of the app.
---
# Skills-based routing in Dynamics 365 Customer Service
How skills-based routing matches customer interactions to appropriately skilled agents — skill definitions, proficiency levels, queue setup.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-customer-service-skills-based-routing
Section: Customer Engagement / Customer Service
Published: 2026-05-01
Not all agents can handle all issues. A Spanish-speaking customer needs a Spanish-speaking agent; a tier-2 technical issue needs a technical specialist; a high-value account needs a senior agent. **Skills-based routing** in Dynamics 365 Customer Service matches interactions to agents with the right capabilities — improving resolution rates and customer experience.
**The skill model.**
- **Skill** — a named capability ("Spanish", "Tier 2 Technical", "Manufacturing Domain").
- **Proficiency level** — Beginner / Intermediate / Expert.
- **Agent skill assignment** — each agent has skills with proficiency.
- **Skill requirements on interactions** — which skills needed.
The matching engine pairs interactions to agents.
**Skill categories.**
- **Language** — Spanish, French, German.
- **Technical** — programming languages, products, tools.
- **Domain expertise** — industry vertical, regulatory domain.
- **Soft skills** — VIP handling, escalation skills.
- **Certifications** — formal qualifications.
A typical agent has 10–20 skills with varying proficiency.
**Proficiency levels.**
- **Beginner (1)** — basic competency.
- **Intermediate (2)** — comfortable; routine cases.
- **Advanced (3)** — handles complex.
- **Expert (4-5)** — deep specialisation.
Numeric levels enable threshold matching ("requires Skill X at level 3+").
**Determining required skills.**
- **From case type** — case category drives skill needs.
- **From customer attributes** — VIP requires VIP handler.
- **From content analysis** — AI extracts likely skills from incoming text.
- **From channel** — Spanish chat → Spanish skill.
The skill requirements set the matching criteria.
## Unified routing
D365's modern routing engine:
- ML-based.
- Considers skills, availability, capacity, historical performance.
- Optimises for resolution.
Replaces older rule-based routing for many scenarios.
**Matching algorithm.**
- Check available agents.
- Filter by required skills at required proficiency.
- Among matching, prioritise by:
- Lowest current load.
- Highest historical resolution rate.
- Customer-specific preference (preferred agent if specified).
- Assign.
## Capacity constraints
Each agent has capacity:
- Max concurrent chats (e.g., 3).
- Max concurrent voice calls (e.g., 1).
- Max active cases.
Routing respects capacity; over-loaded agents skipped.
**Skill assignment for agents.**
- HR system or training records feed agent skill profile.
- Skills updated as agents complete training.
- Periodic refresh.
For mature operations, skill data lives alongside HR; not in the head of the supervisor.
## Multiple required skills
Interactions can require multiple skills:
- "Spanish-speaking" AND "Manufacturing domain" AND "Tier 2".
- Matches agents with all three.
- Stricter criteria → smaller eligible pool → potential delays.
Balance specific routing vs availability.
## Fallback routing
When no agent matches:
- Drop one skill requirement; retry.
- Route to general queue.
- Escalate to supervisor.
- Customer waits.
Mature deployments define fallback paths; without them, customer hangs.
## Skill assessment
Validating agent skills:
- Self-reported (least reliable).
- Manager-assessed.
- Test-based (technical skills).
- Performance-based (historical resolution rate).
Combine multiple inputs; skill data quality affects routing quality.
**Cross-channel skills.**
- Chat skills.
- Voice skills.
- Email skills.
Some agents excel in chat but not voice; route accordingly.
**Reporting.**
- **Skill demand vs supply** — gaps where customer needs unmet.
- **Per-skill resolution times.**
- **Agent skill utilisation.**
- **Routing decisions** — where did interactions go and why.
These metrics guide training, hiring, and routing tuning.
**Common pitfalls.**
- **Skill explosion.** Hundreds of skills; agents over-tagged; routing complex.
- **Stale skill data.** Skills set at hire; agent grew; skill profile not updated.
- **Required skills too strict.** Long wait times; customer abandons.
- **No skill validation.** Self-reported expertise; routing wrong.
- **Capacity ignored.** Skilled agent overloaded; quality degrades.
- **No fallback.** Customer waits forever for the one matching agent.
**Best practices.**
- **Curated skill taxonomy** — 30–50 skills, not hundreds.
- **Periodic skill assessment** — quarterly review.
- **Validated proficiency** — based on performance.
- **Fallback paths defined.**
- **Capacity tuning** based on real workload.
**Training integration.**
- Agent completes training course.
- Skill / proficiency updates automatically.
- Routing immediately reflects new capability.
LMS integration enables this; manual entry fragile.
**AI assistance for skill assessment.**
- Analyse agent's case history.
- Identify topics handled well.
- Suggest skill updates.
Reduces manual skill maintenance burden.
## Strategic positioning
Skills-based routing is the operating model for any moderately-sized contact centre. Without it, routing is by queue alone — generic, often inappropriate matching. With it, customers more often get the right help fast; agents more often work within their expertise; metrics improve. The investment is meaningful — skill taxonomy design, agent profiling, ongoing maintenance — but the operational and CX benefits compound. For any organisation aspiring to differentiated service, skills-based routing is foundational, not optional.
---
# SLA management in Customer Service
How SLAs work in Dynamics 365 Customer Service — KPIs, warning and failure thresholds, business calendars, and KPI roll-up reporting.
Source: https://www.solvingdynamics365.com/guides/sla-management-in-customer-service
Section: Customer Engagement / Customer Service
Published: 2026-05-01
**[Service Level Agreements (SLAs)](https://www.solvingdynamics365.com/glossary/sla)** in Dynamics 365 Customer Service are how commitments to customers — "we'll respond within 1 hour, resolve within 4 hours" — get tracked, enforced, and reported. SLAs encode the response-time and resolution-time expectations that drive both customer satisfaction and operational discipline.
## The model
An **SLA** record defines:
- **Applicable to** — usually the *Case* table, but configurable.
- **Applicable when** — conditions that determine when this SLA applies (e.g. only Premium-customer cases, only Voice-channel cases).
- **Business hours** — the operating calendar (24/7, business hours, multi-region) the SLA respects.
- **SLA KPIs** — the measurable commitments (first response time, resolution time, etc.).
- **Status** — Active or Inactive.
An **SLA item** is the specific KPI within an SLA:
- **KPI** — the field being tracked (First Response By KPI, Resolve By KPI, or custom KPIs).
- **Applicable when** — sub-condition that narrows this item to a slice (e.g. high-priority cases get tighter timing than normal-priority).
- **Success criteria** — what counts as "met" (e.g. case status is *Resolved*).
- **Warning after** — duration after which the SLA is at *Warning* state (e.g. 80% of the resolution window consumed).
- **Failure after** — duration after which the SLA is *Breached* (the commitment is missed).
## Business calendars
SLAs respect business calendars — a 1-hour response SLA at 5pm Friday with a Mon-Fri business calendar doesn't breach over the weekend; the clock pauses outside business hours. Multi-region operations use multi-calendar SLAs that apply per customer's local time.
## SLA timer
Inside the case form, the agent sees a **timer widget** for each active KPI: time remaining, status (Active / Warning / Breached), with colour coding (green / amber / red). The visible countdown changes behaviour — agents prioritise cases that are about to breach.
## Pause and resume
SLAs pause automatically when the case enters certain statuses (e.g. *On Hold — Waiting for Customer*) and resume when status changes back. Pause rules are configured per SLA; the pattern keeps the clock honest about *active service time* vs *waiting time*.
## Escalation
When an SLA approaches warning or breach, Power Automate flows can trigger escalation actions: notify the supervisor, reassign the case, create a Teams notification, escalate the customer relationship. Configured per SLA item.
## Entitlements integration
SLAs are typically applied through **entitlements** — contracts the customer has that grant specific SLA terms. Premium-support customers get Premium SLAs; basic customers get standard. Entitlement configuration drives which SLA applies to a given case.
## Reporting
SLA performance feeds into:
- Real-time agent and supervisor dashboards — current cases approaching warning / breach.
- Historical KPI reports — % cases meeting SLA, average response/resolution time, breach reasons.
- Customer scorecards — per-customer SLA performance over time, used in QBRs.
**Common pitfalls.**
- **No business calendar** — SLA clock runs 24/7 and looks bad even when service was fine.
- **SLA fires for cases that shouldn't have one** — over-broad "Applicable when" conditions cause noise.
- **No pause configuration** — customer-wait time is counted against the support team, demoralising and misleading.
- **Reporting only after breach** — should warn at 80%, not at 110%.
## Operational discipline
Tune SLAs based on actual data, not aspirations. Start with achievable targets and tighten over time as the team performs. SLAs that breach constantly become noise; SLAs that always succeed are not stretch targets.
## Where to go next
SLAs apply through [entitlements](https://www.solvingdynamics365.com/guides/entitlements-in-customer-service) and land on cases that [routing rules](https://www.solvingdynamics365.com/guides/customer-service-routing-rules) assigned; the case itself is covered in [case management deep dive](https://www.solvingdynamics365.com/guides/case-management-deep-dive-in-customer-service) and the agent's view of the timers in [the agent workspace](https://www.solvingdynamics365.com/guides/customer-service-agent-workspace). Which licence tier includes what is in [omnichannel licensing](https://www.solvingdynamics365.com/guides/dynamics-365-customer-service-omnichannel-licensing).
---
# SOAP vs REST vs GraphQL for Dynamics 365
How the three API styles compare for Dynamics 365 integrations — capabilities, when each fits, and the practical considerations for choosing.
Source: https://www.solvingdynamics365.com/guides/soap-vs-rest-vs-graphql-for-dynamics-365
Section: Integrations / Architecture patterns
Published: 2026-05-01
Three predominant API styles offer different trade-offs for Dynamics 365 integrations: **SOAP** (the legacy enterprise standard), **REST/OData** (the dominant modern API style, what Dataverse uses), and **GraphQL** (the modern query-language alternative). Each has a place; choosing wisely matters.
**SOAP overview.**
- XML-based.
- WSDL contract.
- Strict typing.
- Built-in standards (WS-Security, WS-AtomicTransaction).
- Verbose payloads.
Origin: late 1990s enterprise integration; still common in legacy.
**REST overview.**
- Resource-oriented.
- HTTP verbs (GET, POST, PUT, DELETE).
- JSON typical.
- Stateless.
- Lighter than SOAP.
Dominant since mid-2000s; modern default.
## OData
A specific REST flavour:
- Standardised query semantics ($select, $filter, etc.).
- Used by Dataverse and F&O.
- Rich query capability.
**GraphQL overview.**
- Single endpoint.
- Client specifies query shape.
- Strongly typed schema.
- Subscriptions for real-time.
- One round-trip for complex data.
Emerged 2015 from Facebook; popular for client-rich apps.
**Comparison.**
| Aspect | SOAP | REST/OData | GraphQL |
|---|---|---|---|
| Format | XML | JSON | JSON |
| Verbosity | High | Moderate | Moderate |
| Contract | WSDL | OpenAPI | Schema |
| Query flexibility | Low | Moderate (OData) | High |
| Caching | Hard | HTTP-friendly | Custom |
| Tools | Mature, enterprise | Vast | Growing |
| Real-time | WS-* extensions | Push patterns | Subscriptions |
**Dynamics 365 native.**
- **Dataverse** — REST/OData. SOAP organization service still supported but deprecated.
- **F&O** — REST/OData via data entities. Custom services can use either.
- **GraphQL** — not native; available via wrappers.
For Dynamics integrations, REST/OData is the canonical choice.
**When SOAP still appears.**
- Integration with legacy enterprise systems (SAP, mainframes, banking).
- Existing investments unfeasible to migrate.
- Specific industry standards requiring SOAP.
- Some Microsoft legacy APIs (older organization service).
For Dynamics, SOAP is for legacy compat, not new development.
**When REST/OData wins (most Dynamics scenarios).**
- Calling Dynamics from any system.
- Standard tools and libraries.
- HTTP-friendly (caching, proxies).
- Lighter than SOAP.
Default for new Dynamics integrations.
**When GraphQL helps.**
- Front-end consumer benefits from query flexibility.
- Mobile / bandwidth-constrained scenarios — request only what's needed.
- Multiple data sources federated.
- Strong developer experience preference.
Less common in Dynamics native scenarios; useful when fronting Dynamics + other systems.
**Performance comparison.**
- **REST** — multiple endpoints; potentially multiple round-trips for related data.
- **OData $expand** — fetch related in one call.
- **GraphQL** — request exact shape; one round-trip.
- **SOAP** — typically heavier payloads.
For complex queries, GraphQL can be most efficient; OData $expand often sufficient.
**Caching.**
- **REST** — HTTP caching (ETags, Cache-Control).
- **GraphQL** — harder; POST-based queries.
- **SOAP** — typically no caching.
Caching favours REST.
**Versioning.**
- **REST** — `/v1/`, `/v2/` paths or headers.
- **GraphQL** — schema evolution (deprecate fields).
- **SOAP** — namespace versions.
Each has pattern; all manageable.
**Tooling.**
- **REST** — Swagger / OpenAPI, Postman, curl, every language.
- **OData** — additional tools for OData specifically.
- **GraphQL** — Apollo, Relay, GraphQL Playground.
- **SOAP** — older tools; still many.
For Dynamics, REST tooling dominant.
**Security.**
- **REST** — OAuth 2.0 typical.
- **GraphQL** — same.
- **SOAP** — WS-Security with signatures and encryption.
Modern: OAuth for all; WS-Security in legacy contexts.
**Custom Dynamics services.**
- **OData custom actions / functions** — extend Dataverse standard API.
- **Custom REST APIs in Azure Functions** — for non-Dataverse logic.
- **GraphQL wrappers** — for specific scenarios.
- **SOAP services** — rare; for legacy integration.
The right choice depends on consumer and pattern.
**Multi-API support.**
- Some integrations expose multiple flavours.
- API Gateway abstracts; consumers choose.
- More work but maximises consumer choice.
**Migration considerations.**
- **SOAP → REST** — common modernisation; significant effort.
- **REST → GraphQL** — quality-of-life upgrade; substantial work.
- **REST to additional GraphQL** — coexist; not migration.
**Common pitfalls.**
- **SOAP for new development.** Almost always wrong choice today.
- **REST without OpenAPI** — undiscoverable, hard to integrate.
- **GraphQL without query depth limits** — DoS vulnerability.
- **OData over-fetch** — without $select, fetching too much.
- **API style chosen by trend, not fit.**
**Best practices.**
- **Default to REST/OData** for Dynamics consumers.
- **Document with OpenAPI.**
- **Use OAuth.**
- **Version explicitly.**
- **Consider GraphQL for complex client-rich apps**.
- **Maintain SOAP only for legacy.**
## Hybrid landscapes
Most enterprises have all three:
- Legacy SOAP for old integrations.
- REST/OData for most.
- GraphQL for specific scenarios.
Not religious choice; pragmatic per integration.
## Strategic positioning
REST/OData is the right default for Dynamics 365 integrations. GraphQL is occasionally useful when client experience demands. SOAP is for legacy connectivity only.
For architects:
- Choose pragmatically per integration.
- Standardise where possible.
- Document API styles in architecture.
- Plan modernisation of SOAP legacy.
The teams that obsess over API style choice often lose sight of what matters: clear contracts, reliable operations, manageable evolution. Pick a style, do it well, focus on the outcomes.
### Frequently asked questions
**Which API style does Dynamics 365 use natively?**
REST with OData. Dataverse exposes an OData v4 Web API, and Finance and Operations exposes data entities over OData. The SOAP-era organization service still exists for legacy compatibility, and GraphQL is only available through wrappers.
**When does SOAP still appear?**
In legacy enterprise integrations — SAP, mainframes, banking — and industry standards that mandate it. For new Dynamics development it is almost always the wrong choice.
**When is GraphQL worth adding?**
When a client-rich or mobile front end benefits from requesting exactly the shape it needs, or when several back ends are federated behind one endpoint. Add it alongside OData rather than replacing it, and enforce query depth limits.
**What is the most common OData mistake?**
Over-fetching — calling endpoints without $select and pulling every column. $select and $expand together usually make a single OData call as efficient as a GraphQL query.
---
# Solution Checker and App Checker in Power Platform
How Solution Checker analyses Dataverse solutions for issues — categories of findings, integration with Managed Environments.
Source: https://www.solvingdynamics365.com/guides/solution-checker-and-app-checker
Section: Power Platform / ALM & governance
Published: 2026-05-01
Power Platform's static analysis tools — **Solution Checker** for Dataverse solutions and **App Checker** for canvas apps — surface issues before they bite in production. Performance traps, deprecated APIs, security warnings, accessibility issues, plugin best-practice violations. Used systematically, they catch issues that would otherwise emerge as user-facing problems.
## Solution Checker scope
Analyses Dataverse solution content:
- Plug-in code (.NET DLLs).
- Web resources (JavaScript, HTML, CSS).
- Workflow definitions.
- Power Automate flows.
- Forms, ribbons, sitemaps.
- Custom connectors.
- Metadata (tables, columns, relationships).
**Findings categories.**
- **Performance** — patterns that slow operations (`RetrieveMultiple` without paging, excessive plug-in cascading).
- **Reliability** — patterns that cause runtime failures (null reference risks, missing exception handling).
- **Security** — patterns risking unauthorised access (plug-in running as system without checks, hardcoded credentials).
- **Usability and accessibility** — forms missing labels, poor keyboard navigation.
- **Best practices** — deprecated APIs, outdated patterns.
Findings have severity (Critical, High, Medium, Low) and category. Each links to documentation explaining the issue.
**Running Solution Checker.**
- **From the maker portal** — Solution → Run Solution Checker.
- **From Power Platform admin centre** — at scale across environments.
- **From CI/CD pipelines** — via `pac` CLI or Build Tools.
- **Automatic on import** — when Managed Environments + enforcement enabled.
Per run, a report lists findings with file/object/line references.
## Managed Environments enforcement
With Managed Environments, Solution Checker can be enforced:
- Solutions must pass before import to production.
- Critical/High findings block; lower severities warn.
- Bypass requires admin justification (audit logged).
This is the lever that turns Solution Checker from optional to load-bearing in the ALM pipeline.
## App Checker — canvas apps
Built into Power Apps Studio:
- Live findings as the maker designs.
- Performance warnings (slow data sources, large galleries).
- Accessibility violations.
- Formula errors.
- Connector usage patterns.
App Checker runs continuously in the studio; serious issues block save / publish.
**Performance findings (canvas apps).**
- **OnStart load patterns** — heavy logic blocks app start.
- **Filter / Search not delegating** — performance collapses on large data.
- **Excessive use of Set()** — variables proliferating.
- **Image controls referencing large blobs** — load slow.
**Accessibility findings.**
- **Color contrast** — text too light against background.
- **Missing AccessibleLabel** on controls.
- **Tab order** chaotic.
- **No keyboard navigation** path.
For organisations subject to accessibility regulations (US Section 508, European EN 301 549), App Checker is the first-line tool.
## Delegation warnings
Specific to Power Fx on data sources:
- Some functions delegate (server executes); others don't (client downloads all rows).
- Non-delegating function on a large data source = performance bomb.
- App Checker flags non-delegating patterns with yellow warning.
Makers can ignore the warning (often without consequence on small data); large-data scenarios must respect it.
## False positives
Both tools produce some false positives:
- A plug-in genuinely needs to run as system; finding flagged but is correct.
- A canvas app uses a function intentionally despite delegation warning.
Annotations on the codebase mark explicit acknowledgments — "I read this finding, this is intentional."
## Custom rules
Limited but growing:
- Organisations can author custom rules for Solution Checker.
- Specific to internal coding standards.
- Less mature than for traditional linters.
**Reporting and dashboards.**
- **Per-solution finding count** over time.
- **Most common finding categories** — coaching theme for makers.
- **Trend** — are we getting cleaner or accumulating debt?
**Common pitfalls.**
- **Findings ignored.** Run Solution Checker, look at output, dismiss; the findings reappear in production as incidents.
- **No baseline.** New project has 500 findings; team disheartened; sets unrealistic expectations.
- **All-or-nothing enforcement.** Critical findings block; team has to fix 50 critical findings before any deployment; frustration.
- **Outdated rule sets.** Tools update; new patterns flagged; baseline shifts.
- **Solution Checker only at deployment.** Should run continuously during development, not gate-keep at the end.
**Integration with development.**
- **Local checker** — run during development.
- **Pre-commit hooks** — run on every commit.
- **Pull request gates** — must pass to merge.
- **Deployment gates** — must pass to promote to production.
Each layer catches issues earlier; left-shift saves time.
**Operational rhythm.**
- **Continuous in development** — App Checker runs live.
- **Per commit** — Solution Checker via CI.
- **Pre-deployment** — required for production import.
- **Periodic audit** — re-scan existing solutions; track debt.
## Strategic positioning
Solution Checker and App Checker turn intuition-driven quality into data-driven quality. They don't catch everything — domain-specific bugs, business logic errors, integration issues escape — but they catch a meaningful fraction of common issues at low cost. Mature Power Platform programmes treat them as essential development tools, not optional reports. The investment in addressing findings systematically pays back in fewer production incidents and easier maintenance.
---
# Solution dependencies and managed layer conflicts
How solution dependencies work in the Power Platform — required components, layer stacking, conflict resolution, and the maintenance discipline.
Source: https://www.solvingdynamics365.com/guides/solution-dependencies-and-managed-layer-conflicts
Section: Power Platform / ALM & governance
Published: 2026-05-01
Power Platform solutions don't live in isolation. They reference Microsoft's standard components, ISV components from AppSource, and components from other internal solutions. Understanding **dependencies** and **managed layers** is essential for clean deployment, predictable behaviour, and successful upgrades.
**Component dependencies.**
A solution component depends on others when it references them:
- A **flow** depends on **Dataverse tables** it reads or writes.
- A **canvas app** depends on **connection references** it uses and **tables** it references.
- A **business rule** depends on the **fields** it references.
- A **report** depends on the **tables** and **views** it queries.
- A **plug-in** depends on the **assemblies**, **tables**, and **other plug-ins** it interacts with.
When a solution is exported, dependencies are tracked. When the solution is imported into a target environment, all dependencies must be present — either in the target already, or imported as separate solutions first.
**Tracking dependencies.**
The maker portal's **Dependencies** view on each solution and each component shows:
- **Components that depend on this** — who's pointing at me.
- **Components I depend on** — what I need to function.
Before deleting a component, check who depends on it. Removing a field that 50 flows reference breaks all 50.
## Solution dependency chain
Solution A depends on Solution B (e.g. *Customer Service Customisations* depends on the Microsoft *Customer Service* base solution). Imports must happen in order:
1. Microsoft base solution (Customer Service) — already in the environment from Dynamics 365 install.
2. ISV solution from AppSource (industry vertical for service).
3. Customer-customisation solution layered on top.
The target environment must have all parent solutions before child solutions can import.
**Managed layers.**
When multiple solutions modify the same component, they stack as **layers**:
- **Layer 0**: System defaults — the original definition shipped by the platform.
- **Layer 1+**: Each managed solution that touches the component adds a layer.
- **Top layer**: Unmanaged customisations in the dev environment.
The component's effective behaviour is determined by the **topmost active layer**. Underlying layers are hidden but preserved; if a top layer is removed (solution uninstall), the next layer down takes effect.
The **Solution Layers** view on each component lists the layers stacked there, with the source solution for each.
**Conflicts and resolution.**
When multiple managed solutions modify the same component (e.g. two AppSource ISV solutions both adding columns to the Account table), the system stacks both layers; runtime behaviour combines both modifications.
For more substantive conflicts (two solutions defining the same workflow on the Account, two solutions changing the same field's display name):
- The **last imported** wins typically.
- But the system tries to preserve all modifications, which can produce surprising layered effects.
- Conflicts are visible in the Solution Layers view.
Resolving conflicts is manual — remove one layer's modification or merge intent into one solution.
**Common patterns.**
- **Microsoft base + AppSource ISV + customer customisation.** Three layers, in that order. The customer-customisation solution depends on the ISV depends on the Microsoft base.
- **Multiple customer solutions for separate features.** A *Sales Customisations* solution, a *Service Customisations* solution, a *Reporting* solution. Each has its own scope; minimal overlap. Clean dependency graph.
- **One-big-solution anti-pattern.** A single huge customer solution containing everything. Simpler to deploy but harder to reason about, slower to import, harder to retire individual features.
**Uninstalling solutions.**
Uninstalling a managed solution removes its layer. The underlying state takes effect again. But:
- **Data is not removed** — records that depend on the solution's tables remain.
- **Dependencies must be checked** — if other solutions depend on this one, uninstall is blocked.
- **Order matters** — uninstall top-most solutions before underlying ones.
**Common pitfalls.**
- **Circular dependencies** — solution A depends on B and B depends on A. The system rejects this; resolve by separating shared components into a third solution.
- **Missing dependency on import** — solution import fails because a required parent isn't in the target. Import the parent first.
- **Orphan layers after uninstall** — the layer is removed, but the data referencing the removed components becomes orphan. Data cleanup may be needed.
- **Solution gigantism** — solutions grow to encompass everything; imports take hours; reasoning is impossible. Split.
**Operational discipline.**
- **Map your solution dependency graph** — document which solutions depend on which.
- **Plan release order** — when releasing multiple solutions together, plan import order.
- **Audit layers periodically** — accumulated layers from old solutions clog environments.
- **Refactor solutions** when their scope grows unmanageable.
Healthy solution architecture pays back over years of operation.
---
# Solution history and rollback strategies in Dataverse
How to track solution changes over time and roll back when promotions go wrong — solution history table, backup-first patterns.
Source: https://www.solvingdynamics365.com/guides/solution-history-and-rollback-strategies
Section: Power Platform / ALM & governance
Published: 2026-05-01
When a production solution promotion goes wrong — a workflow regression, a broken plug-in, an incorrect form change — the question becomes: how do we get back to the previous state quickly? Dataverse provides some native rollback capabilities but with important limits. A robust rollback strategy combines native features with deployment discipline.
## Solution history
Dataverse maintains a **Solution History** record for each import:
- Solution name and version.
- Type (managed/unmanaged).
- Operation (Install, Upgrade, Update, Patch, Uninstall).
- Start and end timestamps.
- Status (success, failed).
- Linked solution file.
Navigation: Power Platform admin centre → environment → Solutions → History; or in maker portal.
Each history record corresponds to one promotion. Auditable trail of what was installed when. The history doesn't include unmanaged-solution changes — only solution-aware operations.
## Solution layers
Multiple managed solutions can layer over the same component (table, column, form). The **active layer** shows which solution's customisation is currently active. When a solution is uninstalled, its layer is removed, exposing the layer beneath.
This is the foundation of rollback: if Solution v2 introduces a bug, uninstalling it (or installing v1 as a higher version) re-exposes v1's behaviour.
**The four rollback approaches.**
**1. Solution version rollback (managed solutions).** Install the previous version as a managed solution upgrade:
- Take the previous managed solution package (`MySolution_1.0.0.0.zip`).
- Import to the broken environment.
- The platform replaces v2 with v1.
- Data is preserved (rows aren't deleted on solution rollback).
This is the cleanest rollback when the previous package is archived. It requires *archiving every production package* before its successor lands — pipeline practice.
**2. Solution patch reversal.** If the change was a patch (not a new version), reverse-patching is more nuanced. Often easier to uninstall the patch (if uninstall is supported) than to apply a counter-patch.
**3. Manual repair in the UI.** Open the broken environment in the maker portal; revert the specific changes that broke. Risky and error-prone; only viable for tiny issues. Doesn't update solution metadata cleanly — drift between solution and environment results.
**4. Restore from backup.** Each environment has automated **system backups** (typically every few hours, retained 7–28 days depending on tier). Restoring rolls the environment back to a backup timestamp — including data changes since.
This is the nuclear option:
- Wipes all data created since the backup.
- Acceptable for some severe cases where data corruption accompanies the bad deployment.
- Not acceptable for most production rollbacks because of data loss.
## Backup-first pattern
Before every production solution import:
- Take a manual backup (the admin centre supports this).
- Note the backup label.
- Import the solution.
- If the import fails or produces unexpected behaviour, restore the backup.
This is the safety net; configure it as a mandatory pipeline step before any production import.
## Pre-deployment validation
The cheaper rollback is the one you don't need:
- **Test environment** — every solution lands in test before prod; smoke tests run.
- **Solution checker** — static analysis catches many regressions before deployment.
- **Automated tests** — Easy Repro framework, custom Power Fx tests, or external test harnesses; run before promotion.
- **Approval gates** — admin must sign off on prod imports.
A robust pre-prod testing discipline reduces production rollback frequency by an order of magnitude.
## Tracking changes outside solutions
Some changes don't go through solutions:
- **Direct database operations** by users with admin rights.
- **Power Apps and flows** edited directly in prod.
- **Workflow / business rule changes** edited without solution awareness.
These changes don't appear in solution history; rolling them back requires backups or re-editing. The Managed Environments setting "block direct production changes" mitigates this.
**Common pitfalls.**
- **Previous package not archived.** Can't rollback because the v1 package was lost.
- **Backup retention period misunderstood.** Backups only last so long; major regressions discovered weeks later have no backup option.
- **Data created since the bad deployment is valuable.** Restoring loses it; manual repair of v2 with care to preserve data is the only path.
- **Cascading dependencies.** Solution A's rollback breaks Solution B that depended on changes in A. Solutions should be released together and rolled back together for related changes.
- **Async work in flight.** Rolling back while async jobs are processing creates inconsistent state.
## Operational rule
Build the rollback path explicitly:
- **Archive every production solution package** in a versioned artifact store.
- **Pre-import backup** mandatory before any production solution import.
- **Document the rollback procedure** as runbook.
- **Test the rollback** periodically in a sandbox.
A team that has never rehearsed a rollback discovers in the middle of an incident that their plan doesn't work. The rehearsal is the value, not just the documentation.
---
# Solution import / export pipelines for Dataverse
How to automate Dataverse solution promotion through dev / test / prod — Power Platform CLI, Build Tools, GitHub Actions, and Power Platform Pipelines.
Source: https://www.solvingdynamics365.com/guides/solution-import-export-pipelines
Section: Power Platform / ALM & governance
Published: 2026-05-01
A Dataverse solution moves through environments — typically dev → test → prod, sometimes with additional pre-prod or staging layers — via export, import, and publish. Manual promotion is slow and error-prone. **Pipelines** automate this lifecycle, and there are now several distinct approaches with different trade-offs.
**The lifecycle being automated.**
1. Maker / developer builds in **dev environment**, creating components in an unmanaged solution.
2. Solution is **exported** as a managed solution package.
3. Package is **imported** to test environment.
4. Tests pass.
5. Package is **imported** to production.
Manual: download a ZIP, click upload in target environment. Repetitive, error-prone, no audit trail. Pipelines fix all three.
## Approach 1: Power Platform CLI (`pac`)
The command-line tool ships with everything needed for scripted solution management:
```
pac auth create --url https://dev.crm.dynamics.com
pac solution export --path mySolution.zip --name MySolution --managed
pac auth select --index 2 # switch to test environment
pac solution import --path mySolution.zip
```
Scriptable from any CI/CD runner — GitHub Actions, Azure DevOps Pipelines, Jenkins, GitLab CI. Minimal abstraction; pure commands.
## Approach 2: Power Platform Build Tools
Microsoft-published tasks for Azure DevOps Pipelines and GitHub Actions:
- `microsoft/powerplatform-actions/who-am-i@v1` — verify connectivity.
- `microsoft/powerplatform-actions/export-solution@v1` — export.
- `microsoft/powerplatform-actions/import-solution@v1` — import.
- `microsoft/powerplatform-actions/pack-solution@v1` — pack unpacked solution.
- `microsoft/powerplatform-actions/unpack-solution@v1` — unpack solution for source control.
These are wrappers over `pac`. Cleaner pipeline syntax; integrated with CI/CD tooling.
## Approach 3: Power Platform Pipelines
A Power Platform–native, in-product capability under Managed Environments:
- Configure dev → test → prod stages in the maker portal.
- Makers click "Deploy" — solution promotes through the pipeline.
- Approvals at each stage.
- Audit log in the platform.
Designed for citizen developers; no need to learn YAML or CI/CD. Less powerful than full GitHub Actions; great for low-code teams.
**Comparing the three.**
| Aspect | `pac` scripts | Build Tools | Power Platform Pipelines |
|---|---|---|---|
| Audience | Pro devs | DevOps teams | Citizen makers |
| Source control | Native | Native | Limited |
| Approval gates | Via CI | Via CI | Built-in |
| Branching strategy | Full | Full | None |
| Solution patches | Yes | Yes | Limited |
| Power Apps deployment | Yes | Yes | Yes |
| Cost | Free | Free (license-dependent) | Bundled with ME |
## Source control pattern
The mature pattern: solutions are *not* the source of truth. The source of truth is **unpacked solution source** in a git repository.
- `pac solution unpack --zipfile solution.zip --folder src/Solution/` — explodes the ZIP into a directory tree of XML, JSON, JS, CS files.
- Developers commit changes to the source tree.
- CI pipeline packs the source back into a ZIP and imports to the environment.
This pattern enables diffs, code review, branching, conflict resolution — proper engineering workflow. The alternative (export-import shuttling) loses all this.
**Managed vs unmanaged.**
- **Unmanaged** — for development environments where active editing happens.
- **Managed** — for everywhere else; layers prevent unauthorised changes.
Promote unmanaged from dev → export as managed → import managed to downstream. Mixing layers creates messes.
## Solution dependencies
A solution depends on tables, columns, web resources from other solutions. Pipeline must promote dependencies first. Most pipelines:
1. Build all solutions.
2. Topologically order by dependency.
3. Import in order.
**Solution upgrades vs patches.**
- **Solution upgrade** — replace the previous managed solution version completely; clean state.
- **Solution patch** — apply a delta on top of the previous version; smaller package.
For complex production deployments, upgrades; for hotfixes, patches.
**Common pipeline failures.**
- **Missing dependencies** — solution X imported before Y it depends on; fails.
- **Schema breakage** — column type change between versions; import fails.
- **Workflow assemblies version mismatch** — plug-in DLLs binary-incompatible with target.
- **Solution layer drift** — manual changes in target environment block the managed layer; "drift detection" should fail the pipeline early.
- **Connection references missing** — connections need to be created in target before solution imports.
## Connection references and environment variables
Solutions reference external resources via:
- **Connection references** — abstract references to connectors; bound to actual connections per environment.
- **Environment variables** — configurable values per environment.
Pipelines set these up post-import — either through pipeline scripts or manual configuration. Without them, flows and connectors fail to run in the target environment.
**Common pitfalls.**
- **No automation.** Manual promotion in 2026 is hard to justify; pipelines pay back fast.
- **Skipping test environment.** "Just promote to prod" — production crashes; rollback under pressure.
- **No rollback strategy.** Bad import in prod; no clean way back. Always have export-of-previous before import-of-new.
- **Secrets in pipeline scripts.** Connection strings, API keys committed; rotate compromised credentials.
- **No success metrics.** Pipeline succeeds technically; nobody verifies the solution actually works in target.
## Operational rule
Every production Dataverse environment should be downstream of a pipeline — not directly editable by makers in production. The pipeline enforces process, audit, and rollback safety. The maker's perception of "I just made a change" should be implemented as "the pipeline promoted my change," not as "I clicked Save in prod."
---
# Solution patches vs solution upgrades
How patches and upgrades differ in Power Platform solution lifecycle — what each does, when to use which, and the trade-offs across layers.
Source: https://www.solvingdynamics365.com/guides/solution-patches-vs-solution-upgrades
Section: Power Platform / ALM & governance
Published: 2026-05-01
In the Power Platform solution lifecycle, deploying changes to an existing solution in a target environment can happen two ways: as a **patch** or as an **upgrade**. Both look similar from the maker's perspective but produce fundamentally different states in the target environment, and the long-term implications of each pattern matter for ongoing maintenance.
**Solution patches.**
A **patch** is a delta — a solution that contains *only the changes* made since the base solution version. When a patch is imported, it's layered on top of the existing base solution in the target environment. The base solution remains unchanged in the target environment; the patch adds its modifications on top.
**Characteristics:**
- **Faster to build and deploy** — only the changed components are packaged.
- **Smaller solution files** — minutes to import rather than hours.
- **Multiple patches can stack** — patch 1, patch 2, patch 3 all layer on top of the base.
- **Cannot remove components** — patches can only add or modify, not delete components from the base.
- **Eventually cumulate** — over time, the patch stack grows messy.
**When to use patches:** Quick fixes, hotfixes, additive features that don't restructure existing components. Especially useful for production hotfixes where a full re-deploy would be too disruptive.
**Solution upgrades.**
An **upgrade** is a full replacement — the new solution version replaces the existing base solution and all its patches in the target environment. The system reconciles the new version against the existing state, applying additions, modifications, and *deletions*.
**Characteristics:**
- **Comprehensive** — captures the full current state of the solution.
- **Can remove components** that were in the base but no longer in the new version.
- **Slower to build and deploy** — larger package, more processing.
- **Replaces patches** — after an upgrade, the patch stack collapses into the new base.
- **More disruptive** — longer import time, potentially affecting running services.
**When to use upgrades:** Planned major releases, end-of-month rollups consolidating recent patches, major feature waves where significant components have changed.
**The combined pattern.**
The healthy lifecycle pattern:
1. **Base solution** in production.
2. **Patches** for incremental changes (weekly, biweekly, or on demand for fixes).
3. **Upgrade** periodically (monthly, quarterly) consolidating the patches into a new base.
This combines the speed of patches with the cleanliness of periodic upgrades. Avoid letting the patch stack grow indefinitely; it becomes harder to reason about, harder to maintain, and slower to deploy as patches multiply.
## Apply upgrade vs Stage for upgrade
When importing an upgrade, two modes:
- **Apply upgrade** — applies the upgrade immediately. The new version replaces the old in one operation.
- **Stage for upgrade** — imports the new version as a "Holding" solution alongside the existing one, then a separate "Apply solution upgrade" step finalises. Lets you test the staged solution before committing.
The stage-then-apply pattern is safer for production deployments where validation between import and activation matters.
**Managed vs unmanaged considerations.**
- In **development environments** (where the base is unmanaged), patches and upgrades work the same way but components can be edited.
- In **production environments** (where the base is managed), patches and upgrades override the managed components in their layer; underlying managed components remain read-only.
- **Solution layers** stack — managed components from one solution can be modified by patches from another, with the most-recent layer winning.
**Common pitfalls.**
- **Forgetting components are missing from upgrade** — you intended to delete component X from the base, but it's still in production because the upgrade reconciliation missed it. Verify post-upgrade.
- **Patch overload** — 50 patches on top of a base from a year ago. Performance degrades; troubleshooting gets painful. Consolidate.
- **Importing patches in wrong order** — patches generally must be imported in sequence; out-of-order imports may fail or produce surprising states.
- **Patches that conflict** — two patches both modifying the same component create conflicts the system resolves automatically (last one wins), sometimes surprisingly.
**Operational discipline.**
- **CI/CD pipelines** for both patch and upgrade workflows, with appropriate approval gates.
- **Versioning convention** — semantic versioning on base solutions and patches: `1.0.0` base, `1.0.1` patch, `1.1.0` minor upgrade, `2.0.0` major upgrade.
- **Documentation** — what's in each patch and upgrade, communicated to stakeholders.
- **Quarterly consolidation** — fold patches into a new base periodically.
Done right, the patch-and-upgrade rhythm keeps deployments fast and reliable; done badly, it degrades into an unmanageable mess over months.
### Frequently asked questions
**What is the difference between a solution patch and an upgrade?**
A patch is a delta containing only components changed since the base version, layered on top of the base — small, fast, but unable to delete components. An upgrade is a full replacement that reconciles additions, modifications, and deletions and collapses the patch stack into a new base.
**Can a patch remove a component?**
No. Patches only add or modify. To delete a table, column, or flow from the target environment you must ship an upgrade, and verify after import that the reconciliation actually removed it.
**What is the healthy patch-and-upgrade rhythm?**
Patches for weekly or on-demand fixes, consolidated into an upgrade monthly or quarterly. Letting fifty patches pile on a year-old base degrades performance and makes troubleshooting painful.
**What is stage for upgrade?**
Importing the new version as a holding solution alongside the existing one, validating it, then running a separate apply step. It is the safer path for production where checks between import and activation matter.
---
# Stakeholder management for Dynamics 365 implementations
How to identify, engage, and manage stakeholders through a Dynamics 365 project — RACI, communication plans, influence mapping.
Source: https://www.solvingdynamics365.com/guides/stakeholder-management-for-dynamics-365
Section: Implementation / Project execution
Published: 2026-05-01
A Dynamics 365 implementation affects many people — executives funding it, business users using it, IT supporting it, partners delivering it, vendors of integrated systems. **Stakeholder management** ensures the right people are engaged at the right level at the right time. Done poorly, projects ship to surprised stakeholders who don't adopt; done well, projects launch with stakeholder buy-in.
**Who's a stakeholder.**
- **Executive sponsor** — funds and supports.
- **Project sponsor** — operational owner.
- **Business leaders** — affected functional heads.
- **End users** — daily system users.
- **IT leadership** — technical accountability.
- **Process owners** — own affected processes.
- **Subject matter experts** — domain knowledge.
- **External partners** — implementation partner, integration partners.
- **Customers / suppliers** — affected externally.
- **Regulators** — compliance bodies.
- **Board** — for material investments.
Each has stake, interest, and influence; each warrants attention.
**Stakeholder identification.**
- List by role.
- Include each affected function.
- Identify formal and informal influence.
- Capture in stakeholder register.
Often: 30-100 stakeholders for a typical mid-market project.
**Stakeholder analysis.**
Per stakeholder:
- **Interest** — how affected.
- **Influence** — power over outcome.
- **Position** — supportive / neutral / resistant.
- **Concerns** — what worries them.
- **Communication preference** — format, frequency.
The analysis informs engagement strategy.
## Influence-interest matrix
Classical model:
- **High influence + high interest** — manage closely; senior engagement.
- **High influence + low interest** — keep satisfied; not overwhelmed.
- **Low influence + high interest** — keep informed.
- **Low influence + low interest** — monitor.
Different engagement intensity per quadrant.
**RACI per decision type.**
- **Responsible** — does the work.
- **Accountable** — answers for outcome.
- **Consulted** — input solicited.
- **Informed** — kept aware.
For each major decision type, define RACI; reduces ambiguity.
**Communication planning.**
- **What** — content per audience.
- **Who** — sender, recipient.
- **When** — frequency.
- **How** — format (email, meeting, demo, report).
Plan upfront; adjust as project evolves.
**Communication channels.**
- **Executive briefings** — concise, status-focused.
- **All-hands** — milestone announcements.
- **Departmental sessions** — function-specific.
- **Power user community** — change ambassadors.
- **Newsletters / portal** — broader.
- **Training events.**
- **Q&A sessions** — open forum.
Different audiences need different formats.
**Building support.**
- **Show progress** — early wins visible.
- **Address concerns** — surface and respond.
- **Demonstrate value** — link to business outcomes.
- **Listen** — feedback acknowledged.
- **Personalise** — what's in it for them.
Support isn't passive; built actively.
**Managing resistance.**
- **Acknowledge** — concerns are valid.
- **Understand** — why is this person resistant?
- **Engage** — give them voice.
- **Adapt** — adjust where reasonable.
- **Override** when necessary — but visibly and respectfully.
Pure ignoring resistance never works; surfacing and addressing usually does.
**Change champions.**
- **Identify influential supporters** in each area.
- **Equip them** — early visibility, training.
- **Empower** — they speak with credibility.
- **Recognise contribution.**
Champions accelerate adoption; bypassing them slows it.
**Common stakeholder issues.**
- **Sponsor disengagement.** Active early, fades; project loses air cover.
- **Mid-level resistance.** Managers defend status quo.
- **End user surprise.** First exposure to new system is at training; insufficient prep.
- **External party gaps.** Suppliers, customers not informed; integration breaks at go-live.
- **Conflicting priorities.** Two stakeholders want different things; resolution required.
**Stakeholder mapping over time.**
- **Pre-project** — stakeholders identified.
- **Early project** — engagement intense.
- **Build phase** — focused engagement.
- **UAT / Cutover** — broad re-engagement.
- **Hypercare** — close support.
- **Steady state** — ongoing governance.
Cadence of engagement varies; full re-mapping at major transitions.
**Communication artifacts.**
- **Project portal** — central information.
- **Status reports** — periodic.
- **Town halls** — milestone events.
- **Training materials.**
- **FAQs.**
- **Demo videos.**
Mix of pull (portal) and push (reports, town halls).
## Customer stakeholder management
When customers affected (B2B mostly):
- **Pre-announcement** of upcoming changes.
- **Migration communication.**
- **Support during transition.**
- **Post-cutover check-in.**
External stakeholders are easy to overlook; significant brand risk if mishandled.
**Vendor stakeholder management.**
- **Existing integration partners** affected.
- **New ISV vendors** onboarded.
- **Microsoft account team** informed.
Coordination prevents end-of-project surprises.
**Common pitfalls.**
- **Stakeholder map outdated.** People move; map static.
- **Communication frequency wrong.** Too much or too little.
- **One-size-fits-all messaging.** Same content to all; doesn't resonate.
- **No feedback loop.** Communicated to, not heard from.
- **Champion network neglected.** Champions burn out without support.
- **Late escalation.** Resistance hidden until late; too late to address.
**Cultural considerations.**
- **Hierarchical organisations** — respect levels.
- **Collaborative cultures** — broader consultation.
- **Risk-averse cultures** — emphasise mitigation.
- **Action-oriented** — focus on progress.
One-size doesn't fit; adapt approach.
## Strategic positioning
Stakeholder management is one of the highest-leverage soft skills in project leadership. Implementations fail more often from stakeholder issues than technical ones. The discipline of identifying, engaging, and listening to stakeholders prevents the biggest project failure modes.
For project leaders:
- Map stakeholders deliberately.
- Engage proportionally to influence and interest.
- Communicate consistently.
- Address resistance early.
- Build champion network.
- Reassess regularly.
The investment is meeting time and intentional communication; the benefit is stakeholders who back the project through inevitable difficulties. The teams that get stakeholder management right ship to acceptance; the teams that don't ship to resistance.
---
# Statement of Work for Dynamics 365 implementations
How to structure an effective SOW for a Dynamics 365 engagement — scope, deliverables, acceptance criteria, change control, and the protections both sides need.
Source: https://www.solvingdynamics365.com/guides/statement-of-work-for-dynamics-365
Section: Implementation / Vendor & contracting
Published: 2026-05-01
A Statement of Work (SOW) is the contractual document that defines what an implementation partner will deliver, when, for how much, and on what terms. Vague SOWs lead to disputes and cost overruns; well-structured SOWs hold both parties accountable while preserving flexibility for real-world adjustments.
**Core SOW components.**
- **Scope of work** — what's being done.
- **Deliverables** — specific outputs.
- **Timeline** — milestones and dates.
- **Resources** — staffing.
- **Pricing** — cost and payment terms.
- **Acceptance criteria** — how success is measured.
- **Change management** — process for scope changes.
- **Assumptions** — preconditions for the work.
- **Risks** — known risks and mitigations.
- **Roles and responsibilities.**
Each section deserves real attention; templates are starting points, not endpoints.
## Scope of work
Explicit:
- Which Dynamics 365 modules?
- What functional areas?
- Which integrations?
- How many users / legal entities?
- Specific business processes to be implemented?
Out-of-scope items also listed — what's not included.
## Deliverables
Tangible outputs:
- **Functional Design Documents (FDDs).**
- **Technical Design Documents (TDDs).**
- **Configured environment.**
- **Custom code / extensions.**
- **Test scripts and results.**
- **Training materials.**
- **Cutover plan.**
- **Documentation.**
Each deliverable described with:
- Description.
- Format.
- Acceptance criteria.
- Owner.
## Timeline
Milestones:
- Project kick-off.
- Design phase completion.
- Build phase completion.
- UAT start / completion.
- Cutover.
- Go-live.
- Hypercare end.
Dates with dependencies; critical path identified.
**Resource commitments.**
- Named team members.
- Roles (architect, developer, business analyst).
- Allocation percentages.
- Duration of engagement.
Beware "team members to be named" — vague.
## Pricing structure
Match to project type:
- **Fixed price** — clear deliverables, clear scope.
- **Time and materials** — exploratory, evolving scope.
- **Milestone-based** — payments tied to deliverable acceptance.
- **Capped T&M** — cost ceiling.
Each has implications; the right choice depends on certainty of scope.
## Acceptance criteria
How is each deliverable judged complete?
- **Document deliverables** — reviewed and signed off.
- **System deliverables** — meets functional and non-functional requirements.
- **Test deliverables** — pass rate above threshold.
Specific criteria prevent "looks fine to us" disputes.
## Change management process
Inevitable in any real project:
- **Change request** initiated by either party.
- **Impact assessment** — scope, schedule, cost.
- **Approval** — by both parties.
- **Updated SOW addendum** or change order.
Without documented process, every change is an argument.
## Assumptions
Preconditions:
- "Customer provides timely access to subject matter experts."
- "Existing systems documentation is current."
- "Customer has data ready for migration by date X."
If assumptions don't hold, partner can invoke renegotiation. Document candidly.
## Risks
Known risks:
- Data quality.
- Stakeholder availability.
- Integration complexity.
- Custom development scope.
For each, mitigation approach.
## Roles and responsibilities
Who does what:
- **Customer responsibilities** — provide data, attend meetings, sign off.
- **Partner responsibilities** — deliver per scope.
- **Joint responsibilities** — testing, decisions.
A RACI chart often helps.
**Governance structure.**
- Steering committee membership.
- Reporting cadence.
- Issue escalation path.
- Decision authority.
**Termination provisions.**
- For convenience.
- For cause.
- Notice periods.
- Wind-down procedures.
Hopefully never invoked but essential.
**Warranties and remedies.**
- What partner warrants (deliverables work, free of defects).
- For how long (typically 30-90 days post-acceptance).
- Remedies for breach.
**Liability limits.**
- Cap on partner liability typically.
- Carve-outs (IP infringement, confidentiality, gross negligence).
**Intellectual property.**
- Who owns deliverables?
- Pre-existing IP retained by each party.
- Custom code typically client-owned.
## Confidentiality
NDAs separate or integrated.
**Common pitfalls.**
- **Vague scope.** "Implementation of Dynamics 365 Sales" — what does that mean specifically?
- **No change management.** First change request becomes a fight.
- **No assumptions documented.** Partner assumed something; customer didn't; cost overrun.
- **Pricing ambiguous.** "Up to" or "approximately" — interpretation differs.
- **Acceptance vague.** Customer doesn't accept; project drags.
- **No exit clauses.** Either party stuck.
**SOW negotiation.**
- Lawyers and contracts teams involved.
- Take time; rushing produces problems.
- Push back on partner's standard terms where reasonable.
- Customer-friendly language matters.
**Multi-phase engagements.**
- Phase 1 SOW.
- Phase 2 SOW signed at appropriate point.
- Each phase has clear scope and outcomes.
Cleaner than mega-SOW covering everything.
## Master Services Agreement + SOW
A common structure:
- **MSA** — overarching terms (liability, IP, confidentiality).
- **SOWs** under MSA — specific projects.
Reduces negotiation per project; useful for ongoing relationships.
## Strategic positioning
The SOW is the project's commercial backbone. Time invested upfront pays back through clarity and accountability. Common mistake: signing weak SOWs to start work fast — leads to scope creep, disputes, and unhappy outcomes.
For decision-makers:
- Engage legal and procurement early.
- Be specific about scope and deliverables.
- Build in change management.
- Define acceptance objectively.
- Document assumptions candidly.
A well-crafted SOW protects both parties and sets the foundation for a productive partnership. Don't accept the partner's standard template without thoughtful review and negotiation — every clause has implications for the engagement.
---
# Steering committee design for Dynamics 365 programs
How to structure and run a Dynamics 365 steering committee — composition, cadence, agenda, decision rights, and the discipline that keeps programs aligned.
Source: https://www.solvingdynamics365.com/guides/steering-committee-design-for-dynamics-365
Section: Implementation / Operations & support
Published: 2026-08-15
A Dynamics 365 program is a multi-million-dollar, multi-year, cross-functional change initiative. Without senior alignment, the program drifts — competing priorities pull in different directions, decisions get reversed, scope expands without trade-off. The **steering committee** is the executive body that keeps the program aligned. Design and run it well; programs succeed. Skip it or run it badly; programs struggle.
**Composition.**
The steering committee includes:
- **Executive sponsor** — the senior leader accountable for the program's success. Typically a C-level (CFO for ERP programs, COO for operations-focused, CIO for technology-led, sometimes CEO for transformational). Chairs the committee.
- **Functional leaders** — heads of departments materially affected. Finance lead. Sales lead. Operations lead. HR if HR is in scope. Their teams will use the system; they bring the business priorities.
- **IT leader** — CIO or VP of IT. Owns the technology side; accountable for integrations and ongoing operations.
- **Partner sponsor** — the senior partner-side person accountable for the implementation. Brings expertise; held accountable for partner delivery.
- **Program manager** — the customer-side person running the program day-to-day. Prepares agendas; tracks decisions; ensures follow-through.
- **Project manager(s)** — depending on program scale, the PM(s) responsible for execution.
For very large programs, two-tier governance is common — a top-level executive committee (quarterly, big strategic decisions) and a working steering committee (monthly, operational decisions).
**Cadence.**
- **During the project** — monthly is standard; bi-weekly during critical phases (cutover preparation, hypercare).
- **Steady-state operations** — quarterly typically suffices; monthly if change activity continues.
Meetings are real meetings — agendas distributed in advance, decisions documented, follow-up assigned.
**Standard agenda.**
A working steering committee meeting:
1. **Updates from program manager** — status, milestones, key activities since last meeting.
2. **Risk register review** — top risks, mitigation status, new risks.
3. **Issues requiring decisions** — items the program manager has escalated as needing steering input.
4. **Financial status** — budget vs actual, forecasts, committed cost.
5. **Scope status** — what's in scope, what's been added / removed since last review.
6. **Resource status** — people, vendor engagement, contractor utilisation.
7. **Decisions** — explicit votes / consensus on items needing steering decision.
8. **Action items** — follow-up actions assigned to specific committee members.
Each item is short — committee meetings shouldn't be hours-long; 60-90 minutes is the goal.
**Decisions vs information.**
Steering committees decide. Informational updates can happen by email or shorter touchpoints; meeting time should focus on items where the committee adds value:
- **Scope changes** — accept, reject, defer.
- **Major risks** — accept, escalate, mitigate.
- **Resource conflicts** — prioritise across competing demands.
- **Vendor performance issues** — escalate to vendor management.
- **Strategic direction** — major architectural or product choices.
Items that don't need a decision shouldn't dominate the agenda.
**Pre-reads.**
- **Decision items** — distributed 48 hours before the meeting. Each item has context, options, recommendation, decision asked.
- **Status report** — concise, factual, not promotional. Honest about what's behind, ahead, at risk.
Members come prepared; meeting time is for discussion, not for reading the material.
**Documentation.**
- **Minutes** — concise; decisions and action items prominent.
- **Action items** — owner, due date, status. Reviewed at the next meeting.
- **Decision log** — running record of every decision made; referenced as the program proceeds.
Without documentation, decisions get lost; "I thought we decided X" becomes a recurring theme.
**Conflict management.**
Steering committees often surface conflict — finance and operations have different priorities; partner and customer disagree on a design choice; budget vs scope tension. The steering committee is where conflict gets surfaced and resolved.
- **Surface conflict explicitly** — name it; don't paper over.
- **Decisions in the room** — when consensus isn't possible, the executive sponsor decides.
- **No revisiting outside the room** — once decided, the team executes; reversing a decision requires bringing it back to the committee.
**Sponsor accountability.**
The executive sponsor is the single point of accountability for program success. They:
- **Defend the program** internally — protect resources, defend budget against cuts, maintain priority.
- **Make the hard decisions** — when consensus isn't possible.
- **Hold the partner accountable** — for delivery against contract.
- **Hold the team accountable** — for execution.
- **Communicate up** — keep their own peers and superiors aware.
Without an engaged sponsor, programs drift. Sponsor engagement is the single best predictor of program success.
**Common pitfalls.**
- **No steering committee** — program operates without senior alignment; drifts.
- **Steering committee without decision rights** — meetings are theatre; real decisions happen elsewhere.
- **Wrong composition** — missing key functional leader; their priorities ignored; later resistance.
- **Sponsor disengaged** — meetings happen but with reduced effect.
- **Inconsistent attendance** — different attendees each meeting; institutional memory lost.
- **Meeting cancelled when "nothing to discuss"** — alignment work skipped; reappears as crisis later.
## Operational reality
Steering committee discipline is a small overhead — a few hours per executive per month. The return is enormous: a program that stays aligned with the business, decisions made and recorded, sponsors who own outcomes. Design and run the committee like a serious governance function from day one.
---
# Store operations in Dynamics 365 Commerce
How D365 Commerce runs physical store operations — the channel database, offline mode, daily routines, cash management, inventory, and the integration with HQ.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-commerce-store-operations
Section: Finance & SCM / Retail & commerce
Published: 2026-05-01
A retail store needs to keep running when the network drops, the head office is asleep, and the holiday rush hits unexpected volume. **Dynamics 365 Commerce** runs store operations on a distributed architecture — channel databases at each store, replicated transactions to HQ, and POS clients that fall back to offline mode when needed. Understanding the data flow and operational rhythms is essential for any Commerce deployment.
**Architecture overview.**
- **Headquarters (HQ)** — F&O instance holding master data and consolidated reporting.
- **Channel database** — store-level SQL database with the data the store needs.
- **Modern POS (MPOS)** — POS application on store terminals.
- **Cloud POS** — browser-based version for tablets and back-office PCs.
- **Commerce Scale Unit (CSU)** — cloud service or on-premise unit that mediates between POS and HQ.
Data flows: master from HQ → CSU → channel DB → POS; transactions from POS → channel DB → CSU → HQ.
## Channel database
Per store (or per shared physical network of stores). Holds:
- Products and prices effective at that store.
- Customer records.
- Pending and completed transactions.
- Employees and permissions.
- Inventory levels.
The store can run autonomously against this database when the network is down.
## Offline POS
When the connection to CSU drops:
- POS continues operating against the channel DB.
- Transactions captured locally.
- On reconnection, transactions sync to HQ.
The threshold for offline behaviour: if CSU is unreachable for N seconds, POS goes offline. Reconnection automatically re-syncs.
**Daily store routines.**
- **Open store** — first transaction of the day; cash drawer set up.
- **Tender declaration** — operator declares starting cash.
- **Transactions throughout the day.**
- **Shift change** — cashier signs off; new cashier signs on; drawer balanced.
- **End-of-day** — final tender declaration; cash reconciliation.
- **Close store** — settle drawers, run reports, prepare deposit.
Each routine is enforced via store workflow.
## Transactions
Beyond standard sale:
- **Returns** — with or without original receipt.
- **Exchanges.**
- **Layaway** — partial payment, hold inventory.
- **Special orders** — sell items not in stock.
- **Customer orders** — for delivery vs in-store pickup.
The POS handles each transaction type with appropriate UI and accounting.
## Inventory at store level
Critical question: where's the stock?
- **On-hand** — physical at store.
- **In transit** — being transferred between stores or from DC.
- **Reserved** — customer order or hold.
- **Damaged / quarantined.**
POS shows real-time on-hand from the channel DB. Replenishment to the store happens via transfers from DCs.
## Cash management
Stores handle cash:
- **Cash drawer per terminal** — count on open, count on close.
- **Float / starting cash** — set at open, reconciled at close.
- **Drops** — moving cash to safe during the day.
- **Bank deposit** — end-of-day cash to bank.
- **Loomis/Brink's pickup** — cash-in-transit handling.
Cash reconciliation is a core finance control — discrepancies investigated immediately.
## Pricing and promotions
Real-time pricing engine at POS:
- **List price** from product master.
- **Trade agreements** — store-specific pricing.
- **Promotions** — active promo applied automatically.
- **Discount overrides** — manager-approved overrides.
- **Loyalty rewards** — points applied.
Promotions and pricing fully cached in the channel DB so they work offline.
## Loyalty
Loyalty data:
- **Customer profile** with loyalty card.
- **Points balance.**
- **Tier status.**
- **Rewards earned.**
At POS, scanning the loyalty card pulls profile; points earned and burned in transactions.
**Returns processing.**
- **With receipt** — easy; identify original transaction.
- **Without receipt** — manager approval; refund to gift card or store credit; restocking inspection.
- **Damaged returns** — additional processes for quality assessment.
- **Cross-channel** — online purchase returned at store; "endless aisle."
The return policy is configurable; system enforces.
**Workforce management.**
- **Schedules** — store managers schedule employees.
- **Clock in/out** — at POS or dedicated time clock.
- **Hours tracking** — for payroll.
- **Compliance** — break requirements, minor work restrictions.
Integration with HR for employee master; with payroll for hours.
**End-of-day procedures.**
1. Final transactions of the day completed.
2. Each cashier counts down drawer; variance recorded.
3. Manager reviews and approves variances.
4. Final reports printed (sales summary, tender, refunds).
5. Cash deposited or secured.
6. Channel DB syncs to HQ.
This is a 30–60 minute routine per store, often a frustration point if the system is slow.
**Common pitfalls.**
- **CSU connectivity flakey.** Frequent offline-mode transitions; data sync issues; reconciliation problems.
- **Channel DB drift.** Master data not syncing from HQ; store sees wrong prices.
- **Cash variance ignored.** Small daily variances accepted; over months become significant.
- **Offline transactions stuck.** Some transactions not syncing back when online; investigation needed.
- **Performance issues at POS.** Hardware aging; transactions slow; checkout queues form.
- **Wrong tax rates.** Tax configuration off; charges incorrect; reconciliation pain at month end.
## Operational rhythm
Daily open/close routines per store; daily sync to HQ; weekly inventory adjustments; monthly cycle counts; monthly P&L per store. Mature retail operations have well-defined runbooks and clear ownership of each routine.
## Strategic positioning
Retail store operations are the front line of customer experience. Reliability matters — a POS that crashes during checkout loses sales and frustrates customers. The distributed architecture of Commerce is designed for resilience, but it requires attention to ensure each store stays in sync with HQ and that offline-mode transitions are seamless. Investment in store-level operations (training, hardware, network) pays back directly in customer satisfaction and revenue.
---
# Student information system integration patterns for Dynamics 365
How to integrate Dynamics 365 with a student information system — what the SIS keeps, which entities flow into Dataverse and in which direction.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-for-education-sis-integration
Section: Industries / Education
Published: 2026-09-02
Every college and university has a student information system — Banner, PeopleSoft Campus Solutions, Workday Student, Colleague, or a national equivalent — and it is not going anywhere. It owns enrolment, registration, grades, financial aid, and the official student record. Dynamics 365 in education lives around it: recruitment and admissions in Sales and Customer Insights, student services and advising in Customer Service, alumni and advancement afterwards. The integration between the two decides whether the CRM is trusted. This guide covers the patterns that hold up. For where Dynamics 365 fits at all, see [Dynamics 365 for education](https://www.solvingdynamics365.com/guides/dynamics-365-for-education).
## Decide what the SIS owns, in writing
The SIS is the system of record for the student *as a student*: identity once matriculated, programme, enrolment status, term registrations, academic standing, holds, and financial aid status. Dynamics 365 is the system of record for the *relationship*: prospect and applicant data before matriculation, interactions, cases, communications, consent, and after graduation the alumni record.
Write that boundary down as a table of entities with an owner per entity. Every integration argument for the next five years comes back to it, and the projects that skip it end up with advisors editing programme codes in the CRM that the SIS overwrites overnight.
## What flows, and which way
The core feed is SIS to Dataverse, read-mostly:
- **Person** — student identifier, names, demographic fields the institution has decided to share, contact details as held by the SIS.
- **Programme and plan** — what the student is studying, with the academic organisation.
- **Enrolment and term status** — enrolled, withdrawn, on leave, graduated, per term.
- **Holds and flags** relevant to service — a registration hold is exactly what a student-services agent needs to see on the contact.
- **Course enrolments** only if a use case needs them (advising, retention outreach by course). They are the high-volume entity; load them only when someone will act on them.
The reverse direction is narrow: consent and communication preferences maintained in the CRM may need to reach the SIS, and the admissions handoff below creates the student in the SIS. Grades, financial data, and disciplinary records should not enter Dataverse without a specific, reviewed reason.
Microsoft's education accelerator data model for Dataverse — with tables for academic periods, programmes, course sections, and registrations — is a reasonable starting schema, and using it avoids inventing a student table per department.
## Identity matching
The student identifier from the SIS is the key, defined as a Dataverse **alternate key** on the contact so that upserts from the integration are idempotent; the [alternate keys](https://www.solvingdynamics365.com/guides/dataverse-alternate-keys) guide covers them. The hard part is before the identifier exists: a prospect in the CRM who applies through a separate application system and becomes a student in the SIS. The pattern:
1. The CRM contact carries an applicant identifier from the application platform as a second alternate key.
2. When the SIS creates the student, the application identifier travels with it.
3. The SIS-to-Dataverse feed matches on the application identifier first, sets the student identifier, and from then on matches on that.
Matching on name and date of birth is the fallback, must be reviewed by a human, and should be measured — a match rate below what the institution expected is the signal that step two was skipped somewhere.
## The applicant-to-student handoff
Institutions that run admissions in Dynamics 365 Sales and Customer Insights – Journeys — a viable pattern, though the specialist admissions CRMs dominate that market — reach a point where the admitted, deposited applicant must become a student in the SIS. That is a create-in-SIS transaction, usually through the SIS's API or an integration platform, and it is the one place the CRM writes to the SIS. Keep it to the minimum record the SIS needs and let the SIS assign the student identifier, which then flows back.
## Batch or event
Most SIS integrations are nightly batch, and for programme and status changes that is fine. Two categories justify near-real-time: holds and flags that a service desk must see immediately, and events that trigger journeys — a withdrawal that should start a retention outreach within hours, not tomorrow. Modern SIS platforms expose events or webhooks; older ones are polled through a database view or an integration platform. The [polling versus push](https://www.solvingdynamics365.com/guides/polling-vs-push-patterns-for-dynamics-365) guide covers the trade-off; the pragmatic design is nightly batch for everything plus a small event feed for the handful of fields that matter same-day.
Term start is the load test. Registration and status changes for the whole student body arrive within days, and an integration that comfortably handles a hundred changes a night faces fifty thousand. Use batch upserts through the Dataverse API, throttle deliberately, and run the first term start with someone watching.
## Analytics goes the other way
Do not build reporting integrations from Dataverse back to the SIS or from the SIS into Dataverse for analytics. Both belong in a lake or warehouse: Azure Synapse Link or Fabric for the Dataverse side, the SIS's own export for its side, joined on the student identifier. Retention dashboards, yield analysis, and engagement scoring are built there, and the CRM receives only the derived flags it needs to act on (an at-risk indicator, a propensity score) through a small write-back.
## Access and FERPA
US institutions operate under FERPA; others have equivalent student-privacy regimes. In the CRM this means security roles scoped by what each function legitimately needs, column security on directory-restricted fields, and auditing on the student tables. A student who has opted out of directory information must be flagged in the feed and the flag enforced by the roles and by journeys. The [data protection and compliance](https://www.solvingdynamics365.com/guides/dynamics-365-data-protection-and-compliance) guide covers the controls; the education-specific step is mapping each SIS field to a FERPA category before it is loaded.
## Sequencing
Person and status first, matched on the SIS identifier. Then holds and the same-day event feed. Then programme detail and course enrolments if a use case demands them. Then the admissions handoff if the institution runs admissions in Dynamics 365. Institutions that start with the full course-enrolment history load a great deal of data that nobody looks at and delay the feed that student services actually needed.
---
# Subcontracting in Business Central production
How Business Central handles subcontracted manufacturing operations — vendor work centers, the subcontracting worksheet, automatic POs, and cost flow.
Source: https://www.solvingdynamics365.com/guides/subcontracting-in-bc-production
Section: Foundations
Published: 2026-05-25
Manufacturers regularly send work out — heat treatment, plating, anodising, specialty machining, painting, calibration — operations a vendor performs better, cheaper, or because internal capacity is constrained. Business Central's **subcontracting** mechanism handles the workflow: subcontracted routing operations automatically generate purchase orders to the chosen vendor, with the cost flowing back into the production order's cost stack.
**The setup.**
- **Vendor as work center.** Create a **work center** that represents the subcontractor. The work center carries the vendor's number (linking to the vendor card), shop calendar (vendor's availability), and cost rates.
- **Subcontractor field** on the work center — links the work center to a vendor.
- **Routing operations** referencing the vendor work center are automatically subcontracted.
**The flow.**
1. **Production order** is released with a routing that includes one or more subcontracted operations.
2. **Subcontracting worksheet** runs — it scans released production orders for subcontracted operations and proposes purchase orders to the assigned vendors.
3. User reviews proposals and runs **Carry Out Action Message**, which creates the purchase orders.
4. The POs reference the production order; the vendor's quoted price for the service is the PO amount.
5. The user ships intermediate goods (the work-in-progress at the operation's stage) to the vendor — typically tracked as a transfer or a special-purpose shipment.
6. The vendor performs the operation and ships back.
7. **Goods are received** as completed work on the production order — typically captured through the production journal as the next operation's input.
8. The vendor invoices for the service.
9. **Purchase invoice posts** — cost flows into the production order's WIP, becoming part of the finished item's cost.
**The cost mechanics.**
- The subcontracted operation's cost on the routing is what the system expects the operation to cost (estimated or standard).
- The actual vendor invoice may differ (price change, quantity variance, additional charges). Variances post to variance accounts at production order completion.
- For standard-cost items, the difference between routing standard and actual vendor cost becomes a production variance.
**Tracking material across the subcontractor.**
The most common pattern: ship raw or in-process material to the vendor; receive completed work. Several options for tracking:
- **Treat as transfer** — issue a transfer order to the vendor's "location" (modelled as a location card), receive at vendor; post the operation; transfer back to the production line.
- **Issue as consumption** — consume the material against the production order before sending; the vendor sends back the finished work consumed against the operation.
- **Lot / serial tracking** — for sensitive items, every unit tracked to the vendor and back with full traceability.
Operations differ by industry; configure to fit how the floor actually works.
**Quality and rework.**
- Subcontracted work that fails quality can be returned to the vendor for rework.
- The return is tracked as a purchase return; the vendor reships after rework.
- Rework cost may or may not be re-billed depending on contract.
## Capacity planning
Subcontracted work centers can have **finite or infinite capacity** modelling:
- **Finite** — the vendor has limited capacity per period; load is tracked; over-capacity dates re-schedule.
- **Infinite** — assume the vendor accepts any load; load reporting is informational only.
Most subcontracted vendors are modelled as infinite-capacity in BC; vendor relationships rarely encode actual capacity availability.
## Vendor selection
A routing operation is assigned to a specific vendor at routing-creation time. For operations with multiple potential vendors (lowest-price wins, fastest-turnaround wins, certified-supplier-only), the routing carries one vendor and changes go through routing revision — or partner ISVs offer multi-vendor subcontracting modules.
**Reporting.**
- **Subcontracting worksheet** — open subcontracted operations awaiting PO creation.
- **Vendor scorecards** — performance per subcontractor (on-time, quality, cost).
- **Production cost variance** — subcontract variance per item per period.
**Common pitfalls.**
- **Subcontract operation not yet released** — the worksheet doesn't propose POs for not-yet-released production orders. Release sequencing matters.
- **Vendor not linked to work center** — the subcontract routing fails silently; check the link.
- **Material in transit to vendor unaccounted** — physical goods at the vendor but no system record of their location.
- **Vendor invoice for different quantity** — variance handling needs explicit attention.
## Operational reality
Subcontracting in BC works well for standard scenarios. Complex multi-vendor sourcing, dynamic pricing, or sophisticated quality workflows often justify a partner ISV. For mainstream subcontracting in mid-sized manufacturing, BC's built-in is adequate.
---
# Subcontracting in Project Operations
How Project Operations handles subcontractor management — engaging external resources, time and expense capture, billing, and the accounting flow.
Source: https://www.solvingdynamics365.com/guides/subcontracting-in-project-operations
Section: Customer Engagement / Project Operations
Published: 2026-05-01
Subcontracting — engaging external companies or individuals to deliver part of a project — is standard for services businesses managing peak demand, niche skills, or geographic coverage. Dynamics 365 Project Operations handles subcontractor engagement with first-class objects for resource sourcing, time and expense, billing, and accounting reconciliation.
## Why subcontracting is harder than employees
Internal employees come with known cost rates, accessible time-entry tools, and integrated approval flows. Subcontractors come from external vendors with their own rate negotiations, different time-capture experiences, separate accounting flows, and contract-bound deliverables. Project Operations models the differences explicitly.
**The subcontracting flow.**
1. **Identify the need.** A project requirement that can't be filled internally — the resource hub flags it as unfilled or the project manager explicitly requests external sourcing.
2. **Engage a vendor.** The vendor is a Dataverse Account; the agreement is a **purchase agreement** specifying rate, terms, deliverables.
3. **Bookable resource for the subcontractor.** The subcontractor's named individual is created as a **bookable resource of type Account** (or Contact for a specific individual), tied to the vendor.
4. **Booking against the project.** The subcontractor is booked to project tasks like any other resource, with skill match and capacity.
5. **Time and expense capture.** The subcontractor enters time and expense, either directly (through a Power Pages portal granting limited access) or via the prime contractor's project manager entering on their behalf from invoices received.
6. **Approval.** The customer's project manager approves time and expense.
7. **Vendor invoice posts.** A purchase invoice from the subcontractor's company posts in F&O or BC, referencing the project. The cost lands in the project's cost ledger.
8. **Customer billing.** The customer is billed for the work (possibly with markup) as part of the regular project invoicing.
## Cost vs price
The subcontractor's cost (what you pay them) and the customer price (what the customer pays for that work) are distinct. Typical pattern: the project has a "Subcontractor Hours" billable plan billable at the customer rate; the actual cost posts at the subcontractor's vendor rate. Margin equals the difference. Reporting shows both.
**Three engagement models.**
- **Time and Materials subcontracting** — pay the subcontractor for their time at agreed hourly rates; bill the customer at the customer rate.
- **Fixed-fee subcontracting** — pay the subcontractor a fixed amount for a deliverable; bill the customer on the project's terms (possibly fixed-fee, possibly T&M).
- **Capped T&M** — pay the subcontractor T&M up to a capped total; protect against overruns.
## Sourcing through purchase requisitions
For larger organisations, formal sourcing through purchase requisitions and POs gives procurement oversight on subcontractor engagements. The PO references the project and the resource requirement, creating a paper trail.
## Portal access for subcontractors
A **Power Pages portal** can give subcontractors restricted access to log time and expense against the projects they're booked to. Pre-configured permissions limit what they see to their own work, with no exposure to other client projects.
## Compliance
Subcontractor engagements often have regulatory dimensions:
- **IR35 / worker classification** in some countries — is the subcontractor genuinely independent or effectively an employee for tax purposes?
- **Background checks** — required by customer or industry.
- **Confidentiality agreements** — managed as contract documents.
- **GDPR / data protection** — subcontractors processing customer data need explicit data-protection agreements.
Document these alongside the engagement record.
## Reporting
Subcontractor margin per project, per vendor; subcontractor utilisation; subcontractor performance ratings against deliverables; spend by vendor over time.
**Common pitfalls.**
- **Subcontractor cost not posted to project** — billed to customer but no offsetting cost, inflating margin.
- **Time captured without approval** — subcontractor invoices for hours the customer didn't approve.
- **Markup transparency** — some customer contracts require disclosing subcontractor rates; others forbid the customer from knowing.
- **Currency mismatches** — pay in one currency, bill in another; FX gains/losses surprise.
## Operational discipline
Subcontracting works when the engagement is paperwork-disciplined and the time-and-cost flow is honest. Skip the discipline and subcontractor work becomes a profitability mystery.
---
# Subcontracting workflows in Dynamics 365 Supply Chain Management
How subcontracted production works in Dynamics 365 Supply Chain Management — the service-item and vendor-line-type pattern, vendor resources on routes.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-for-manufacturing-subcontracting-in-f-and-o
Section: Industries / Manufacturing
Published: 2026-09-02
Subcontracting — sending a partly finished item to an outside vendor for an operation such as plating, machining, or heat treatment, then getting it back — is routine in discrete manufacturing and awkward in most ERPs. Supply Chain Management has a coherent model for it, but it involves more objects than people expect: a service item, a purchase order, a vendor resource, a vendor warehouse, and a production order that all have to line up. This guide walks the model and the operational decisions around it. For Business Central, see [subcontracting in BC production](https://www.solvingdynamics365.com/guides/subcontracting-in-bc-production); for services businesses, [subcontracting in Project Operations](https://www.solvingdynamics365.com/guides/subcontracting-in-project-operations).
## The model in one paragraph
The subcontracted operation is a route operation whose resource is a **vendor-type resource**. The cost and purchasing of that operation are carried by a **service item** placed on the BOM with **line type Vendor**, which tells the system to create a purchase order to the subcontractor when the production order is estimated. The components the vendor needs are moved to a **warehouse that represents the vendor**. When the service item's purchase order is received, the operation is reported as finished and the production order continues. Costing flows from the purchase price of the service item into the produced item's cost.
Every piece of that sentence is a configuration decision.
## Setting it up
**The vendor resource.** Create a resource of type Vendor linked to the vendor account, put it in a resource group, and use it on the subcontracted operation of the route. Capacity on a vendor resource is usually set to infinite, because the manufacturer does not schedule the vendor's shop. Lead time lives on the operation as run time or, more commonly, as the service item's purchase lead time.
**The service item.** An item of product type Service, with a purchase price from the subcontractor's trade agreement. On the BOM of the produced item, add it as a line with line type *Vendor*, and set the operation number to the subcontracted operation so that the purchase order is tied to the right step. Whether the service item consumes at operation start or finish is a BOM-line flushing decision.
**The vendor warehouse.** The subcontractor's premises are modelled as a warehouse — one per subcontractor if material is tracked at them, or a single "at subcontractor" warehouse if only the accounting matters. The BOM lines for components consumed at the vendor's operation point to this warehouse. Getting them there is a transfer order or a transfer journal, which is the first of the manual steps.
**Line type and purchase order timing.** With line type Vendor, estimation of the production order creates the purchase order to the subcontractor. Schedule the production order and the PO's requested delivery date follows the operation's scheduled end. Change the production schedule after the PO exists and the dates do not update automatically — a planner has to.
## The operational flow
1. Production order created and estimated. PO to the subcontractor is generated for the service item.
2. Components for the vendor operation are transferred to the vendor warehouse. In a warehouse-management-enabled setup, this is a transfer order with picking work; without it, a transfer journal.
3. Physical shipment of components with a packing slip from the transfer order, which doubles as the paperwork the subcontractor needs.
4. Subcontractor does the work. Nothing happens in the system unless vendor collaboration or a portal is in use for acknowledgement.
5. Finished or semi-finished items come back. The service item PO is received; the receipt reports the operation's quantity as finished. If the route operation is the last one, the production order can be reported as finished from here.
6. Vendor invoice matched to the PO. Cost lands on the production order via the service item's consumption.
Two points trip up first implementations. The PO receipt drives the operation feedback, so receiving the wrong quantity or receiving before the goods arrive corrupts the production order's progress. And the material at the vendor warehouse is consumed by the production order at the vendor operation, so if the transfer was skipped, the consumption journal will show negative stock at the vendor warehouse, which is how many manufacturers discover their process is not being followed.
## Costing
The subcontract cost is the purchase price of the service item, which flows into the produced item's cost as a material-type cost by default. Manufacturers that want subcontract cost broken out on the cost roll-up define a dedicated cost group for service items, so that the produced item's standard cost shows material, labour, overhead, and subcontracting separately. Do this at design time; recategorising later means re-rolling every standard cost.
Standard-cost manufacturers also need a policy for subcontract price variance, because the PO price and the standard rarely match. It posts through the normal purchase price variance accounts and is visible per production order.
## Warehouse management and subcontracting
With advanced warehouse management, the vendor warehouse is warehouse-management-enabled or not, and that choice has consequences. Enabling it gives proper picking and shipment work for the outbound transfer but makes the receipt of the service item a warehouse process too, which is unnecessary ceremony for a service. The common compromise: outbound transfers under warehouse management from the main warehouse, vendor warehouse not warehouse-management-enabled, receipt of the service item as a plain PO receipt.
## What is not in the product
There is no subcontractor portal for the vendor to see what is at their site and report progress. **Vendor collaboration** gives the subcontractor PO acknowledgement and invoice visibility, which is useful but not shop-floor status. Partners offer subcontractor portals built on Power Pages. There is also no automatic rescheduling of the subcontract PO when the production order moves; the linkage is created at estimation and maintained by people.
Quality inspection on returned items works through the standard quality management module, with a quality order triggered at PO receipt of the service item — set the quality association on the service item, not the produced item, or the trigger never fires.
## Deciding how much to model
A manufacturer with three subcontractors and a few operations can run the full model comfortably. One with sixty subcontractors and hundreds of service items needs to think about whether every subcontractor warrants a warehouse and whether transfer orders per shipment are sustainable. The alternative — a single vendor warehouse and periodic transfer journals — loses traceability of what is at which vendor. There is no right answer, but the decision should be made deliberately, because changing it after go-live means changing every BOM.
---
# Subscription billing in Dynamics 365 Finance
Microsoft's Subscription Billing module — recurring contracts, revenue recognition, billing schedules, and where it fits in the F&O stack.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-finance-subscription-billing
Section: Finance & SCM / Finance
Published: 2026-05-01
**Subscription Billing** is a relatively recent addition to Dynamics 365 Finance, built to handle the recurring-revenue, contract-driven business models that are now common across software, telecoms, equipment-as-a-service, and B2B services. It replaces a long history of customer-built workarounds for handling subscriptions in AX/F&O.
## Three integrated components
Subscription Billing combines three working units:
1. **Recurring Contract Billing** — manages contracts, billing schedules, mid-term changes (add/remove products, prorations, upgrades/downgrades), and renewals.
2. **Revenue and Expense Deferrals** — manages straight-line and milestone deferrals of revenue or expense across periods, automating the journals.
3. **Multiple Element Allocations** — handles the ASC 606 / IFRS 15 problem of allocating contract revenue across performance obligations when a contract bundles multiple products or services.
## Contracts
A subscription contract holds the customer, term, billing cadence, products, prices, discounts, and any special clauses. Contracts can be billed monthly, quarterly, annually, on milestones, or on usage. Mid-term changes (adding a seat, upgrading a tier, partial cancellation) prorate automatically.
## Revenue recognition
Revenue recognition is decoupled from billing — invoicing a customer for an annual contract doesn't recognise twelve months of revenue at once. The deferral component spreads revenue across the contract period to comply with accounting standards. Performance-obligation-based recognition handles bundled contracts.
## Usage billing
For consumption-based components, usage data feeds Subscription Billing through a Data Management interface or an API, where it's priced and billed alongside the recurring component on the same invoice.
## Pricing
Tiered pricing, volume discounts, ramp-ups, and prepaid balances are all configurable without custom code.
## Integration with the rest of F&O
Subscription Billing posts to the standard AR sub-ledger, so customer balances, payments, and statements work as normal. Revenue recognition entries land in the GL with deferred-revenue control accounts and recognised-revenue accounts mapped by product.
## Reporting
ARR (annual recurring revenue), MRR (monthly recurring revenue), churn, contract value, and waterfall reports are produced via Power BI templates that ship with the module.
## Where it doesn't fit
Very high-volume B2C subscriptions (tens of millions of subscribers) typically sit better with a dedicated subscription platform (Stripe Billing, Zuora) that feeds F&O the financial summary. For B2B subscription businesses up to mid-market, Subscription Billing is increasingly the right answer in-product.
---
# Sustainability in Business Central
How Business Central's Sustainability module tracks emissions and environmental data — emission scopes, accounting.
Source: https://www.solvingdynamics365.com/guides/sustainability-in-business-central
Section: Business Central / Compliance & localisation
Published: 2026-05-01
Sustainability reporting has moved from nice-to-have to regulatory obligation in many jurisdictions — the EU's **Corporate Sustainability Reporting Directive (CSRD)** is the most prominent example, with similar regimes in the UK, US, and elsewhere. Microsoft added a **Sustainability** module to Business Central to put emissions tracking and environmental data inside the same system that already holds the financial transactions.
## The model
Sustainability in Business Central works in parallel to the financial ledger — but instead of debits and credits, the entries are **emissions** in CO₂-equivalent units. Each environmental transaction has:
- **Date** — when the emission occurred.
- **Source** — what produced it (item purchased, fuel consumed, electricity used, business travel, waste).
- **Emission scope** — Scope 1, Scope 2, or Scope 3 (the GHG Protocol categories).
- **Quantity** — the volume of activity (litres of fuel, kWh of electricity, kg of material).
- **Emission factor** — the conversion factor from activity to CO₂-equivalent (e.g. 2.3 kg CO₂e per litre of diesel).
- **CO₂-equivalent amount** — quantity × factor.
**Emission scopes.**
- **Scope 1** — direct emissions from operations the company owns (company fuel use, company-owned vehicles, on-site combustion).
- **Scope 2** — indirect emissions from purchased energy (grid electricity, district heat).
- **Scope 3** — all other indirect emissions in the value chain (purchased goods and services, business travel, employee commuting, downstream product use, end-of-life).
Scope 3 is typically the largest and hardest to track — it includes the emissions embedded in everything the business buys.
## Emission factors
A library of **emission factors** maps activity types to CO₂-equivalent rates. Factors are jurisdiction-specific (electricity grid carbon intensity differs by country) and update periodically. Microsoft ships baseline factors; customers extend with industry-specific ones or third-party factor providers.
## Integration with financial transactions
The powerful pattern: link emissions to financial activity. A vendor invoice for diesel posts both a financial transaction (cost) and an emissions transaction (Scope 1 from fuel). A purchase of materials posts both cost and Scope 3 embedded emissions if the vendor's product carbon footprint is known. This automation — emissions captured as a by-product of normal posting — is what makes ongoing reporting sustainable rather than a quarterly research project.
## Reporting
The module produces:
- **Emissions by scope, time, source, location** — the core summary views.
- **Trend reports** — year-over-year, period-over-period.
- **CSRD-aligned reports** — pre-built for the European Sustainability Reporting Standards (ESRS), with mapping to the standardised disclosure tables.
- **Power BI dashboards** — for management and operations visibility.
## Targets and reduction tracking
The module supports setting **emission targets** (e.g. Scope 1+2 reduction of 30% by 2030 baseline 2024) and tracking progress over time.
## Limits
Business Central's Sustainability module covers the structured emissions accounting cleanly. It does *not* replace specialist platforms for complex needs:
- Lifecycle assessment (LCA) of products.
- Supplier engagement and primary-data collection programmes.
- ESG strategy and disclosure software for very large multi-entity organisations.
For most SMB and mid-market customers running BC, the module covers the operational emissions tracking required for CSRD and similar disclosures. Larger organisations integrate BC with **Microsoft Sustainability Manager** (a separate product on the Microsoft Cloud for Sustainability) for the enterprise scope.
## Operational reality
Sustainability reporting is a discipline as much as a technology problem — get the right activities tagged with the right factors, post emissions as normal business happens, review and disclose. The module is the enabler; the data quality is the customer's responsibility.
---
# Teams collaboration with Dynamics 365
How Microsoft Teams integrates with Dynamics 365 — embedded record views, chat in context, meeting integration, Loop components.
Source: https://www.solvingdynamics365.com/guides/teams-collaboration-with-dynamics-365
Section: Foundations / Productivity & UX
Published: 2026-05-01
Microsoft Teams is increasingly the connective tissue across Microsoft 365 and Dynamics 365 — chat, meetings, file collaboration. The integration with Dynamics surfaces records, automations, and workflows where users already work. Done well, it eliminates context-switching between Teams and Dynamics apps; done poorly, it adds another integration to maintain without behavioural change.
**The integration touchpoints.**
- **Records in Teams** — pin a Dynamics record (account, opportunity, case) to a Teams channel for ongoing collaboration.
- **Chat about records** — start chats with context from Dynamics.
- **Meeting integration** — Dynamics records linked to meetings; meeting notes flow to Dynamics.
- **Adaptive cards** — Dynamics events posted as cards in Teams.
- **Approval flows** — Power Automate approvals delivered in Teams.
- **Power Apps in Teams** — embed canvas or model-driven apps as Teams tabs.
- **Copilot integration** — M365 Copilot accessing both Teams and Dynamics data.
Each is a useful integration; together they form a meaningful productivity pattern.
## Pinning records to channels
A common use case:
- Sales channel pins active opportunities.
- Service channel pins escalated cases.
- Project channel pins the project and milestones.
The pinned record displays Dynamics data in the Teams channel; team members discuss the record in channel chat; updates in Dynamics reflect in the pin.
## Chat from records
From a Dynamics record:
- Start a Teams chat about it.
- Pre-populated with link back to the record.
- Includes recipient lookup (typically the record's owner and stakeholders).
The pattern reduces friction — no need to manually paste record URLs into chats.
**Meeting and call integration.**
- **Calendar invites** can reference Dynamics records.
- **During meetings**, the linked record is accessible.
- **Meeting notes** synced to the record post-meeting.
- **Call recordings** (Teams Premium) processed by Sales Conversation Intelligence.
The link between meetings and CRM records keeps activity history clean without manual logging.
## Power Apps in Teams
Canvas apps and model-driven apps can be embedded as Teams tabs:
- **Channel-level apps** — for team-shared apps.
- **Personal apps** — for individual use.
The app runs inside Teams; users don't leave to use it. For specific workflows (timesheet, expense, time-off), this is a meaningful productivity uplift.
**Adaptive cards.**
- Dynamics events post cards to Teams channels — "new high-value opportunity in your region."
- Cards can include action buttons — approve, view, dismiss.
- Power Automate flows post adaptive cards on events.
Cards work in chat or channel posts; they're interactive and respect Teams's display.
## Approval flows
Power Automate approvals deliver to Teams:
- Approver sees the approval in their Teams feed.
- Tap-to-approve directly in Teams.
- Mobile-friendly.
For organisations standardising on Teams, this is the canonical approval surface; avoids approver context-switching.
## Loop components
Microsoft Loop is the collaborative-component framework:
- **Loop component** — a piece of interactive content (task list, voting, status).
- **Embeddable** in Teams chat, Word, Outlook.
- **Shared state** — updates sync across surfaces.
Some Dynamics integrations expose Loop components for shared collaboration on a record.
**Copilot integration.**
- **M365 Copilot** can query Dynamics data when properly authorised.
- **"Summarise this opportunity"** answers from Dynamics data.
- **"Draft an email to this customer about open cases"** combines Outlook and Dynamics context.
The Copilot story stitches data across products invisibly to the user.
**Implementation considerations.**
- **Permissions** — Teams users need appropriate Dynamics permissions.
- **Tenant configuration** — Teams + Dynamics in the same Microsoft tenant; cross-tenant is possible but more complex.
- **Licensing** — both Teams and Dynamics licences required; Copilot adds further.
- **Information architecture** — which channels, which apps, which records to pin.
**Adoption patterns that work.**
- **Start with a high-frequency workflow** — sales opportunity review, case escalation.
- **Train both Teams users and Dynamics users** — the integration touches both.
- **Build adaptive cards for high-signal events** — not every Dynamics change; only the ones worth interrupting.
- **Measure usage** — adoption metrics reveal which integrations stick.
**Pitfalls.**
- **Over-notification.** Every Dynamics change posts to Teams; channels become noise.
- **Wrong-channel pins.** Records pinned in channels not actually used; pins ignored.
- **Permissions misaligned.** Teams user sees Dynamics record but can't update; frustration.
- **Adaptive cards stale.** Card shows data captured at posting time; not updated.
- **Power Apps in Teams ignored.** Embedded but users still go to Power Apps web.
**Operational rhythm.**
- **Quarterly review** of integration usage and value.
- **Continuous tuning** — turn off integrations that aren't driving behaviour.
- **Update cards and Power Apps in line with Dynamics changes.**
## Strategic positioning
Teams + Dynamics 365 integration is the canonical Microsoft productivity vision: collaboration and CRM/ERP in one interface. The technical integration is mature; the operational reality depends on adoption discipline.
For organisations already deep on Teams, integrating Dynamics into Teams is natural. For organisations less Teams-centric, forcing the integration is less effective.
The investment is moderate (configuration, training, possibly custom Power Apps); the payback is measurable productivity through reduced context-switching. Most modern Microsoft-aligned organisations should pursue this integration; the question is which workflows and how deeply, not whether.
---
# Tenant administration for Dynamics 365
How to administer a Dynamics 365 tenant — Microsoft 365, Power Platform, Business Central, and Finance/SCM admin centres, roles, and tenant-level governance.
Source: https://www.solvingdynamics365.com/guides/tenant-administration-for-dynamics-365
Section: Implementation / Operations & support
Published: 2026-05-01
A Dynamics 365 tenant is administered across several overlapping admin consoles. Knowing which one does what — and what tenant-level governance settings live where — is essential to running the platform without surprises.
**The four main admin consoles.**
1. **Microsoft 365 admin centre** (admin.microsoft.com) — the master console for tenant-level identity, users, licences, domains, and Microsoft 365 services. The starting point for everything else; Entra ID is here, licence assignment is here, baseline tenant configuration is here.
2. **Power Platform admin centre** (admin.powerplatform.microsoft.com) — environments, Dataverse capacity, DLP policies, custom connectors, AI Builder credits. Where most Dynamics 365 CRM-side and Power Platform admin happens.
3. **Business Central admin centre** (businesscentral.dynamics.com/...) — BC-specific: environments (production and sandbox), notifications, update windows, application insights configuration, telemetry, support tickets.
4. **Lifecycle Services (LCS)** (lcs.dynamics.com) — Finance and SCM specific: environments, code deployments, platform updates, support tickets, asset library, BPM, telemetry. Microsoft is gradually migrating LCS functions to the Power Platform admin centre.
## Entra ID and identity
All Dynamics 365 sign-in flows through **Microsoft Entra ID** (formerly Azure AD). Tenant-level identity policies — MFA, conditional access, named locations, app consent policies — are configured at the Entra layer and apply to Dynamics 365 automatically. Custom policies are typically in scope for:
- MFA enforcement for all Dynamics 365 access.
- Conditional access blocking risky sign-ins.
- App consent restrictions preventing user-driven third-party app integrations.
## Roles for admins
Microsoft Entra has tenant-scoped roles:
- **Global Administrator** — full tenant control. Use sparingly; protect with extra MFA and review.
- **Power Platform Administrator** — full Power Platform admin centre access.
- **Dynamics 365 Administrator** — broader rights across Dynamics 365 admin functions, including F&O.
- **License Administrator** — assign/remove licences.
- **User Administrator** — manage users.
Within Dynamics 365 apps themselves, separate **app-level roles** (e.g. *Customer Service Manager*, *Sales Administrator* in Dataverse; *System Administrator* in F&O) govern in-app rights.
## Tenant-wide DLP
Data Loss Prevention policies in the Power Platform admin centre classify connectors as Business / Non-Business / Blocked, and prevent flows or apps from mixing classes. Set a tenant baseline and refine per environment.
## Licence management
Microsoft 365 admin centre assigns Dynamics 365 licences to users. Power Platform admin centre shows capacity (Dataverse storage, API call usage, AI Builder credits) consumed. Both are checked monthly for the health of the tenant.
## Environment topology
A healthy Dynamics 365 tenant has at minimum: production environment, UAT/Test sandbox, Dev sandbox. Larger orgs have per-team dev environments, per-product UATs, per-region production environments. Document the topology and review quarterly.
## Backup and restore
Production Dataverse environments have 28 days of point-in-time backup; BC and F&O similar. Test the restore process before you need it.
## Auditing
Tenant-wide audit events stream to **Microsoft Purview** for compliance retention. Per-app audit configures per table; verify both layers.
## Alerting
Tenant-level health (sign-in failures, service disruptions, capacity warnings) routes through Azure Monitor and the Microsoft 365 admin centre's service health page. Configure email or Teams notifications to a real distribution list, not an individual.
## Governance documentation
Maintain a single-page tenant governance document: environments, admin roles, DLP policies, licence holders, capacity thresholds, alert escalations. Living document, reviewed quarterly.
---
# Tenant-to-tenant migration scenarios
What's involved in migrating Dynamics 365 from one Microsoft 365 tenant to another — common scenarios, what moves, and what has to be rebuilt.
Source: https://www.solvingdynamics365.com/guides/tenant-to-tenant-migration-scenarios
Section: Implementation / Operations & support
Published: 2026-05-01
Sometimes Dynamics 365 needs to move from one Microsoft tenant to another — an acquisition consolidates two organisations onto a single tenant, a divestiture splits one company into separate tenants, a customer migrates from a partner-managed tenant to their own, a re-organisation moves business units across tenants. These migrations are non-trivial and infrequently smooth; planning makes the difference between completed-on-schedule and stuck-for-months.
## Why tenant migration is hard
A Microsoft tenant is a deep container — Entra ID, all M365 services, all licensing, all Dynamics 365 environments, all Power Platform environments, file storage, mail, SharePoint, every integration token, every service principal. Moving from one to another isn't a copy; it's a re-establishment across many surfaces simultaneously.
**Common scenarios.**
1. **Carve-out from a parent tenant.** A business unit being divested into its own company needs its Dynamics 365 environment moved to a fresh tenant. Most surgical migration scenario.
2. **Merger consolidation.** Two companies merging consolidate onto one tenant. Either one party's existing tenant absorbs the other, or both move to a fresh tenant. The bigger of the two usually absorbs.
3. **Partner-managed to customer-managed.** A customer running Dynamics 365 inside a partner's tenant moves to their own tenant once they outgrow the partner-hosted model.
4. **Geographic / regulatory move.** Moving from a global tenant to a country-specific sovereign tenant for data-residency requirements.
5. **Sovereign cloud move.** Moving from commercial cloud to GCC, GCC High, or DoD — substantial operational changes.
**What Microsoft supports natively.**
For **Dataverse-based** environments (CRM, Customer Service, Field Service, Power Platform), Microsoft has improving but not perfect tenant-migration tooling. The `pac` CLI and partner tools (KingswaySoft, Skyvia, Scribe) export and import data, with manual reconciliation for identity-bound items.
For **Business Central**, Microsoft offers a **tenant migration** through the BC admin centre — copy environments from one tenant to another, with limitations on identity-bound configuration.
For **Finance and Operations**, tenant moves go through Microsoft FastTrack-supported processes. Not self-service; substantial Microsoft engagement.
**What moves cleanly.**
- Application data (Dataverse rows, BC data, F&O data).
- Customisations as packaged solutions / apps / deployable packages.
- Configurations stored as data.
- File attachments (with rebinding to new SharePoint locations).
- Code (extensions stored in source control).
**What has to be rebuilt or rewired.**
- **Identity / user accounts.** Users are bound to the originating Entra tenant. Moving users requires creating new accounts in the destination tenant and reassigning record ownership.
- **Service principals and app registrations.** Each integration's authentication needs new registrations in the destination tenant.
- **Connections in Power Automate / Power Apps.** Every connection re-authenticates after migration.
- **SharePoint integration.** Document libraries rebind to destination SharePoint.
- **Licensing.** New licences provisioned in destination; original licences released.
- **Custom domain names.** DNS records, SSL certificates re-establish.
- **External partner access** — Entra B2B guest accounts re-established.
- **Webhook subscriptions, Service Bus endpoints, Event Grid subscriptions** — every external integration target reconfigured.
- **Telemetry endpoints** — Application Insights resources may move.
**The phased approach.**
1. **Discovery** — comprehensive inventory of every Dynamics 365 environment, integration, custom code, configuration, integration point, user.
2. **Architecture** — destination tenant topology, with identity and integration design.
3. **Pilot migration** — migrate a small slice (one environment, a few users) to validate the approach.
4. **Mock migration** — full dress rehearsal.
5. **Production migration** — typically over a weekend with read-only freeze on the source.
6. **Hypercare** — extended support for the first weeks as integrations re-establish.
## Timeline
Realistic timelines for tenant migrations span **3–12 months** depending on scope. Quick promises of "we'll move it next month" usually miss the depth of work.
## Operational reality
Engage Microsoft FastTrack early. The cost-benefit of doing this without expert guidance rarely pays.
---
# Test automation for Dynamics 365
How to automate testing for Dynamics 365 — AL test framework, EasyRepro for CRM, Playwright for web UIs, and the strategy that actually pays back.
Source: https://www.solvingdynamics365.com/guides/test-automation-for-dynamics-365
Section: Foundations
Published: 2026-05-01
Test automation in Dynamics 365 is genuinely hard. The platform spans AL, X++, JavaScript, Power Fx, Dataverse plug-ins, Power Automate flows, and web UIs — each with different tooling. Done thoughtfully, automation catches regressions that release waves silently introduce; done badly, it's a maintenance burden that gets abandoned. The strategy matters more than any specific tool.
## What to automate
Not everything. Prioritise:
- **Posting paths** — the transactional code that puts data into the GL or sub-ledgers. Most consequential if it regresses.
- **Custom AL or X++ code** — your own extensions. Microsoft tests their own; you test yours.
- **Critical integrations** — flows that move data across systems. Silent failures here are expensive.
- **High-volume / high-frequency processes** — anything users hit hundreds of times a day, where a UI change costs operations.
## What not to automate
UI tests that depend on Microsoft's standard pages. Microsoft changes them release-by-release and your tests become a maintenance treadmill chasing those changes. Test your extensions; trust Microsoft to test theirs.
## Layer 1: AL test framework (Business Central)
Built-in. Run by the `bccontainerhelper` PowerShell module in containers. Each AL test codeunit holds test methods with `[Test]` attributes. Tests run in rolled-back transactions so they're re-runnable. Microsoft ships **Test Libraries** with helper functions for creating customers, items, sales documents, etc. Use them.
## Layer 2: Dataverse plug-in unit tests
C# plug-ins have plain .NET unit tests using **FakeXrmEasy** or **XrmUnitTest** — frameworks that mock the Dataverse SDK so plug-ins can be tested without a real Dataverse environment. Fast, run in CI, catch logic bugs.
## Layer 3: Power Automate flow tests
Power Automate has built-in flow checker and a **Power Automate Test Framework** for unit-testing flow logic with mocked actions. Less mature than other layers, improving.
## Layer 4: Power Apps tests
Canvas apps support **Power Apps Test Studio** for recorded test flows. Model-driven apps test through web UI automation.
## Layer 5: UI automation
Two leading tools:
- **EasyRepro** — Microsoft's open-source library on top of Selenium, targeting Dynamics 365 model-driven apps. C# tests script user interactions: open opportunity, set field, click save, verify result. Robust against Microsoft's web UI changes (Microsoft maintains it alongside the product).
- **Playwright** — Microsoft's modern web testing framework, language-agnostic (TypeScript, Python, C#, Java). Increasingly preferred for new projects given its broader cross-application capability — test a Dynamics 365 form, a Power Pages portal, and a Power Apps canvas app in one suite.
For Business Central web client, **Playwright** or **Selenium** drive the UI; pattern is similar.
## Layer 6: Integration tests
End-to-end scenarios that span multiple systems. Often built in Power Automate flows that perform the test scenario, capture results, post to Dataverse for tracking. Or in dedicated test orchestrators like **Azure Test Plans** or **TestFlight**.
## CI/CD integration
Tests at every layer run in CI:
- Unit tests on PR build.
- Integration tests on merge to main.
- UI smoke tests in UAT after deploy.
- Full regression suite weekly or before production deploys.
## Test data
A persistent challenge — tests need data that survives release-wave updates and resets. Patterns:
- **Self-creating tests** — each test creates the data it needs (customers, products, orders) and rolls back.
- **Reference data sets** — a small set of stable test records preserved through resets.
- **Synthetic data** — generated programmatically for volume / performance tests.
## Maintenance
Automated tests rot. Schedule quarterly review — which tests still pass, which fail false-positively, which haven't run in months. Retire what's dead; refactor what's flaky.
## Operational reality
Start small. 20 well-maintained tests on critical paths beat 200 flaky tests nobody trusts. Build the culture of "every bug deserves a test" so the suite grows from real lived experience, not aspirational planning.
---
# Test data management for Dynamics 365
How to build and maintain test data for Dynamics 365 environments — anonymisation, synthetic data, data subsetting.
Source: https://www.solvingdynamics365.com/guides/test-data-management-for-dynamics-365
Section: Implementation / Project execution
Published: 2026-05-01
Realistic test data is one of the most underrated assets in any Dynamics 365 programme. Without it, testing happens against thin or stale data that doesn't reveal the issues real production data would. With it, defects are caught early and stakeholders trust UAT outcomes. **Test data management** is the discipline of designing, generating, anonymising, and maintaining data for non-production environments.
**The problem.**
- **Production-like data** is essential for realistic testing but contains sensitive content that can't be exposed in non-prod.
- **Synthetic data** is safer but rarely captures real-world data quirks that cause production issues.
- **Subsets of production** balance realism and volume but bring referential integrity challenges.
- **Stale data** in test environments means tests pass that production would fail.
The right answer is usually a mix: subsetted, anonymised production data refreshed periodically, supplemented with crafted synthetic data for specific scenarios.
**Anonymisation strategies.**
- **Substitute** — replace names with fictional alternatives.
- **Mask** — replace specific characters (e.g., emails become `j***@e***.com`).
- **Shuffle** — re-order column values across rows (preserves distribution, breaks identity).
- **Hash** — irreversibly transform identifiers.
- **Tokenise** — replace with consistent placeholder values.
Each has trade-offs:
- Substitution preserves natural reading but loses statistical properties.
- Shuffling preserves stats but breaks within-record consistency.
- Hashing is irreversible but identifiers don't look natural.
**What to anonymise.**
- **Names** — first, last, full names.
- **Emails** — fictional or hashed.
- **Phone numbers** — fictional or masked.
- **Addresses** — fictional, but geographically plausible.
- **Tax IDs / SSNs** — never preserved in non-prod.
- **Credit card data** — should never be in Dynamics; certainly not in non-prod.
- **Health data** — strict regulatory requirements.
- **Salary data** — masked or shuffled.
- **Free-text fields** — most problematic; may contain accidentally-pasted sensitive content.
## Free-text challenges
Notes, descriptions, email bodies, case narratives — these contain unpredictable content. Solutions:
- **Pattern detection** — find SSN-like patterns, credit-card-like patterns, replace.
- **Wholesale replacement** — replace free text with synthetic content.
- **Manual review** — for small datasets.
Each has cost; complete free-text anonymisation is hard.
## Referential integrity in subsets
Subset production: pick 1,000 customers from 100,000. Need their:
- Related contacts.
- Open opportunities.
- Cases.
- Orders.
- All recursive related data.
A naive subset breaks referential integrity. Tools that follow relationships (parent-to-child) preserve integrity. Building such tools for complex schemas (F&O especially) is significant work.
**Synthetic data generation.**
- **Templated** — predefined templates for common entities.
- **Generative** — rule-based generation (names from lists, addresses from city tables).
- **AI-generated** — LLMs generate plausible text content.
- **Combinatorial** — exhaustive coverage of choice combinations.
For specific test scenarios (boundary conditions, rare combinations), synthetic data is more valuable than production subsets — production rarely contains the edge case you want to test.
**Tools.**
- **Microsoft Test Data Generator** — limited capability.
- **Configuration Migration tool** — F&O-focused.
- **Third-party** — Tonic.ai, IBM Optim, Delphix.
- **Custom scripts** — Power Automate, Power Shell, custom .NET.
For large-scale TDM, dedicated commercial tools save time; for small projects, scripted custom approaches suffice.
**Refresh cadence.**
- **Per UAT cycle** — refresh UAT data before each round.
- **Per major test phase** — refresh SIT before integration testing.
- **Quarterly** — refresh dev / playground environments.
Refresh always includes re-anonymisation; bypassing this is a compliance risk.
**Test data for specific scenarios.**
- **Performance testing** — large volume data; realistic distribution.
- **UAT** — recent production-like data; familiar to stakeholders.
- **Functional testing** — small, carefully crafted data covering specific scenarios.
- **Demo** — clean, presentable data without anomalies.
Each scenario has different needs; one dataset rarely serves all.
## Data versioning
As schemas evolve:
- New columns need data.
- Deleted columns leave gaps.
- Renamed columns break references.
Test data needs versioning aligned with solution versioning — restore data from a backup matched to a solution version.
**Common pitfalls.**
- **No regular refresh.** Test data 6 months stale; UAT participants find issues that production has long since had.
- **Anonymisation skipped.** Production data refreshed to non-prod without anonymisation; compliance breach.
- **Free-text leaked.** Anonymisation script handles structured fields but misses free-text; sensitive data slips through.
- **Subset broken.** Subsetting tool misses relationships; tests fail with FK errors.
- **Synthetic data unrealistic.** Generic names, default addresses; tests don't catch edge cases that real data would.
- **Environment data drift.** Each test environment has different data; reproducing issues across environments impossible.
**Operational rhythm.**
- **Pre-UAT** — refresh, anonymise, validate.
- **Pre-release** — production-like data for pre-prod.
- **Continuous** — synthetic data templates for ongoing testing.
- **Periodic** — full test data audit; identify stale or compromised sets.
## Strategic positioning
Test data management is investment that pays back continuously. Teams that skimp on TDM ship more defects to production. Teams that invest in it have higher-confidence releases and more meaningful UAT. The investment scales with environment count and regulatory exposure; smaller projects can manage with lighter tooling, larger ones need dedicated TDM platforms. Either way, treat test data as a programme asset — designed, maintained, governed.
---
# The AL debugger in Business Central — a deep dive
How the AL debugger works for developing Business Central extensions — VS Code integration, snapshot debugging, attaching to sessions.
Source: https://www.solvingdynamics365.com/guides/business-central-debugger-deep-dive
Section: Business Central / AL & development
Published: 2026-05-01
Updated: 2026-08-25
Writing AL code without good debugging tooling would be miserable. The **AL debugger** in VS Code provides step-through debugging, breakpoints, watch variables, snapshot debugging for production, and attach-to-session for live troubleshooting. Mastering it is a productivity multiplier for any BC developer.
**The two debug modes.**
- **Live debugging** — attach to your dev session, step through code as it runs.
- **Snapshot debugging** — record a session and replay; non-intrusive for production.
Each has its place.
**Live debugging setup.**
1. AL Language extension installed in VS Code.
2. `launch.json` configured with target server (sandbox URL, auth).
3. Press F5 to launch / attach.
4. VS Code connects to BC session.
5. Set breakpoints; trigger the code path; step through.
The experience is full VS Code debugger — step into, step over, step out, watch expressions, call stack, locals.
**Breakpoints.**
- **Line breakpoint** — fires when the line is reached.
- **Conditional breakpoint** — only when an expression evaluates true.
- **Hit count breakpoint** — every Nth time.
- **Function breakpoint** — by function name.
Conditional breakpoints save massive time — instead of stepping through hundreds of records, break only when `Item No. = 'PROBLEM-ITEM'`.
## Watch expressions
Add expressions to the Watch panel:
- Current variable values.
- Computed expressions (`SalesAmount * 1.21`).
- Object properties.
Watch updates as you step; visualises state at each point.
## Snapshot debugging
A different model:
1. Configure snapshot debugging in VS Code launch.json.
2. Trigger snapshot recording in BC (admin action).
3. User performs the action being debugged.
4. Stop recording; VS Code downloads the snapshot.
5. Replay locally with full debugger experience.
Crucially, **snapshot debugging doesn't pause production** — the user's action runs at full speed. The recording is replayed offline. Production-safe debugging.
## Useful in production scenarios
Customer reports a bug in production. The partner can:
1. Configure snapshot debugging on the prod environment.
2. Have the user reproduce the issue.
3. Capture the snapshot.
4. Debug locally with full visibility into what happened.
Far better than "send me a screenshot."
**Attach to current session vs another.**
- **Current session** — your dev session; you're triggering and stepping.
- **Another session** — attach to a colleague's session or a background session (job queue).
Attaching to job queue for batch debugging is invaluable; otherwise debugging batch issues requires guesswork.
## Source code mapping
The debugger maps compiled IL back to source AL:
- Set breakpoint in your AL file.
- BC executes IL.
- Breakpoint fires on the IL line that maps to your AL.
Mapping works for your own extension and Microsoft's base app (you don't have base app source by default, but can step into compiled views).
## Performance counters
Beyond debugging, AL profiling:
- Performance Profile sessions in BC client.
- Identify hot paths.
- Compare options.
Profiling and debugging are complementary; profiling shows where time is spent, debugging shows why a specific path behaves as it does.
**Common debugging scenarios.**
- **Posting fails** — break on the error; inspect data state.
- **Wrong field value** — break before the line, inspect input; break after, inspect output.
- **Performance issue** — profile + targeted snapshot.
- **External integration fails** — break in the callback / event handler; inspect HTTP response.
## Test debugging
AL tests can be debugged like regular code:
- Run test in debug mode.
- Step through.
- Inspect assertions.
Test development without debugging is slow; with debugging, tests get fixed quickly.
**Common pitfalls.**
- **Wrong launch.json target.** Connected to wrong environment; breakpoints don't fire.
- **Source code mismatch.** Extension compiled vs source out of sync; breakpoints in unreachable lines.
- **Multi-session confusion.** Stepping in one session while another is running; concurrency surprises.
- **Snapshot too large.** Long-running sessions produce big snapshots; trim recording windows.
- **Forgetting to publish.** Edit AL, hit F5; debugging old compiled version.
**Best practices.**
- **Conditional breakpoints** for high-volume code paths.
- **Step over** for known-good code; **step into** for new logic.
- **Watch expressions** rather than repeatedly inspecting variables.
- **Snapshot for production** — safer than attach to live prod.
- **Logging supplement debugging** — for issues that don't reproduce, telemetry to App Insights is the alternative.
## Strategic positioning
The AL debugger has matured enormously. Modern BC development should not be done without it. For partners maintaining extensions across many customers, snapshot debugging in production is one of the most valuable features in the BC tooling — it transforms what was previously a guessing game into reproducible debugging. Investment in debugger fluency pays back daily.
---
# The AL test framework
Writing automated tests in AL — test codeunits, test runners, test isolation, and the libraries Microsoft ships with Business Central.
Source: https://www.solvingdynamics365.com/guides/al-test-framework
Section: Business Central / AL & development
Published: 2026-05-01
Updated: 2026-08-25
Business Central ships with a full test framework for AL that's the right tool for both unit tests and integration tests of your extensions. Adopting it is a one-time investment that pays back the first time you regression-test a major release wave update.
## Test codeunits
A test codeunit is a normal codeunit with the `Subtype = Test` property set. Each test method is decorated with `[Test]`, optionally `[HandlerFunctions(...)]` to register UI handlers, and `[TransactionModel(...)]` to control transactional isolation. The test runner discovers test codeunits in installed extensions and executes them in containers.
## Test isolation
By default, each test runs in a **rolled-back transaction**, so changes don't persist between tests. This is what makes the suite re-runnable against the same database. For tests that genuinely need to commit (e.g. testing a sequence of posted documents), `TransactionModel::AutoCommit` is available; use it sparingly.
## Test libraries
Microsoft publishes a set of **test libraries** as separate AL packages: `Test Library - Sales`, `Test Library - Inventory`, `Test Library - ERM`, etc. They give you helper functions like *CreateCustomer*, *CreateItem*, *PostSalesDocument* that produce valid test data without you wiring up every field. They live on AppSource and are installed into sandbox environments where tests run.
## Handler functions
AL tests run headless, so any dialogs or pages the code-under-test opens need a *handler*. A `[MessageHandler]`, `[ConfirmHandler]`, `[ModalPageHandler]`, or `[ReportHandler]` registered on the test codeunit catches the call and lets the test assert and respond.
## Assertions
The `Assert` codeunit provides `IsTrue`, `IsFalse`, `AreEqual`, `AreNotEqual`, `RecordCount`, and string/error variants. Idiomatic AL tests follow the *arrange, act, assert* pattern.
## Running tests
Inside Business Central, the **Test Tool** page lists test codeunits, lets you run them interactively, and shows pass/fail. From CI, the `Run-TestsInBcContainer` PowerShell cmdlet (part of the BC Container Helper) runs tests headless and emits results in JUnit XML for build pipelines.
## Code coverage
AL has built-in code coverage reporting; the test runner can produce a coverage map showing which lines of the system-under-test were exercised.
## Where to start
Don't try for 100% coverage. Start by testing the *posting paths* that matter — your sales discount calculation, your custom price formulas, your event subscribers — and grow from there.
---
# The Business Central API and OData services
How external systems talk to Business Central — the v2.0 REST API, OData web services, bound actions, and call limits.
Source: https://www.solvingdynamics365.com/guides/business-central-api-and-odata
Section: Business Central / AL & development
Published: 2026-05-01
Updated: 2026-08-31
Business Central has a first-class HTTP API that's the canonical way to integrate it with anything outside the product. The API is what powers Power Automate connectors, mobile apps, Power Pages portals, and partner integrations.
**The v2.0 REST API.** Microsoft maintains an OpenAPI-described REST API at `/api/v2.0/companies({id})/...` that covers the most-used entities: customers, vendors, items, sales orders, sales invoices, purchase orders, journals, GL accounts, and many more. Each entity supports the standard verbs (GET, POST, PATCH, DELETE) and OData query semantics (`$filter`, `$select`, `$expand`, `$top`, `$skip`). Pagination follows the OData convention with `@odata.nextLink`.
## Custom API pages
When the v2.0 API doesn't expose what you need, partners or in-house developers write **AL API pages**. An API page targets a single table, lives at a customer-defined publisher / group / version path (e.g. `/api/contoso/myapp/v1.0/...`), and lets you control exposed fields, behaviour, and security.
## Bound actions
Beyond reading and writing entities, API pages can expose **bound actions** — e.g. *post* a sales order, *cancel* an invoice, *apply* a payment. Actions invoke AL code and return a result, which is how you trigger BC's transactional behaviour rather than just writing fields.
## OData v4 web services
A second, older surface exposes any **page** or **query** as an OData endpoint when published from the Web Services list. OData is read-and-write, less RESTful than v2.0, and useful for ad-hoc Excel pulls or Power BI imports.
## Authentication
SaaS APIs authenticate with **Microsoft Entra ID** OAuth 2.0 — usually via service-to-service flows with an app registration granted Dynamics 365 Business Central application permissions. Basic Auth is deprecated.
## Call limits
Each tenant has API throughput limits: requests per minute per user, and an overall throughput allowance. Going over returns HTTP 429 with a `Retry-After` header. Well-behaved integrations honour the header, batch where possible, and prefer `$expand` over multiple round trips.
## Webhooks
Business Central can push **change notifications** to a registered subscriber endpoint when records change, avoiding polling. Subscriptions auto-expire and must be renewed — build the renewal into your integration rather than discovering the expiry in production. The mechanics are covered in [webhooks in Business Central](https://www.solvingdynamics365.com/guides/webhooks-in-business-central).
## URL anatomy — environments and companies
Two things trip up every first integration. First, the URL carries the **environment name**: `https://api.businesscentral.dynamics.com/v2.0/{tenant}/{environment}/api/v2.0/...` — an integration built against `sandbox` doesn't reach `production` by accident, which is a feature, but it means environment names belong in configuration, never in code. Second, almost everything in BC lives **per company**. The API root lets you list companies, and every entity call is scoped to one company ID. A multi-company tenant needs the integration to loop companies or be told which one it serves; assuming "the" company is the classic day-one bug in a [multi-company setup](https://www.solvingdynamics365.com/guides/business-central-multi-company-setup).
## Performance patterns that actually matter
The throughput limits aren't generous, so integration design matters more than in most SaaS APIs:
- **Filter server-side, always.** `$filter` and `$select` cut both payload and server work. Pulling a full table to filter client-side is the top cause of 429s.
- **Use `$expand` instead of N+1 calls.** One request for sales orders with `$expand=salesOrderLines` beats a call per order by an order of magnitude.
- **Read deltas, not snapshots.** Filter on `lastModifiedDateTime` (present on v2.0 entities) to sync only what changed since the last run, or use webhooks to be told.
- **Batch writes.** The `$batch` endpoint packs multiple operations into one request and can run them in a single transaction — essential for journal lines that must post together.
- **Respect `Retry-After`.** On 429, wait the stated time and retry. Hammering through the backoff extends the penalty window.
For genuinely heavy reads (BI-scale extraction, warehouse loads), the API is the wrong tool regardless of tuning — that's what BC's Fabric/lakehouse paths and scheduled exports are for; keep the API for operational integration.
## Choosing a surface — the decision in practice
The strategic order: **v2.0 standard API first** — versioned, documented, stable across [release waves](https://www.solvingdynamics365.com/guides/business-central-release-waves), and what Microsoft performance-tests. **Custom API pages second**, when you need custom fields or tables — they inherit the same versioned, RESTful behaviour and remain under your control. **Published OData page endpoints last**: they expose whatever the page shows, which means a page redesign or personalisation quirk can silently change your integration contract, and page-based endpoints drag UI logic through the server with every call. They earn their keep for ad-hoc Excel and Power BI pulls where a **query object** endpoint delivers joined, aggregated data efficiently — not as the backbone of a system integration. And SOAP, still technically present on-premise, belongs in migration plans only.
## Best practice
Use v2.0 first, custom API pages second, OData last, basic auth never. Put a queue or integration layer between BC and any chatty upstream system, log correlation IDs from response headers when raising support cases, and test against a sandbox that actually resembles production data volumes — the API that flies with 50 demo items behaves differently against 200,000 SKUs.
---
# The Business Central finance module
An overview of Business Central's financial management — general ledger, dimensions, AP/AR, banking, fixed assets, and intercompany.
Source: https://www.solvingdynamics365.com/guides/business-central-finance-module
Section: Business Central / Finance & accounting
Published: 2026-05-01
Updated: 2026-08-30
Financial management is the heart of Business Central. Every other module — sales, purchasing, inventory, jobs, manufacturing — eventually posts to the same general ledger, using the same dimensions and the same posting groups, which is what makes Business Central feel like *one* system rather than a collection of bolt-ons. It also means finance configuration decisions made in week one echo through every subledger for the life of the system, so this is the module to design carefully rather than quickly.
## General ledger
The GL is structured around a customer-defined **chart of accounts** and an unlimited number of **dimensions** — flexible analytical tags such as Department, Cost Centre, Project, Region, or Salesperson that are attached to every posting. Dimensions replace the proliferation of GL sub-accounts you see in other ERPs and make slice-and-dice reporting in Power BI or the built-in account schedules straightforward.
The design advice that survives every project: keep the chart of accounts short and push the analysis into dimensions. A 300-account chart with six well-chosen dimensions out-reports a 3,000-account chart every time, and it is far easier to maintain. Two dimensions can be marked as **global** (stored directly on every ledger entry and filterable everywhere) — choose those two deliberately, because changing them later is disruptive. The full reasoning is in the [dimensions design guide](https://www.solvingdynamics365.com/guides/business-central-dimensions-design).
**Posting groups** are the other structural decision: customer, vendor, inventory, and general posting groups map subledger activity to GL accounts automatically. Users never pick a GL account on a sales invoice — the posting group setup does. This is why data entry stays clean, and why a wrong posting group mapping quietly mis-posts hundreds of documents until someone reconciles.
## Accounts payable and receivable
Vendor and customer ledger entries are posted automatically from purchase and sales documents, and can also be entered through general journals. Standard features include payment terms, payment discounts, due-date reminders, customer statements, finance charge memos, and a built-in **payment journal** that produces bank files (SEPA in Europe, ACH/positive-pay variants in North America). Application — matching payments to invoices — can be automatic on import or handled manually, and unapplication is possible when someone matches wrongly.
## Banking
Bank account cards, bank reconciliation (with AI-assisted matching via Copilot), and bank file import/export are first-class objects. Many regions have bank feeds available through partner extensions, which turn reconciliation from a monthly chore into a near-daily non-event. Reconcile frequently: a bank reconciliation done weekly takes minutes; one done quarterly takes days.
## Fixed assets
Asset register, depreciation books, partial disposals, insurance, and maintenance — covered out of the box, with multiple depreciation methods in parallel for tax vs accounting. Depreciation runs as a batch job and posts through a dedicated FA journal, so the GL trail is as auditable as everything else. The [fixed assets deep dive](https://www.solvingdynamics365.com/guides/business-central-fixed-assets-in-depth) covers the setup order that saves rework.
## Cash flow and budgeting
Cash flow forecasts pull from sales orders, purchase orders, jobs, fixed asset disposals, and manual entries. Budgets are dimension-aware and can be imported from Excel — which in practice is how nearly everyone builds them: model in Excel, import, report actual-vs-budget through account schedules or Power BI.
## Reporting: account schedules
**Financial reports** (long known as account schedules) are the built-in report writer: row definitions over accounts and dimension filters, column definitions over periods, budgets, and comparisons. They cover the standard P&L, balance sheet, and cash-flow statements without any external tool, and they export to Excel. Learn them before reaching for an ISV reporting product — for most SMBs they are enough. See [account schedules and financial reports](https://www.solvingdynamics365.com/guides/business-central-account-schedules-and-financial-reports).
## Intercompany and consolidations
Business Central supports posting between legal entities — intercompany general journals and purchase/sales documents that mirror into the partner company — and consolidating multiple companies into a reporting company with currency translation and eliminations. It is genuinely usable for a handful of related companies; groups with dozens of entities and complex ownership usually add a consolidation tool on top. [Multi-company setup](https://www.solvingdynamics365.com/guides/business-central-multi-company-setup) walks the options.
## Statutory reporting
VAT statements, EC sales lists, e-invoicing formats, and country-specific localizations are delivered either by Microsoft (for the major countries) or by ISV localization partners on AppSource. This is the single biggest reason to verify country coverage before signing a contract: the finance module is global, but tax compliance is local, and the quality of the localization decides how much manual work month-end involves.
## The month-end rhythm
A well-configured finance module makes month-end close boring: run Adjust Cost, reconcile bank and interim accounts, post recurring journals, run the VAT statement, review account schedules against budget. If close takes more than a few days, the cause is almost always upstream — posting groups, missing item charges, or unapplied payments — not the GL itself. The [month-end close guide](https://www.solvingdynamics365.com/guides/business-central-month-end-close) has the checklist.
---
# The Business Central planning worksheet
How MRP works in Business Central — the planning worksheet, reordering policies, supply, demand, and the regenerative engine behind it.
Source: https://www.solvingdynamics365.com/guides/business-central-planning-worksheet
Section: Business Central / Inventory & warehouse
Published: 2026-05-01
Updated: 2026-08-31
The **planning worksheet** is Business Central's [MRP](https://www.solvingdynamics365.com/glossary/mrp) engine. It calculates net requirements for every planning-relevant item across your locations and proposes the orders needed to keep supply aligned with demand. Properly configured, it's the difference between firefighting shortages and running a calm supply chain.
## Inputs
The engine considers all *supply* and *demand* signals. Supply: on-hand inventory, open purchase orders, open production orders, open transfer orders, planned orders inside the planning horizon. Demand: open sales orders, service orders, components in production orders, transfer requirements, forecast lines, blanket sales orders, and projected demand from job tasks.
## Reordering policies
Each item card sets a **reordering policy** that drives planning behaviour:
- **Lot-for-Lot** — plan exactly the quantity required by demand on each date.
- **Fixed Reorder Qty** — order in fixed lots (e.g. carton of 24).
- **Maximum Qty** — top up to a maximum when below reorder point.
- **Order** — plan only on direct customer demand (true MTO).
Lead times, safety stock, safety lead times, minimum order quantities, lot multiples, and order modifiers fine-tune the suggestions.
Choosing the policy is the design decision that matters most, and the defaults people reach for are often wrong. Lot-for-Lot suits items with lumpy, order-driven demand; Fixed Reorder Qty and Maximum Qty are *reorder-point* policies that ignore future demand timing and only look at whether stock has dipped below a threshold — fine for cheap C-class items, dangerous for anything with long lead times or real seasonality. A common failure mode is setting reorder-point policies on everything because they feel intuitive, then wondering why the worksheet suggests purchases for items with no upcoming demand. If demand differs per warehouse, plan per location with **stockkeeping units**, which let the same item carry different policies, lead times, and replenishment sources (purchase here, transfer there) at each location.
## Planning worksheet vs requisition worksheet
BC ships two worksheets. The **requisition worksheet** handles purchase and transfer replenishment only — no production orders — and suits distribution businesses that buy and move stock. The **planning worksheet** is the full MRP engine covering production, purchase, transfer, and assembly. Manufacturers live in the planning worksheet; pure wholesalers can stay in the simpler requisition worksheet and avoid maintaining manufacturing-grade item setup. Running both against overlapping item sets is a recipe for duplicate suggestions — pick one home per item.
## Running the worksheet
A planner opens the planning worksheet, sets a date range and a filter, and runs *Calculate Regenerative Plan* or *Calculate Net Change Plan*. Regenerative recomputes from scratch; net change updates only items affected by changes since the last run. The output is a list of suggestions — new purchase orders, production orders, transfer orders, plus reschedule and cancellation actions on existing orders.
## Acceptance
Planners review suggestions and accept them with the *Carry Out Action Message* function, which creates or modifies the suggested supply orders. Accepted suggestions disappear from the worksheet.
## Action messages
*New, Change Qty, Reschedule, Reschedule & Change Qty, Cancel* — each indicates what the engine wants you to do, with reasons (early supply, late supply, demand changed, etc.).
## Subcontracting and assembly
Subcontracted production operations auto-suggest purchase orders to the subcontract vendor; assembly items can use a simpler assembly planning routine.
## Rolling it out without chaos
The worst way to adopt the planning worksheet is to configure every item and run a regenerative plan across the whole catalogue on day one — the result is thousands of suggestions nobody trusts, and the tool is abandoned within a month. The rollout that works:
- **Start with one item class** — a supplier's range, or the A-items at one location — and run the worksheet daily for a few weeks until the suggestions match what a good planner would have done by hand.
- **Fix master data before blaming the engine.** Wrong lead times, missing vendor catalogues, and stale safety stock produce wrong suggestions with perfect logic. The worksheet is a master-data quality audit whether you want one or not.
- **Use the dampener settings** (dampener period and quantity on the item card) to suppress trivial reschedule messages — a suggestion to move an order by one day creates noise, not value.
- **Never carry out actions unreviewed.** The worksheet proposes; the planner disposes. Automating *Carry Out Action Message* end-to-end is tempting and almost always premature.
A worksheet nobody trusts gets bypassed with manual purchase orders — which then appear as unexpected supply in the next run, making the suggestions stranger and trust lower. The loop only stabilises when planners work *through* the worksheet, exceptions included.
## Where it stops
The engine is single-level per run in its reasoning about capacity and is not finitely capacity-constrained — it will happily load 300 hours of production onto a work centre with 80 available. Capacity checking happens downstream, on the production orders it creates. For demand sensing, finite scheduling, complex scenario planning, or full S&OP, customers add an ISV planning module or step up to [Dynamics 365 Supply Chain Management](https://www.solvingdynamics365.com/guides/what-is-dynamics-365-supply-chain), whose Planning Optimization service is built for exactly that scale. For the production side of what the worksheet feeds, see [Business Central manufacturing](https://www.solvingdynamics365.com/guides/business-central-manufacturing).
---
# The Business Central reservation engine
How reservations work in Business Central — automatic vs manual, item tracking, order-to-order binding, and the trade-offs.
Source: https://www.solvingdynamics365.com/guides/business-central-reservation-engine
Section: Business Central / Inventory & warehouse
Published: 2026-05-01
Updated: 2026-08-25
The **reservation engine** in Business Central links a piece of supply (inventory on hand, an inbound purchase order, a production order, a transfer order) to a specific demand (a sales order line, a production component, a service order). Reservations are how the system promises one customer that *this* particular stock will be reserved for *their* order rather than the next person who logs in.
## Why reserve at all
Without reservations, a sales order line just expresses demand against a pool — and that pool is up for grabs by anyone else who picks faster. Reserving converts the promise into a binding allocation that survives until the order is shipped or the reservation is cancelled.
## Automatic, optional, never
Each item has a **Reserve** field with three settings: *Never* (no reservations allowed), *Optional* (users reserve manually when needed, the default), and *Always* (every demand line is reserved as it's created, blocking creation if no supply exists). Most companies use *Optional* and reserve selectively.
## Manual reservations
From a sales order line, users open the *Reservation Entries* page and pick which supply to bind to: on-hand quantity, an inbound purchase, a production order, an assembly order, a transfer order. The reservation entry stores the link. Posting the source consumes the reservation.
## Order-to-order binding
A stronger form of reservation, used for make-to-order and configure-to-order, where the supply is *created specifically for* the demand. The link is bidirectional — if the sales order quantity changes, the production order changes; if the production order is cancelled, the demand becomes unreserved. Order-to-order is the operating model for many engineer-to-order shops.
## Item tracking and reservations
When items have lot or serial numbers, reservations can be at the tracking level (this serial number, this lot) or at the quantity level. Specific tracking reservations are common in pharma, food, and high-value goods.
## Reservations and planning
Reserved supply is visible to MRP and is excluded from the available-to-promise pool. The planning worksheet honours reservations and won't suggest cancelling a reserved supply order.
## Trade-offs
Heavy reservation discipline gives reliable delivery promises but increases administrative load. Many companies start with *Optional* and reserve only for committed orders above a value or with delivery commitments.
---
# The Cash Management module in Dynamics 365 Finance
How F&O's Cash Management handles cash positions, bank reconciliation, payment processing, and cash flow forecasting at enterprise scale.
Source: https://www.solvingdynamics365.com/guides/cash-management-module-in-f-and-o
Section: Finance & SCM / Finance
Published: 2026-06-14
For enterprise finance teams, **cash management** is daily operational work — knowing the current bank balance across many accounts, forecasting near-term liquidity, reconciling bank statements, processing payments, managing FX exposure. Dynamics 365 Finance's **Cash and Bank Management** module covers the operational layer.
## Bank accounts
Each bank account is a master record with:
- **Identifier** — account number, routing details, IBAN, SWIFT/BIC.
- **Currency** — the account's base currency.
- **Bank** — the financial institution.
- **Type** — operating, savings, escrow, payroll, intercompany.
- **Posting profile** — GL accounts for bank activity.
- **Bank statement format** — for import (camt.053, MT940, BAI2, country-specific).
- **Payment file formats** — for outbound payment generation.
- **Approval thresholds** — for payment authorisation.
Multi-currency operations have multiple bank accounts per currency; multi-entity groups have many bank accounts per entity.
## Bank statement import
Daily or weekly:
- **Live bank feeds** — partner connectors (Yodlee, Token, country-specific bank-feed services) automate import.
- **MT940 / camt.053** — uploaded files for banks supporting standard SWIFT or ISO 20022 formats.
- **CSV / custom formats** — bank-specific exports with mapping configuration.
The imported statement lines feed into reconciliation.
## Bank reconciliation
Reconciling F&O's bank account ledger against the bank statement:
1. Import the statement.
2. Auto-match statement lines to bank ledger entries by amount, date, reference.
3. Manual match unmatched lines.
4. Post journal entries for items only the bank knows about — fees, interest, direct debits, returned items.
5. Reconcile balance differences.
6. Post the reconciliation; bank ledger entries marked closed.
AI-assisted matching (Copilot) suggests matches for ambiguous lines; the user accepts, modifies, or rejects.
## Payment processing
Outbound payments to vendors / employees / others through:
- **Payment proposals** — system identifies vendor invoices due for payment, proposes a payment batch.
- **User review** — adjust amounts, exclude entries, override priorities.
- **Bank file generation** — SEPA pain.001, Bacs, ACH NACHA, Bankgirot (SE), country-specific formats.
- **Posting** — payment journal posts; vendor ledger settled; bank ledger reduced.
- **Bank approval workflows** — many banks require dual-approval for high-value payments; F&O integrates with bank workflow.
## Inbound payments
Customer payments arrive through:
- **Bank feed** — incoming credits identified and applied.
- **Manual entry** — for receipts not yet on the bank statement.
- **Direct debit reversal** — failed direct debits returned to open AR.
- **Lockbox** — for organisations with bank-provided customer-payment lockbox services, automated import.
## Cash flow forecast
F&O's cash flow forecast considers all liquidity signals:
- **Opening bank balances** — across all accounts in all currencies.
- **Receivables** — open AR with due dates.
- **Payables** — open AP with due dates.
- **Sales orders** — open with planned shipment / invoice dates.
- **Purchase orders** — open with planned receipt / invoice dates.
- **Service contracts** — recurring revenue commitments.
- **Capital projects** — planned cash outflows.
- **Loan repayments and interest** — recurring debt servicing.
- **Tax accruals** — periodic tax payments.
The forecast aggregates per period (daily near-term, weekly medium-term, monthly long-term), per currency, per entity. Power BI templates visualise.
## FX exposure
For multi-currency operations:
- **Position per currency** — net exposure across all accounts.
- **Open forex contracts** — hedges in place.
- **Period-end revaluation** — translate foreign-currency balances at period-end rates, post FX gain / loss.
- **Realised FX** — when foreign-currency invoices settle at different rates from booking.
For sophisticated treasury operations (hedging strategy, FX optionality, intra-day position management), customers integrate a dedicated treasury platform alongside F&O.
## Intercompany cash management
Multi-entity groups have inter-company cash flows — entity A funds entity B's working capital, intra-group loans, central treasury sweep. F&O supports:
- **Centralised payments** — entity A pays vendor invoices for entity B; IC accounting reconciles.
- **IC cash transfers** — programmatic moves between entities.
- **Pooling structures** — for groups with notional or physical cash pooling.
**Reporting.**
- **Cash position dashboard** — current balance per account, total, by currency.
- **Daily / weekly cash forecast.**
- **Bank reconciliation status** — which accounts reconciled, which behind.
- **FX exposure summary.**
- **Treasury KPIs** — DSO, DPO, working capital metrics.
**Common pitfalls.**
- **Bank feeds not configured** — daily reconciliation work is manual.
- **Payment file format mismatched to bank** — payments rejected; vendor relationships strained.
- **Stale reconciliations** — accumulating unreconciled items become harder to investigate.
## Operational reality
Cash management discipline drives working capital efficiency. Modern enterprise F&O implementations integrate live bank feeds, run daily reconciliation, and feed forecasts that the CFO actually trusts.
---
# The Cost Accounting module in Dynamics 365 Finance
How Cost Accounting differs from financial accounting in F&O — cost objects, allocation hierarchies, statistical dimensions, and management reporting.
Source: https://www.solvingdynamics365.com/guides/the-cost-accounting-module-in-f-and-o
Section: Finance & SCM / Finance
Published: 2026-05-01
**Cost Accounting** in Dynamics 365 Finance is a separate, parallel ledger purpose-built for management accounting — operating cost allocation, profitability analysis by product / customer / region, and the analytical reporting that financial accounting on its own can't deliver cleanly. It's one of the most underused modules in F&O and one of the most powerful when adopted.
## Why a separate ledger
Financial accounting answers external questions — statutory P&L and balance sheet for tax authorities, auditors, regulators. Cost accounting answers internal questions — which products are profitable, which customers cost too much to serve, which cost centres run efficiently. These two views need different rules:
- **Cost reallocation across periods** — match operational costs to the periods they actually drove value, not just when the invoice posted.
- **Different cost hierarchies** — financial sees by GL account; management sees by product category or customer segment.
- **Cost allocation across cost objects** — IT cost shared across departments; marketing cost allocated to product lines.
- **Imputed costs** — opportunity cost, depreciation by management methodology, deemed cost of capital.
Forcing all of this into the financial ledger pollutes statutory accounts. The cost accounting module gives a separate, audit-trailed analytical view.
**The cost-accounting data model.**
- **Cost element dimension** — the cost categories you analyse (Salary, Travel, Equipment, Utilities, etc.). Map to GL accounts but groupings can differ from the chart of accounts.
- **Cost object dimension** — what bears the cost (Cost Centre, Profit Centre, Project, Product, Customer Segment). Can include hierarchical structures.
- **Statistical dimensions** — non-monetary measures used to drive allocations (Headcount, Square Metres, Production Units, Machine Hours).
## Source of cost data
Cost accounting *consumes* data from financial accounting — GL postings are copied into the cost-accounting ledger periodically. Within cost accounting, the data is transformed and reallocated without changing the source.
## Allocation hierarchies
The core of cost accounting:
1. **Primary allocation** — IT cost (in a service cost centre) split across operational cost centres based on a driver like headcount or laptop count.
2. **Secondary allocation** — allocated cost in operational centres further reallocated to product lines, customer segments, or projects.
3. **Tertiary allocation** — cumulative allocation to derive product profitability or customer profitability.
Allocations cascade through configurable hierarchies, with full audit of each allocation step.
## Statistical dimensions as drivers
Statistical dimensions don't represent money — they represent volume metrics that drive allocation. Headcount drives HR cost; Machine Hours drive production overhead; Square Metres drive facility cost. Values are entered periodically or loaded automatically from operational systems.
## Cost rates
Cost rates apply to statistical dimensions to compute imputed cost — e.g. an internal hourly rate for a resource type used for project cost capture.
## Reporting
Pre-built cost reports cover:
- **Cost statement** — like a management P&L by cost element and cost object.
- **Cost analysis** — drill down by hierarchy to find anomalies.
- **Cost-centre performance** — actual vs budget, by period.
- **Product profitability** — revenue – cost across the cost-accounting view.
- **Customer profitability** — same logic at customer or segment level.
Power BI templates ship with the module for richer visualisation.
## When to adopt
Cost Accounting pays back when:
- Cost allocations across cost centres / products / customers are material to decisions.
- Management reporting needs cost views that the chart of accounts can't naturally produce.
- The organisation has dedicated controllers willing to maintain the configuration.
## When not
For small, simple operations where the GL with dimensions answers most management questions, Cost Accounting adds complexity without proportional benefit. Adopt when the gap becomes painful.
## Operational reality
Cost Accounting is a configuration-heavy module. Budget a focused implementation (a few weeks for a controller and consultant) and maintain it as ongoing controller work. Done well, it transforms management visibility.
---
# The cost adjustment job in Business Central
Why Business Central separates inventory cost adjustment from posting — how the Adjust Cost - Item Entries batch works, when it runs.
Source: https://www.solvingdynamics365.com/guides/cost-adjustment-job-in-business-central
Section: Business Central / Finance & accounting
Published: 2026-05-01
When you sell an item before its true cost is known — a sale shipped today against a vendor invoice that arrives next week, or a transfer received before the costing run that establishes its standard — Business Central posts the sale at an **expected** or **best available** cost, then comes back later to **adjust** the cost via the **Adjust Cost - Item Entries** batch job. Understanding this two-step pattern is essential to reading BC's inventory accounting.
**Why costs aren't always final at the moment of sale.**
- A purchase **receipt** can post before the purchase **invoice** is received. Item ledger entries get an `Expected Cost` until the invoice posts.
- A **revaluation** runs after an item has already been sold; the cost difference needs to flow forward.
- An **inventory adjustment** (e.g. write-off) changes the cost basis of remaining stock.
- A **standard cost change** revalues open inventory and may require COGS adjustment on already-shipped items.
In all these cases, the original transactions are correct from a quantity perspective; only the unit cost needs revision.
## The value entry chain
Each item ledger entry has one or more **value entries** attached:
- The first value entry captures the cost at the time of the original posting.
- Subsequent value entries capture cost adjustments — `Direct Cost`, `Indirect Cost`, `Variance`, `Revaluation`, `Rounding`.
- The sum of value entries equals the current cost recorded against the item ledger entry.
This separation lets BC track *how* a cost became its current value, not just the final number — auditing the cost history is essential during cost disputes.
## Adjust Cost - Item Entries
The batch job:
1. Scans for item ledger entries whose costs are still flagged as **not adjusted** or have downstream entries needing adjustment.
2. Recomputes the cost for each affected entry using the item's **costing method** (FIFO, LIFO, Average, Specific, Standard).
3. Posts value entries to capture the adjustment.
4. If `Automatic Cost Posting` is enabled on Inventory Setup, the value entries also post to the general ledger; otherwise the **Post Inventory Cost to G/L** batch posts them later.
**Costing methods determine the math.**
- **FIFO** — outbound entries match against earliest inbound; adjustments propagate when those inbounds are revalued.
- **LIFO** — same, but latest inbound first. Rare; some US tax positions.
- **Average** — running weighted average. Adjustments to one inbound recompute the average and ripple forward.
- **Specific** — by lot or serial; adjustments stay tied to the specific unit.
- **Standard** — items always post at standard; variances post separately. Adjustments materialise as additional variance entries.
## Running cadence
Most BC tenants schedule Adjust Cost on the **Job Queue** to run nightly or hourly. Some run it after every purchase invoice posting. Don't leave it manual — un-adjusted entries pile up and the next run takes much longer.
## Automatic cost adjustment
On **Inventory Setup**, the `Automatic Cost Adjustment` field can be set to:
- `Never` — manual only (not recommended in production).
- `Day`, `Week`, `Month`, `Quarter`, `Year` — entries posted within that window trigger an immediate adjustment on next save.
- `Always` — adjusts on every transaction.
`Always` is theoretically pure but kills performance in high-volume environments. Most use `Day` plus a scheduled nightly run.
## Post Inventory Cost to G/L
Separately from Adjust Cost, the value entries created need to flow to the **General Ledger**. The `Post Inventory Cost to G/L` batch reads value entries and creates G/L entries for COGS, inventory account, variance, etc. Either run it via job queue or set `Automatic Cost Posting = Yes` on Inventory Setup to post G/L entries inline.
## Reconciliation
Two views need to agree:
- **Inventory Valuation Report** — values inventory based on item ledger entries.
- **G/L Inventory Account** — balance from posted G/L entries.
If they disagree, the cause is almost always:
- Cost adjustments pending (haven't run Adjust Cost recently).
- Value entries not yet posted to G/L.
- Direct G/L journals against the inventory account bypassing item ledger.
The `Inventory Valuation - Reconcile` report in BC compares the two and shows the gap.
**Common pitfalls.**
- **Skipping the job.** Costs stay at expected; financial reporting is wrong.
- **G/L posting disabled.** Value entries accumulate; G/L inventory account drifts.
- **Manual G/L journals against the inventory account.** Reconciliation impossible — fix by only ever using item-side documents.
- **Closing period before adjustment.** Adjustments posted in a closed period either fail or post into the next period, breaking the historical valuation.
## Operational discipline
A clean cost-adjusted environment is the foundation of accurate gross-margin reporting. Treat Adjust Cost and G/L posting as core financial close steps, not a "run if you remember" task.
---
# The Customer Service Workspace in Dynamics 365
How the Customer Service Workspace differs from the classic Hub — multi-session, productivity pane, agent scripts, and the architectural shift it represents.
Source: https://www.solvingdynamics365.com/guides/customer-service-agent-workspace
Section: Customer Engagement / Customer Service
Published: 2026-05-01
The **Customer Service Workspace** is Dynamics 365's modern agent desktop — a multi-session, productivity-paneled, omnichannel-ready environment that replaces the older single-session **Customer Service Hub** for serious contact-centre work. Understanding what it adds and where it differs from the Hub matters for any new Customer Service deployment.
## The Hub baseline
Customer Service Hub is the model-driven app most agents historically used. Single browser tab = single case. Navigation is between cases by opening a new tab. Adequate for low-volume, knowledge-driven service work.
**What Workspace adds.**
- **Multi-session tabs** within a single browser window — agents handle several conversations or cases simultaneously.
- **Productivity pane** — collapsible side panel with smart assist, knowledge, similar cases, suggested actions.
- **Agent scripts** — guided steps tied to case type or conversation context.
- **Omnichannel integration** — voice, chat, SMS, social, email surfaces unified.
- **Macros** — pre-canned actions agents trigger (send template, close case, escalate).
- **Customisations specific to Workspace** — layouts and components designed for the multi-session model.
## Sessions
A session is a working context — a case, a conversation, a customer record. Multiple sessions are stacked as tabs at the top of the workspace. Switching between sessions preserves state per session: forms half-edited, conversations mid-thread.
For agents handling chat or voice (where multiple conversations may be active simultaneously), multi-session is essential. For email/case agents working one at a time, single-session may suffice.
## Productivity pane
A vertical side panel that contextually surfaces:
- **Smart assist** — AI suggestions based on conversation content.
- **Knowledge search** — search KB and articles inline.
- **Similar cases** — related cases for context.
- **Agent script** — step-by-step guidance.
- **Customer summary** — quick view of who the customer is and their history.
The pane is configurable per session type; what an inbound voice call shows differs from a returning case.
## Agent scripts
Procedural guidance:
- **Linear scripts** — checklist of steps.
- **Decision-tree scripts** — branching based on customer responses.
- **Automated step actions** — some steps trigger flows or macros.
Scripts standardise call handling; quality and speed both improve once agents follow them. Building scripts is meaningful work — they must reflect real-world variability, not idealised playbooks.
## Macros
Pre-defined sequences of actions:
- **Send a template email.**
- **Create a follow-up task.**
- **Update case status and route.**
- **Open a specific URL with customer ID.**
Macros eliminate repetitive clicks. Defined in the productivity pane configuration; agents trigger by button.
## Omnichannel surfaces
When **Omnichannel for Customer Service** is installed alongside Workspace:
- **Inbound chat, SMS, voice** route to agent's queue.
- **Conversation surface** in the workspace handles the medium.
- **Customer profile**, history, sentiment displayed in the productivity pane.
The unified surface means agents don't context-switch between systems for different channels.
**Workspace vs Hub — when to use each.**
- **Hub** — small teams, case-only workload, simple service.
- **Workspace** — multi-channel teams, chat/voice agents, productivity-pane-heavy workflows.
Migration from Hub to Workspace is straightforward for the data side (same Dataverse), heavier for the UX side (forms, dashboards, customisations may need rework).
## Customisations
Workspace is a model-driven app like Hub. Customisations:
- **Site maps** — what entities and views are accessible.
- **Forms** — record forms; can be Workspace-specific.
- **Dashboards** — at the workspace level.
- **Productivity pane components** — custom side-panel widgets.
Some legacy Hub customisations don't transfer cleanly; budget rework time.
## Performance
Multi-session is heavier than single-session:
- Each session loads forms and data.
- High session counts can degrade performance.
- Modern browsers handle 5–10 sessions comfortably; beyond that, agents stack their own tabs.
**Common pitfalls.**
- **Workspace deployed without scripts or macros.** Agents get the multi-tab feature but no productivity uplift; experience worse than Hub.
- **Productivity pane configured incorrectly.** Wrong components for the channel; cluttered.
- **Switching costs underestimated.** Migrating from Hub means retraining, rewriting customisations, retesting; budget weeks not days.
- **Session limit hit.** Heavy use opens many sessions; performance drops. Set agent training: close sessions promptly.
- **Custom code on forms broken.** JavaScript form scripts running differently across Workspace sessions; test carefully.
## Strategic positioning
Workspace is Microsoft's strategic direction for Customer Service agent UX. New investments should land on Workspace; existing Hub deployments should plan migration on a reasonable timeline. Maintaining both adds complexity; commit to one as your primary surface and design customisations for that target.
## Operational rule
Choose Workspace by default for new Customer Service deployments. Ensure agent scripts, macros, and productivity pane components are designed before go-live — the multi-tab capability alone isn't worth the migration effort, but the productivity layer on top of it transforms agent efficiency.
---
# The Data Management Framework (DMF) in Dynamics 365 F&O — a deep dive
How F&O's Data Management Framework moves data in and out — data projects, data entities, source/staging/target, recurring integrations.
Source: https://www.solvingdynamics365.com/guides/data-management-framework-deep-dive
Section: Finance & SCM / Overview & platform
Published: 2026-05-01
The **[Data Management Framework (DMF)](https://www.solvingdynamics365.com/glossary/dmf)** is the structural foundation of every bulk data move in Dynamics 365 Finance and Operations — initial migration, ongoing integrations, exports for reporting, and recurring file-based exchanges. Understanding its core entities (data entities, data projects, staging) is essential for anyone touching F&O integration work.
## Data entities
A **data entity** is a denormalised view over one or more F&O tables, exposing a canonical structure suitable for external interchange. F&O ships with ~1,800 standard data entities — `CustomerV3`, `VendorsV2`, `ReleasedProductCreationV2`, `SalesOrderHeaderV4` — covering most master data and most documents.
Each entity has:
- A **public name** (used in URLs and APIs).
- A **target structure** (how it maps to underlying tables).
- A **staging table** (intermediate landing area for imports/exports).
- A **set of mapping rules** (per source format).
## Data projects
A **data project** is a configured import or export job. It contains:
- **Source format** — Excel, CSV, XML, ODBC, AX 2012, JSON.
- **Entities** — which data entities are in scope.
- **Mapping** — how source columns map to entity fields.
- **Filters** — what subset of records.
- **Sequence** — order of entity processing (matters for FK dependencies).
Projects are reusable: build once, run repeatedly. Each execution becomes a **job**.
## Source → Staging → Target
The import flow is three-stage:
1. **Source** — the input file or feed.
2. **Staging** — the data entity's staging table; intermediate landing with field-level validation.
3. **Target** — the actual F&O tables; the entity's `insert/update` business logic runs.
Errors at each stage are isolated: source parse errors don't corrupt staging; staging validation errors don't corrupt target. Failed records can be reprocessed without re-running the full job.
## Export is the reverse
Target tables → staging → source format file or feed.
## Data templates
Pre-configured data project sets shipped by Microsoft for common scenarios:
- **All customer data** — customers, addresses, contacts, etc.
- **All financial data** — chart of accounts, dimensions, opening balances.
- **All inventory data** — items, BOMs, routes, prices.
Templates are a good starting point; production projects usually need customisation.
## Recurring integrations
Beyond manual project execution, F&O supports recurring integrations:
- **Recurring data jobs** — pre-configured DMF projects scheduled or triggered.
- **OData-based** — REST endpoints for entity-based data access.
- **Batch APIs** — bulk data movement via REST.
For high-volume recurring integrations, batch APIs are preferred over OData per-record approach — OData throttles aggressively under load.
## Entities vs OData
The same data entities serve:
- **Batch DMF jobs** — bulk imports/exports via files.
- **OData APIs** — record-by-record CRUD operations.
- **Custom services** — programmatic invocation.
- **Power Platform connectors** — Power Automate / Power Apps use OData behind the scenes.
A consistent entity layer means the same logical record type is accessible through multiple channels — Power Apps reads the customer entity; an integration writes via batch DMF; both see the same data structure.
## Composite entities
Some data entities aggregate multiple related entities into a single payload (e.g. a sales order with header, lines, charges in one record). Useful when downstream systems prefer one structure per business document.
**Entity import performance.**
- **Standard entities** — moderate performance; suitable for ~1,000–10,000 records per minute.
- **Set-based processing** — high performance; entities marked as set-based skip per-record business logic.
- **Bulk import** — entire data sets in dedicated jobs; performance varies by entity complexity.
For large migrations (millions of records), entities are tuned individually — some standard entities don't scale and need partner extensions or direct SQL preparation.
**Common pitfalls.**
- **Mapping errors.** Source column names don't match staging fields; silent data drops or import errors. Test mappings with small samples.
- **Dependency ordering.** Loading sales orders before customers exist; FK violations. Always sequence entities respecting dependencies.
- **Staging accumulation.** Old staging records not cleaned; performance degrades. Schedule staging cleanup.
- **No error handling.** Failed records silently dropped; downstream confusion. Always extract error logs and reconcile.
- **Tier 1 testing not representative.** A migration that works in a Tier 1 dev environment may fail in Tier 2 SAT or production due to data volumes and parallel batch contention. Test with production-scale data on Tier 2.
**Source format gotchas.**
- **CSV** — character encoding (UTF-8 vs ANSI), delimiter handling, embedded commas.
- **Excel** — date formats, leading zeros stripped, formula evaluation.
- **XML** — schema mismatches.
Standardise on UTF-8 CSV or composite entity XML for predictability.
## Operational rule
Production data integration on F&O is built on DMF entities. Custom direct-SQL approaches are not supported and break with platform updates. Stay on the standard pattern — use entities, build data projects, schedule recurring jobs, handle errors explicitly.
## Where to go next
The entities DMF moves are described in [data entities and DMF](https://www.solvingdynamics365.com/guides/dynamics-365-data-entities-and-dmf); the near-real-time alternative for Dataverse is [dual-write](https://www.solvingdynamics365.com/guides/dynamics-365-dual-write-integration); the orchestration layer many projects put around it is [Azure Data Factory](https://www.solvingdynamics365.com/guides/azure-data-factory-with-dynamics-365). For the project view, [data migration strategy](https://www.solvingdynamics365.com/guides/data-migration-strategy-for-dynamics-365), and for exposing logic rather than data, [custom services and OData in F&O](https://www.solvingdynamics365.com/guides/custom-services-and-odata-in-f-and-o).
---
# The Dataverse plug-in execution pipeline
How Dataverse executes plug-ins — stages, pre/post images, transactional scope, and how multiple plug-ins interact on a single operation.
Source: https://www.solvingdynamics365.com/guides/dataverse-plugin-execution-pipeline
Section: Customer Engagement / Dataverse platform
Published: 2026-05-01
When an external call modifies a Dataverse record, multiple plug-ins, workflows, business rules, and platform logic may fire. Understanding the **execution pipeline** — the order and scope in which these run — is essential for any developer writing plug-ins or debugging behaviour that seems unpredictable.
**The five stages.**
- **Stage 10 — Pre-validation** — outside the database transaction. Used for early gates, custom auth, plugin-level redirects.
- **Stage 20 — Pre-operation** — inside transaction, before platform DB write. Modify the incoming target before commit.
- **Stage 30 — Platform operation** — the database write itself.
- **Stage 40 — Post-operation (in transaction)** — inside transaction, after DB write but before commit. Effects can be rolled back on exception.
- **Stage 50 — Post-operation (out of transaction)** — after commit. Async by default; out of the user's transaction scope.
Each plug-in registers at a specific stage; only Stage 20 and 40 plug-ins can directly affect the operation's outcome.
**Stage 10 specifics.**
- Outside transaction.
- Can cancel the operation by throwing.
- Limited by what's not yet committed (record doesn't exist yet for Create).
- Useful for early validations that don't need transactional rollback.
**Stage 20 — pre-operation, in-transaction.**
- Inside transaction.
- Can modify the `Target` entity — changes flow to the DB write.
- Can throw exception, rolling back.
- Most validation logic goes here.
Example use: enforce business rule that account category must match account type.
**Stage 30 — platform operation.**
- The DB write itself.
- Plug-ins do not register here.
- Triggers cascade behaviour (related records updates, indexes).
**Stage 40 — post-operation, in-transaction.**
- After DB write; before commit.
- The record exists; can read it back.
- Can modify related records as part of the same transaction.
- Exception still rolls back.
Example use: create a child record automatically when parent is created.
**Stage 50 — post-operation, out-of-transaction.**
- After commit.
- Async by default.
- Failures don't affect the original operation.
- Used for external integrations (call third-party API), audit logging, notifications.
For most "after creation, do this" scenarios, this is the right stage.
**Sync vs async at Stage 50.**
- **Sync** — runs in the same operation context but outside transaction; user waits.
- **Async** — runs in background job queue; user doesn't wait.
For external API calls, async preferred — user shouldn't wait on third-party responsiveness.
**Pre and post images.**
- **PreImage** — snapshot of the record before the operation. Available in Stages 20, 40, 50.
- **PostImage** — snapshot after. Available in Stage 40 and 50.
- Required for Update operations to compare before/after.
- Configured at registration time.
The image structure: choose which columns to capture. Capturing all is heavy; capture only what you need.
**Plug-in registration parameters.**
- **Message** — Create, Update, Delete, etc.
- **Primary entity** — which table.
- **Filtering attributes** — only fire when these columns change (Update only).
- **Stage.**
- **Execution mode** — Sync / Async.
- **Deployment** — Server / Offline / Both.
- **Unsecure / secure configuration.**
**Multiple plug-ins same stage.**
- All run sequentially.
- Order configured via "Execution Order" on the registration.
- Lower number runs first.
For deterministic behaviour, set execution order explicitly when multiple plug-ins on same event.
**Recursion control.**
- Each operation has a **depth** value.
- A plug-in modifying its own table triggers another invocation; depth increments.
- Default max depth = 8.
- Plug-in should guard: `if (context.Depth > 1) return;`
Without guard, infinite recursion possible (or hits depth limit).
**Transaction scope.**
- Stages 20 and 40 in transaction; all changes atomic.
- Throwing exception rolls back everything.
- Stage 50 out of transaction; original committed before this runs.
For multi-record consistency, use Stage 40; for fire-and-forget, Stage 50 async.
**Performance considerations.**
- **Sync plug-ins** block the user's operation; keep fast (< 2 seconds).
- **Heavy logic** belongs in async Stage 50.
- **Image data load** — capturing many columns slows registration; tune.
**Plug-in pipeline + workflows + business rules.**
- **Business rules** — run client-side (and server-side for some).
- **Real-time workflows** — run server-side, similar to plug-ins.
- **Plug-ins** — code.
- **Async workflows / flows** — out-of-band.
All can fire on the same event; ordering matters.
**Common pitfalls.**
- **Wrong stage.** Validation at Stage 50 — too late.
- **No image** — Update plug-in can't see old values.
- **Recursive plug-in** — depth guard missing.
- **Slow sync plug-in** — user-facing slowness.
- **Stage 10 cancel on Create** — record doesn't exist; cascade behaviour unclear.
- **Plug-in chains** — cascading effects unpredictable; debugging hard.
**Best practices.**
- **Comment the stage choice** — future maintainers understand the rationale.
- **Test all stages** — what happens if your plug-in throws at each stage?
- **Logging in plug-ins** — for production diagnosability.
- **Avoid cross-table updates** in Stage 20/40 unless needed.
- **Keep plug-in scope narrow** — one logical responsibility per plug-in.
## Strategic positioning
The pipeline is the foundation of all server-side Dataverse logic. Misunderstanding it leads to subtle bugs — race conditions, partial writes, missing data. Mastering it produces robust, maintainable extensibility. Invest in the model; the productivity gain is across every plug-in you'll write thereafter.
---
# The Dataverse security model
Roles, business units, teams, row sharing, and field-level security in Dataverse — the layers that protect data in Dynamics 365 CRM and Power Apps.
Source: https://www.solvingdynamics365.com/guides/dataverse-security-model
Section: Customer Engagement / Dataverse platform
Published: 2026-05-01
Dataverse security looks intimidating from the outside but reduces to a handful of layered concepts. Once they click into place, designing security for a Dynamics 365 implementation becomes a methodical exercise rather than guesswork.
## Business units (BUs)
The root of the security model. Every Dataverse environment has a tree of **business units** with a single root and any number of children. Every user and every record belongs to a BU. BUs typically map to organisational structure — divisions, regions, subsidiaries — and form the scope boundary for security roles.
## Security roles
A **security role** grants privileges (create, read, write, delete, append, append-to, assign, share) on each Dataverse table. Each privilege has a **scope**: *user-owned*, *business unit*, *parent: child business unit*, or *organisation* — meaning the user can act on their own records, on records owned by their BU, on records owned by their BU or its children, or on all records. The intersection of role + scope is what determines a user's effective access. Multiple roles combine additively.
## Teams
A **team** is a collection of users. Teams can own records, and security roles can be assigned to teams to grant access to all team members. **Owner teams** behave like users; **access teams** are lightweight groups for ad-hoc record sharing. **Microsoft 365 groups** can be linked as teams.
## Row sharing
Records can be **shared** with a user or team for specific privileges, granting access outside the regular scope rules. Sharing is the safety valve when default scopes don't fit — but heavy reliance on sharing complicates audit and admin.
## Field-level security
Beyond row-level, **field-level security profiles** restrict access to specific columns (e.g. salary on the User table). Profiles list users or teams that can read, update, or both, on each protected field. Use sparingly — every protected field adds maintenance.
## Hierarchies
**Manager** and **position** hierarchies offer an additional scope dimension where users with manager rights can see records owned by their direct or indirect reports.
## Auditing
Audit is enabled per table and column. Every change to an audited column is recorded with user, timestamp, old value, new value. Long-term retention pushes audit data to **Microsoft Purview** for compliance.
**Practical advice.**
- Start from Microsoft's built-in roles (e.g. *Salesperson*, *Customer Service Rep*); copy and edit.
- Use BUs sparingly — too many makes admin painful.
- Default to BU-level scope; jump to organisation only with a real reason.
- Audit access reviews quarterly.
## Where to go next
Each layer has its own guide: [business units and teams](https://www.solvingdynamics365.com/guides/dataverse-business-units-and-teams-deep-dive), [owner teams vs access teams](https://www.solvingdynamics365.com/guides/owner-teams-vs-access-teams-in-dataverse), [field-level security](https://www.solvingdynamics365.com/guides/field-level-security-in-dataverse), and [hierarchical security](https://www.solvingdynamics365.com/guides/hierarchical-security-in-dataverse). The privilege errors a wrong role produces — 0x80040220 and friends — are decoded in [Dataverse Web API errors](https://www.solvingdynamics365.com/guides/dataverse-web-api-errors-explained).
### Frequently asked questions
**What are the layers of Dataverse security?**
Business units as the scope boundary, security roles granting per-table privileges at user, business unit, parent-child, or organisation scope, teams that own records or carry roles, record sharing as the safety valve, field-level security profiles for sensitive columns, and manager or position hierarchies.
**How do multiple security roles combine?**
Additively. A user's effective access is the union of every role assigned directly and through teams, plus shares and hierarchy rights.
**How many business units should I create?**
As few as possible. Business units are the root of the model and too many make administration painful. Default to business-unit scope on roles and escalate to organisation scope only with a real reason.
**Where should I start when designing roles?**
Copy Microsoft's built-in roles such as Salesperson or Customer Service Rep and edit the copies, use field-level security sparingly, enable audit on sensitive tables, and review access quarterly.
---
# The Dataverse TDS endpoint
How to query Dataverse with SQL through the TDS endpoint — Azure SQL-compatible read access for reporting tools, with limitations and security implications.
Source: https://www.solvingdynamics365.com/guides/the-dataverse-tds-endpoint
Section: Customer Engagement / Dataverse platform
Published: 2026-07-14
For many years, the only way to query Dataverse was through the Web API (OData) or the older SOAP service. Both are excellent for app integration but awkward for tools that speak SQL — Power BI's older DirectQuery patterns, SQL Server Management Studio for ad-hoc exploration, third-party reporting tools, SQL-aware ETL platforms. **The TDS endpoint** (Tabular Data Stream) gives Dataverse a SQL Server-compatible read-only endpoint.
## What TDS is
TDS (Tabular Data Stream) is the protocol Microsoft SQL Server uses for client-server communication. Tools that speak TDS — SQL Server Management Studio (SSMS), Power BI Desktop, Excel's "Get Data from SQL Server", Azure Data Studio, any ODBC / JDBC driver using a SQL Server provider — can connect to the TDS endpoint as if it were a SQL database.
## The endpoint
Each Dataverse environment exposes a TDS endpoint at a specific URL:
```
.crm.dynamics.com,5558
```
(port 5558 is the standard TDS port for Dataverse).
Connections authenticate with **Microsoft Entra ID** — typically via Entra ID password authentication or Entra ID interactive authentication. Service principals work for unattended scenarios.
**What you can do.**
- **Run SELECT queries** with full T-SQL syntax against any Dataverse table.
- **Joins across tables** using SQL JOIN syntax.
- **Aggregations** (GROUP BY, HAVING, SUM, COUNT, AVG).
- **Window functions** (ROW_NUMBER, RANK, etc.).
- **Subqueries and CTEs**.
- **All the SQL syntax** Azure SQL Database supports for read operations.
**What you cannot do.**
- **No writes** — TDS endpoint is read-only. INSERT / UPDATE / DELETE not supported.
- **No DDL** — can't create tables, indexes, or schema changes.
- **No stored procedures.**
- **No transactional control** — no BEGIN TRAN / COMMIT.
- **Limited some SQL Server features** — synonyms, change tracking statements, specific extensions don't apply.
## Security
The TDS endpoint respects:
- **User's security role** — same as Web API access.
- **Business unit scopes** — same row-level filtering.
- **Field-level security** — secured columns are stripped from query results.
- **Hierarchical security** — same as Web API.
A user querying through the TDS endpoint sees only what they'd see through the standard Power Apps UI. The endpoint is a *different protocol*, not a different security context.
## Power BI use cases
TDS is particularly valuable for Power BI:
- **DirectQuery** datasets can connect via the SQL Server connector to the TDS endpoint, querying Dataverse live.
- **Import mode** can refresh by SQL queries against the endpoint.
- Complex Power BI models can join across multiple Dataverse tables natively in SQL.
Compared to the OData connector, the SQL approach is sometimes faster for complex aggregations and joins.
## Tooling for ad-hoc analysis
SQL Server Management Studio (SSMS) and Azure Data Studio connect to the TDS endpoint:
1. Connect to `.crm.dynamics.com,5558`.
2. Authenticate with Entra ID.
3. Browse the schema like any database.
4. Run SELECT queries interactively.
Useful for data exploration, ad-hoc analysis, troubleshooting, building queries for use in reports.
## ETL integration
SQL Server Integration Services (SSIS) and similar SQL-aware ETL tools can extract from the TDS endpoint as a source. Combined with the read-only constraint, this is a one-way pattern — Dataverse out to other systems, not back.
**Performance.**
- Queries against the TDS endpoint go through Dataverse's security and audit pipeline; substantial complex queries take longer than equivalent queries against a raw SQL database.
- For very large analytical queries, **Synapse Link for Dataverse** (streaming data to OneLake) is the better path. The TDS endpoint is for moderate-volume direct-query needs.
- The TDS endpoint isn't a substitute for analytical data warehousing at scale.
**Limits and caveats.**
- **Some columns** are exposed differently — choice columns show as integer values; you might need to join to the metadata to get labels.
- **Image and file columns** behave specifically — typically not queryable directly.
- **Calculated columns** are computed in the query rather than pre-stored.
- **Performance for very large tables** can be slow because of security checks.
- **Schema names** may differ from intuitive expectations — verify with SSMS browsing first.
**Common use cases.**
- **Power BI DirectQuery datasets** for live Dynamics 365 reporting.
- **SSMS for ad-hoc exploration** by developers and analysts.
- **SQL-aware reporting tools** like Tableau, Qlik, Looker connecting via SQL drivers.
- **ETL extraction** for one-time data exports.
**Common pitfalls.**
- **Heavy production reporting via TDS** — for high-volume, complex analytics, use Synapse Link instead.
- **Service-principal authentication confusion** — Entra ID requirements can be fiddly; use Azure CLI or PowerShell to set up properly.
- **Assuming SQL Server feature parity** — TDS endpoint is read-only and doesn't support all SQL Server features.
## Operational reality
TDS is a useful integration surface for SQL-aware tools and ad-hoc analysis. Don't make it the only analytical pattern; for serious analytics, layer Synapse Link / Microsoft Fabric on top.
---
# The Dynamics 365 Finance and SCM security model
How role-based security works in Dynamics 365 Finance and SCM — duties, privileges, roles, segregation of duties, and extensible data security.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-finance-security-model
Section: Finance & SCM / Finance
Published: 2026-05-01
Dynamics 365 Finance and Supply Chain use a layered, role-based security model derived from AX 2012. It's powerful, expressive, and considerably more complex than Business Central or the CRM apps. Understanding the hierarchy is essential.
**The four layers.**
1. **Privileges** — the lowest level. A privilege grants access (read, create, update, delete, perform action) on one or more *securable objects* — menu items, fields, tables, services, reports. Privileges are the building blocks; Microsoft ships hundreds.
2. **Duties** — a logical group of privileges that together let a user perform a job task: *Maintain customer invoices*, *Approve vendor payments*, *Inquire into ledger balances*. Duties are how you express "this job does these things".
3. **Roles** — a job role assembled from duties: *Accounts Payable Manager* contains *Maintain vendor master*, *Approve vendor invoices*, *Inquire into AP*, etc. Users are assigned to roles.
4. **Process cycles** — the highest level, grouping duties by business process for documentation purposes. Process cycles don't affect runtime security.
## Why the layers
This structure lets Microsoft ship roles and customers compose them without rewriting privileges. A customer rarely creates privileges; they assemble duties, occasionally extend roles, and assign users.
## Segregation of duties (SoD)
F&O has a built-in **SoD framework**. Administrators declare which pairs of duties are conflicting (e.g. *Maintain vendor master* + *Approve vendor payments*) and the system blocks any role assignment that would violate them, surfacing the conflict for resolution.
## Extensible Data Security (XDS)
Beyond menu/object security, **XDS** restricts data at the row level — e.g. "salespeople see only customers in their region". XDS policies are defined as queries on the underlying tables and apply automatically wherever those tables are queried, including in custom reports.
## Organisation hierarchy
Most security ties back to the **organisation hierarchy** — legal entities, operating units, departments, cost centres. Roles can be scoped to one or many entities; a user assigned to a role across multiple entities sees consolidated lists where appropriate.
## Effective access tool
F&O provides an effective-access tool that, given a user, shows every securable object they can reach and the role chain that granted it. Use it to debug "why can I see/not see this?".
## Practical advice
Start from Microsoft's shipped roles, copy them, edit the copies. Define SoD policies early. Don't grant the *System Administrator* role to anyone in production except true admins — it bypasses all security.
---
# The Dynamics 365 Finance tax engine
How tax calculation works in Dynamics 365 Finance — tax codes, tax groups, item tax groups, the Globalization tax service, and country-specific localizations.
Source: https://www.solvingdynamics365.com/guides/the-f-and-o-tax-engine
Section: Finance & SCM / Finance
Published: 2026-05-01
Tax calculation in Dynamics 365 Finance is one of the more configuration-dense areas of the product. Multi-country operations, complex rate structures, statutory reporting variations, and the recent move toward Microsoft's **Globalization Studio** tax service all demand careful design.
## The classic engine
F&O's classic tax engine — descended from AX — works by intersecting two classifications on each transaction line:
- **Tax group** — assigned to customer or vendor; defines the tax codes that apply for that trading partner's relationship (domestic VAT, export, EU intra-community, reverse charge, etc.).
- **Item tax group** — assigned to item or service; defines the tax codes that apply for what's being sold or bought (standard rated, reduced rated, exempt, etc.).
The intersection gives the **tax code** to apply, which carries the rate, the ledger accounts for tax payable and recoverable, and the reporting classification.
## Tax codes and tax periods
Tax codes have rates, posting accounts, and validity periods. Multiple rates per code over time (e.g. VAT rate changes) are managed by date-ranged versions. **Tax periods** define VAT/sales-tax return periods with start, end, and status (open / closed / submitted).
## Tax calculation steps
When a transaction line is created, the engine:
1. Looks up the trading partner's tax group.
2. Looks up the item's tax group.
3. Finds the intersection in the *tax code on the tax group lines*.
4. Calculates the tax amount (line × rate, with proration for partial line discounts).
5. Posts to the configured tax payable/recoverable accounts.
## Multi-step tax
Some jurisdictions require multi-step calculation — e.g. US state tax on top of local tax, or layered VAT-plus-environmental-fee. The classic engine supports this through chained tax codes.
## The Tax Calculation service (Globalization)
Microsoft's modern, configurable tax calculation service is built around the **Globalization Studio**. The Tax Calculation service is hosted in Azure, configured per country with electronic-reporting (GER) templates, and called by F&O at transaction time. The service supports:
- Complex multi-step calculations beyond the classic engine.
- Country-specific rules without hard-coding into F&O.
- A configurable rule engine in the Globalization Studio.
The new service is the strategic direction; for most established F&O customers, the classic engine remains in use, with migration planned over time.
## Country localizations
Country-specific tax reporting (VAT returns, intrastat, SAF-T, real-time invoice reporting in Spain/Italy/Hungary, e-invoicing in Mexico/Brazil, OSS for EU B2C) is delivered either by Microsoft (for the major countries) or by partner ISVs. The Electronic Reporting (GER) engine renders the actual report files; the underlying tax data comes from the calculations described above.
## External tax engines
For US sales tax with thousands of jurisdictions, customers integrate **Avalara** or **Vertex** — third-party tax engines that hold up-to-date jurisdiction rules. F&O calls the external service at posting; the result is stored as tax transactions in F&O.
**Common pitfalls.**
- **Wrong intersection setup.** New customer or item without correct tax-group assignment posts incorrect tax silently.
- **Rate change without versioning.** Updating the same tax code in place affects historical transactions on reprint; always version with effective dates.
- **Localization without specialist help.** Each country has nuances; rely on an experienced country implementer.
---
# The Dynamics 365 product family
A guided tour of every app in Dynamics 365 — ERP, CRM, marketing, retail, HR — what each one actually does.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-product-family
Section: Foundations / Platform overview
Published: 2026-05-01
Updated: 2026-08-30
Dynamics 365 is not one product. It is a portfolio of business applications sold under one brand, grouped loosely into two halves: **ERP** for running the back office (money, inventory, operations) and **CRM** for running customer-facing work (sales, service, marketing). Microsoft calls the CRM half "Customer Engagement" and the ERP half "Finance and Operations apps", and neither label appears consistently even in Microsoft's own material — which is why a map helps.
If you're deciding what to buy, [the product chooser](https://www.solvingdynamics365.com/guides/how-to-choose-the-right-dynamics-365-product) is the decision-focused companion to this guide. This one is the tour.
## The ERP side: money and operations
**[Dynamics 365 Finance](https://www.solvingdynamics365.com/guides/what-is-dynamics-365-finance)** is the enterprise financial system, descended from Dynamics AX. General ledger, accounts payable and receivable, fixed assets, budgeting, revenue recognition, and consolidations across many legal entities, currencies, and tax regimes. If you have subsidiaries in twelve countries, this is the tier built for you.
**[Dynamics 365 Supply Chain Management](https://www.solvingdynamics365.com/guides/what-is-dynamics-365-supply-chain)** is Finance's operational twin — same codebase, same database, usually implemented together (the pair is what people mean by "F&O"). It covers procurement, inventory, warehouse and transportation management, master planning, and discrete, process, and lean manufacturing.
**[Business Central](https://www.solvingdynamics365.com/guides/what-is-business-central)** is the SMB ERP, descended from Dynamics NAV. It delivers financials, sales, purchasing, inventory, projects, and light manufacturing in one tightly integrated app with a far simpler operating model than F&O. It is not a cut-down F&O — it is a different product with a different lineage, and for most companies under a few hundred users it is the right ERP. The [BC vs F&O comparison](https://www.solvingdynamics365.com/guides/business-central-vs-finance-and-operations) draws the line in detail.
**[Project Operations](https://www.solvingdynamics365.com/guides/what-is-dynamics-365-project-operations)** runs professional services firms — project sales, resourcing, time and expense, project accounting, and billing. It deliberately straddles the ERP/CRM line: the sales and resourcing side runs on Dataverse, the invoicing side runs on the F&O financial engine.
## The CRM side: customers
**[Sales](https://www.solvingdynamics365.com/guides/what-is-dynamics-365-sales)** handles leads, opportunities, pipeline, and forecasting — the core CRM most people picture. It is Microsoft's head-to-head competitor with Salesforce, and [that comparison](https://www.solvingdynamics365.com/guides/dynamics-365-sales-vs-salesforce) is its own guide.
**[Customer Service](https://www.solvingdynamics365.com/guides/what-is-dynamics-365-customer-service)** runs case management and omnichannel support — voice, chat, email, social — with SLAs, entitlements, and knowledge management. Its contact-centre sibling, [Dynamics 365 Contact Center](https://www.solvingdynamics365.com/guides/dynamics-365-contact-center-explained), packages the channel and Copilot layer as a standalone CCaaS product that can sit on top of other CRMs.
**[Field Service](https://www.solvingdynamics365.com/guides/what-is-dynamics-365-field-service)** schedules and dispatches mobile technicians: work orders, route optimisation, a technician mobile app, and IoT-triggered service. If your business sends people in vans to fix things, this is the app.
**Customer Insights** is one licence covering two distinct products. **[Customer Insights – Journeys](https://www.solvingdynamics365.com/guides/customer-insights-journeys-explained)** is the marketing automation app — customer journeys, email campaigns, events, lead scoring. **[Customer Insights – Data](https://www.solvingdynamics365.com/guides/customer-insights-data-explained)** is a customer data platform that unifies profiles from many systems. They install and work independently; the shared name causes endless confusion, and the [naming history](https://www.solvingdynamics365.com/guides/dynamics-365-marketing-history-and-transition) explains how it got this way.
## The operational extensions
**[Human Resources](https://www.solvingdynamics365.com/guides/what-is-dynamics-365-human-resources)** covers HR core: the employee record, org structure, leave and absence, benefits, and compensation. It is not a payroll engine — payroll comes from ISV partners — and in most deployments it feeds a broader HCM landscape rather than replacing one.
**[Commerce](https://www.solvingdynamics365.com/guides/dynamics-365-commerce-explained)** is the unified retail platform: head-office merchandising, store point-of-sale, e-commerce, and call centre, running on the same data model as Finance and Supply Chain Management. It is the deepest vertical product in the family and effectively assumes the F&O backbone underneath it.
## The platform underneath
Every app above stands on shared plumbing, and that plumbing is the real reason the family exists as a family.
The **[Power Platform](https://www.solvingdynamics365.com/guides/dynamics-365-and-power-platform)** — Power Apps, Power Automate, Power BI, Copilot Studio, and Power Pages — extends every Dynamics 365 app with low-code customisation, automation, analytics, AI agents, and external portals. In practice you cannot run a serious Dynamics 365 implementation without touching it; a Dynamics licence includes rights to use it against your Dynamics data.
**[Microsoft Dataverse](https://www.solvingdynamics365.com/guides/what-is-microsoft-dataverse)** is the shared data layer the CRM-side apps run on natively. The ERP apps keep their own databases and connect to it — a distinction with real architectural consequences, unpacked in [how the apps connect](https://www.solvingdynamics365.com/guides/how-dynamics-365-apps-connect).
Identity comes from **Microsoft Entra ID**, so one login covers CRM, ERP, Power Platform, and Microsoft 365. Infrastructure, compliance, and data residency are inherited from **Azure**. And **Copilot** now threads through the whole family — [the orientation guide](https://www.solvingdynamics365.com/guides/copilot-across-dynamics-365) covers what is real versus roadmap.
## How to read the family
Three practical rules keep the portfolio legible:
**The apps are sold separately.** "We're getting Dynamics 365" means nothing until someone names the apps. Each is licensed per user per month at its own price, with attach pricing when one user needs several — the [edition comparison](https://www.solvingdynamics365.com/guides/dynamics-365-edition-comparison) covers the licensing shape.
**The halves have different DNA.** The CRM apps share one database and feel like one product. The ERP apps are separate systems that integrate with the CRM side rather than merging with it. Expect integration work whenever a project spans the line.
**Names change; products mostly don't.** Marketing became Customer Insights – Journeys, Retail became Commerce, AX became Finance and Supply Chain, NAV became Business Central. When you meet an unfamiliar Dynamics name in older material, it is usually a current product wearing a previous badge.
Next step in the path: [how the apps actually connect](https://www.solvingdynamics365.com/guides/how-dynamics-365-apps-connect) — which links between them are tight, which are loose, and what that means for your architecture.
### Frequently asked questions
**Which Dynamics 365 apps are ERP and which are CRM?**
ERP: Finance, Supply Chain Management, Business Central, Commerce, and the financial half of Project Operations. CRM (Customer Engagement): Sales, Customer Service, Field Service, Customer Insights – Journeys and – Data, and the front half of Project Operations. Human Resources sits on the Finance and Operations platform.
**Is Business Central a cut-down version of Finance and Operations?**
No. Business Central descends from Dynamics NAV and Finance and Operations from Dynamics AX; they are different products with different data models and operating models. For most companies under a few hundred users Business Central is the right ERP, not a compromise.
**Do the Dynamics 365 apps share one database?**
The CRM apps do — they run natively on Dataverse and share Account, Contact, and Activity rows. The ERP apps keep their own databases and integrate with Dataverse through dual-write, virtual tables, or APIs. Any project that spans the line should budget integration work.
**What did the older Dynamics product names become?**
Dynamics 365 Marketing became Customer Insights – Journeys, Retail became Commerce, AX became Finance and Supply Chain Management, NAV became Business Central, and CRM became the Customer Engagement apps. Unfamiliar names in older material are usually current products under a previous badge.
---
# The Field Service mobile app
The Field Service mobile app — what technicians do in the field, offline capabilities, parts inventory, customer signatures, and Copilot.
Source: https://www.solvingdynamics365.com/guides/field-service-mobile-app
Section: Customer Engagement / Field Service
Published: 2026-05-01
The **Field Service mobile app** is where technicians actually do their work — the customer-facing screen of the entire Dynamics 365 Field Service investment. It runs on iOS and Android, online and offline, and is the productivity-or-bust component of any FSM implementation.
## Day plan
A technician's home screen is their schedule for the day: bookings in time order, each linked to a work order with customer location, contact details, equipment, parts requirements, and skill match. Tap a booking and the app navigates them through the work.
## Offline
Field Service must work offline; technicians regularly visit sites with no signal. The app maintains a local copy of the assigned work orders, customer history, knowledge articles, and parts inventory. Edits made offline queue and sync when connectivity returns. Conflict resolution is built around last-writer-wins with surfacing of differences.
## Navigation
The app integrates with the device's mapping system — Apple Maps on iOS, Google Maps on Android — for turn-by-turn navigation from one booking to the next. ETA is computed and pushed back to the customer as an arrival window.
## Customer history and assets
Tapping the customer or asset surfaces full history — past work, recurring faults, warranty status, contract entitlements. For complex equipment, the **asset hierarchy** (parent equipment with child sub-assemblies) is browsable inline.
## Time and inspections
Travel time, work time, and break time are captured with start/stop buttons. **Inspection forms** — configurable structured checklists with required fields, photos, and conditional branches — are completed on site and saved to the work order. Inspections are first-class objects with reportable data.
## Parts inventory
Each technician carries a **truck stock** location. Parts consumed on a job decrement the truck balance; replenishment requests can be created on the spot. Non-stocked parts can be ordered to the customer site.
## Customer signature and payment
At job close, the customer signs on screen (capture saved as image to the work order), receives an emailed PDF, and — in supported configurations — can pay invoice from the same flow.
## Photos and attachments
Photos taken in the app upload directly to the work order, including before/after evidence and damage records.
## Copilot
A field copilot answers questions about the work order ("what was the customer's last fault?"), summarises the previous visit, drafts the resolution notes, and suggests next steps based on knowledge articles.
## Practical wins
Done well, the mobile app drops average job time and dramatically improves first-time-fix rates. Done badly (no offline, slow, hard to log time), technicians shadow-log on paper and the data dies.
---
# The Global Address Book in Dynamics 365 Finance & Operations
How the Global Address Book unifies parties across customers, vendors, contacts, and workers in F&O — party types, role assignments.
Source: https://www.solvingdynamics365.com/guides/global-address-book-in-f-and-o
Section: Finance & SCM / Overview & platform
Published: 2026-05-01
A single individual or organisation might be a **customer** for one legal entity, a **vendor** for another, a **business contact** in CRM-style scenarios, and the **employer** of internal **workers**. Without a unifying model, the same party gets recorded multiple times with slight variations, and analytics lose coherence. F&O's **Global Address Book (GAB)** is the cross-legal-entity store that holds parties once and assigns them roles.
## Core entity: Party
A **party** in GAB is a person or organisation. Each party has:
- **Type** — Person or Organisation.
- **Name and address details.**
- **Contact information** — phone, email, URLs.
- **Identification numbers** — VAT registration, DUNS, government IDs.
- **One or more roles** — Customer, Vendor, Contact, Worker, Competitor, Other.
A party can hold multiple roles simultaneously: organisation Acme Corp is a Customer in three legal entities and a Vendor in one. Each role is a separate record in the role-specific table (Customer, Vendor) but linked back to the same party.
## Why this matters
Reconciling "who's who" across customer master, vendor master, and worker records becomes one query — joining through the party. Master data quality programs operate at party level; data quality fixes propagate to all roles.
## Cross-legal-entity sharing
GAB is **enterprise-wide** — one address book across all legal entities in the F&O tenant. A customer created in Legal Entity A can be activated as a customer in Legal Entity B by adding the customer role for that entity, reusing the underlying party.
This is a structural advantage F&O has over many ERPs: one global identity, locally activated as needed.
## Address book hierarchy
The hierarchy:
- **Default global address book** — the single shared book.
- **Custom address books** — optional sub-books for specific scopes (e.g. "Legal" address book for in-house counsel use).
Most installations use only the default book. Custom books are for unusual segregation requirements.
## Addresses on parties
Each party can have multiple **postal addresses**, each with:
- **Purposes** — Invoice, Delivery, Statement, Statutory, Multiple.
- **Effective from/to dates** — addresses can age in/out.
- **Primary flag** — designates the default for a purpose.
When a customer record is created, addresses are derived from the party's address book entries — but can be overridden at customer level if needed for that legal entity's relationship.
## Names and translations
A party may have:
- **Primary name** — the canonical name.
- **Translations** — alternative-script names (Chinese, Arabic) for global vendors.
- **Alternative names** — DBA, "trading as", historical names.
Search across all name variants is supported, useful for finding an organisation whose name has shifted over time.
## Contact persons
A **contact** in GAB is a person party linked to an organisation party via a role. This person is "the buyer at Acme" but also exists as a party in their own right — they could later become a vendor contact at a different organisation. Maintaining contacts at party level rather than per-customer-per-LE prevents duplicate contact records.
## Workers and HR
Internal employees are also parties. The worker party is linked to an HR worker record (in the HR module) or a project worker (in Project Operations). Same person, different roles.
## Duplicate detection
Adding a new party with a name similar to an existing party triggers duplicate warnings. The match algorithm uses name similarity, address proximity, and identifier overlap. Manual review confirms or rejects the duplicate.
## Merge
If two parties turn out to be the same:
- **Merge function** moves all role assignments to one surviving party.
- Transactions, addresses, contacts all redirect.
- The merged-away party is marked inactive but retained for audit history.
Use with care — merge is hard to undo.
## Integration with Dataverse and CDS
When F&O integrates with the Power Platform via **Dual-Write**, the GAB party model maps to Dataverse's Account and Contact tables. The party identifier becomes a key bridging both sides. This dual-write is the underlying plumbing for the unified "Dynamics 365" experience.
**Common pitfalls.**
- **Creating duplicates in workflow.** Sales rep creates a customer without checking if the party already exists; duplicate party emerges; reconciliation later is painful.
- **Address divergence.** Addresses overridden at customer level drift from the party master; cross-LE reporting shows different addresses.
- **Forgotten role activation.** A customer exists in LE A; LE B starts trading with the same customer but creates a new party instead of activating the existing one.
- **GAB performance at scale.** Very large GAB (millions of parties) can slow address book lookup; index tuning and archiving stale parties helps.
- **Merge ambiguity.** Merging two parties where one has high-value historical data; merge logic preserves the surviving party's data — picking the wrong survivor loses history.
**Operational disciplines.**
- **Master data ownership** — a single team owns party creation across all LEs, with workflow approval and duplicate-check enforcement.
- **Periodic dedupe runs** — duplicate detection runs against the full GAB, flagging probable duplicates for review.
- **Identifier governance** — VAT numbers, DUNS, government IDs collected and used as primary match keys.
## The unifying value
GAB is one of F&O's more architecturally interesting features — a global identity model that few competitors match. The implementation upside (data quality, cross-LE analytics, integration simplicity) only materialises with master data discipline; without it, GAB becomes another store of duplicates.
---
# The job queue in Business Central
How Business Central's job queue runs scheduled and background work — categories, parallelism, error handling, and operating discipline.
Source: https://www.solvingdynamics365.com/guides/the-job-queue-in-business-central
Section: Business Central / Admin & ops
Published: 2026-05-01
Business Central's **job queue** is the scheduler that runs background tasks — nightly batch routines, scheduled report distributions, asynchronous integrations, long-running calculations that shouldn't block the user. Configured well, it's invisible infrastructure; configured badly, it's the source of mysterious "this didn't run" support tickets.
## Job queue entries
A **job queue entry** is the schedule definition for one task. Each entry has:
- **Object Type** — Codeunit, Report, or XMLport.
- **Object ID** — which one to run.
- **Description** — a human-readable name.
- **Earliest Start Date/Time** — when the next run is scheduled.
- **Expiration Date/Time** — when the schedule ends (blank for indefinite).
- **Recurring Job** — yes or no.
- **Run On [Days]** — which days of the week recurring jobs fire.
- **Starting / Ending Time** — daily window for execution.
- **Status** — Ready, In Process, Error, Finished, On Hold.
- **Maximum No. of Attempts** — retry policy on failure.
- **Job Queue Category Code** — for grouping and parallelism control.
- **User ID** — the user context the job runs as.
## Job queue categories
Categories let you group entries and control concurrent execution. By default all entries share the same category and can run in parallel up to the platform limit. Custom categories with concurrency limits (`Max No. of Concurrent Jobs = 1`) serialise long-running work that mustn't overlap — e.g. inventory cost adjustment, currency revaluation, complex MRP runs.
## Errors and retries
A job that errors moves to Error status with the error message captured. The retry policy controls how many attempts run before final failure. Failed jobs are visible in the *Job Queue Log Entries* view with the full call stack for investigation.
## Standard scheduled work
Common job queue uses:
- **Adjust Cost — Item Entries** — nightly.
- **Post Inventory Cost to G/L** — nightly after Adjust Cost.
- **Currency Exchange Rate Service** — fetches daily rates.
- **Email reports** — scheduled report runs that PDF and email to distribution lists.
- **Bank account reconciliation imports** — pulls bank feeds.
- **Document send retries** — for failed email deliveries.
- **Power Automate-triggered actions** — many BC connectors create job queue entries internally.
## Parallelism
A standard tenant runs several job queue threads in parallel. Long-running blocking jobs in one category don't block other categories. The configuration tunes the trade-off between throughput (more parallel) and resource pressure (fewer parallel).
## User context
Each job runs as a specific user — important for permission and audit. Best practice: create a dedicated *Job Queue Service Account* user (a system user, not a person), assign appropriate permissions, and run all background jobs as that user. Avoids the messy "what happens when this user leaves" question.
## Telemetry
Job queue runs emit Application Insights telemetry — start, finish, duration, error. Build alerts on long-running or repeatedly-failing jobs.
**Common pitfalls.**
- **Job that errors but doesn't recover** — left in Error status indefinitely until someone notices. Build alerts on failed jobs.
- **Long-running job in a small window** — the job starts but doesn't finish before the ending time and is rescheduled. Investigate duration vs window.
- **Permission-failing job** — user lacks rights to a table the job touches. Audit the service-account user's permissions.
- **Conflicting jobs without category** — two jobs that mustn't overlap run in parallel and corrupt state. Assign them to a serialised category.
## Observability
Schedule a daily admin glance at the job queue. Most healthy tenants need only minutes; the alternative is the surprise call from a controller asking why nothing reconciled last month.
---
# The Landed Cost module in Dynamics 365 SCM
How the Landed Cost module captures the true cost of imported goods — voyages, shipping containers, charges, allocation methods.
Source: https://www.solvingdynamics365.com/guides/landed-cost-module-in-f-and-o
Section: Finance & SCM / Supply chain & inventory
Published: 2026-05-01
For companies importing goods internationally, the purchase price is only part of the cost. Freight, insurance, duties, brokerage, port charges, and inland transportation add 10–30% to the unit cost — and that "landed cost" is what should appear on the inventory valuation, not just the supplier invoice. The **Landed Cost** module in Dynamics 365 SCM models this end-to-end.
## Why a separate module
The classic F&O **Misc Charges** mechanism lets you add charges to a purchase order, but it doesn't model:
- Multiple shipments converging into one voyage.
- Charges incurred against a container, not a single PO.
- Cost allocation across many POs and many lines.
- Cost-as-of dates differing from invoice posting dates.
Landed Cost adds **voyages**, **containers**, and **cost types** as first-class entities that aggregate across purchase orders.
**Core entities.**
- **Voyage** — a vessel's trip from origin to destination, with a departure and arrival date.
- **Container** — a shipping container within a voyage, holding cargo.
- **Folio** — a grouping of charges (often per shipment).
- **Cost type** — a category of charge (sea freight, insurance, duty, broker fee).
- **Cost allocation method** — how a charge is distributed (by weight, volume, value, quantity, equal split).
**Workflow.**
1. Purchase orders are created normally.
2. A **shipping container** is created and PO lines assigned to it; the system computes total weight, volume, value per container.
3. The container is added to a **voyage**.
4. Estimated charges are recorded against the voyage or container (sea freight estimate, broker estimate, duty estimate). These flow into estimated landed cost on each PO line.
5. When the goods arrive, the receipt posts at estimated landed cost.
6. Actual invoices arrive over weeks (freight, duty, broker). Each is recorded against the voyage or container as actual charges.
7. Cost adjustment routines reconcile actuals vs estimates and post the variance.
## Allocation methods
For each charge, choose:
- **By weight** — heavy items absorb more.
- **By volume** — voluminous items absorb more.
- **By value** — high-value items absorb more.
- **By quantity** — flat per unit.
- **By equal share** — flat per PO line.
The right method per charge type matters: freight is usually weight or volume; insurance is usually value; duty is per-line per-tariff. A landed cost setup that uses one method for everything is naive.
## Estimated vs actual
Estimates flow into inventory cost immediately at receipt — without estimates, inventory is valued at supplier price only. When actuals arrive:
- **Variance** = actual - estimate per cost type.
- **Adjustment routine** processes the variance into existing inventory and COGS for already-sold items.
- **Variance accounts** capture systematic over- or under-estimation patterns.
## Duty and customs
Country-specific tariff codes and duty rates drive duty calculation. Landed Cost can compute duty per line based on Harmonised System (HS) codes and country of origin, integrating with customs declaration data. For complex customs, partner extensions (Avalara, Vertex landed cost) layer on top.
## Multi-currency
Cost types are typically denominated in different currencies — sea freight in USD, broker fees in local. The module handles per-currency conversion at the appropriate rate (charge date, receipt date, or invoice date — configurable).
**Reporting.**
- **Voyage cost analysis** — total landed cost per voyage, broken down by cost type.
- **Container utilisation** — value vs capacity.
- **Variance by cost type and supplier** — where estimates routinely miss.
This reporting is where landed cost yields ROI — identifying which trade lanes, which freight forwarders, which products consume more cost than expected.
## Integration with inventory cost
Landed Cost integrates with the F&O **cost engine**:
- Inventory close runs respect landed cost adjustments.
- FIFO/Weighted Average calculations use the landed cost, not just supplier price.
- COGS at the moment of sale reflects the most current landed cost calculation.
**Common pitfalls.**
- **Estimates too optimistic.** Persistent under-estimation; variances always negative; finance distrusts the module.
- **Allocation method mismatch.** All charges allocated by value; freight on a low-value bulky item is wrong.
- **Cost type proliferation.** Dozens of cost types where five would do; reconciliation becomes painful.
- **Late actuals.** Invoices arriving months later; inventory has already been sold; adjustments hit COGS unexpectedly.
- **Integration with broker spreadsheets.** Broker provides duty in Excel; manual re-keying introduces errors. Build an import process.
## Operational rhythm
A monthly landed cost close: confirm all voyages with departures in the month are estimated; reconcile any actuals received; post adjustments. A quarterly variance review identifies systematic estimation issues.
## When to use it
If imports are >5% of cost and >20% of inventory by value, Landed Cost pays back. For occasional imports, the simpler Misc Charges approach is sufficient.
---
# The marketing and relationships module in Business Central
Business Central's built-in contact-and-relationship management — when it works, when Dynamics 365 Sales is the better answer.
Source: https://www.solvingdynamics365.com/guides/the-marketing-and-relationships-module-in-business-central
Section: Business Central / Sales & purchasing
Published: 2026-05-01
Business Central ships a **Relationship Management** module — historically called Marketing — with contact records, interactions, opportunities, segments, and campaigns. It is a *light* CRM, included with both Essentials and Premium, and it covers many SMB needs without a separate Dynamics 365 Sales subscription. Knowing when it's enough — and when it isn't — saves both money and confusion.
## The data model
The module centres on:
- **Contacts** — people and companies. Independent of the financial Customer record, though linkable. The flexibility lets you track prospects who aren't yet customers, leads, partners, and other non-financial relationships.
- **Contact Companies and Contact Persons** — modelled separately, with employees attached to companies.
- **Interactions** — recorded touchpoints: phone calls, emails, meetings, letters, web form submissions. Each interaction has an interaction template, a date, a comment, and links to the contact.
- **Opportunities** — sales pursuits in progress, with sales cycle stages, estimated value, probability, and expected close date.
- **Segments** — saved groups of contacts for targeted campaigns.
- **Campaigns** — marketing initiatives with start/end dates, budgeted cost, and connected segments.
**What it does well.**
- Track interactions across customers, vendors, prospects in a single timeline.
- Manage a basic sales pipeline with stages and weighted forecasts.
- Send simple targeted email to segmented contact lists.
- Capture and qualify leads.
- Maintain centralised contact data linked to the customer/vendor financial records.
**What it doesn't do.**
- Sophisticated sales process automation, AI-driven scoring, or copilot-grade selling assistance.
- Omnichannel customer service with case management, SLA enforcement, knowledge base.
- Marketing automation at journeys-grade — multi-step nurture sequences, A/B testing, advanced personalisation.
- Account hierarchies, complex territory management, sales accelerators.
- Full integration with Outlook / Teams / Power BI at the depth Dynamics 365 Sales offers.
## When BC's module is enough
Small businesses with a handful of salespeople, simple pipeline tracking, basic interaction logging, occasional email outreach — BC's module covers it without a Sales subscription. Common in companies under 25 users where the cost of separate Dynamics 365 Sales licences would exceed the benefit.
## When to upgrade to Dynamics 365 Sales
Signs you're outgrowing BC's module:
- Sales team is large enough to want their own dedicated tool, not a corner of the ERP.
- Pipeline reporting needs are sophisticated — forecasting, manager hierarchy roll-ups, AI-predicted insights.
- Email integration with Outlook needs to be deep — track every email automatically, see CRM context in Outlook.
- Customer service operates on cases and SLAs, not just interactions.
- Marketing automation needs are real — multi-step journeys, A/B tests, attribution.
- Copilot-style AI assistance is wanted.
## The hybrid pattern
Many BC customers keep the Relationships module for basic interaction logging and central contact management, *plus* subscribe to Dynamics 365 Sales for the people who genuinely sell. Integration between the two is configured: customers and contacts sync between BC and Dataverse via the standard connector or Power Automate flows.
## Migration path
When upgrading from BC Relationships to Dynamics 365 Sales:
1. Provision the Sales environment in Dataverse.
2. Map BC's Contacts to Dataverse Accounts and Contacts.
3. Migrate opportunities and interactions if historical data is needed.
4. Configure dual-write or scheduled sync between the two systems for ongoing.
The cleanest moves keep BC as the financial system and Dynamics 365 Sales as the relationship system, with clear ownership rules per data type.
---
# The multi-session experience in Customer Service
How the Customer Service Workspace handles multi-session agents — tabs, productivity pane, capacity profiles, and the operational realities.
Source: https://www.solvingdynamics365.com/guides/multi-session-experience-in-customer-service
Section: Customer Engagement / Customer Service
Published: 2026-05-01
A contact-centre agent handles many things at once — a chat in progress, an open case, a phone call about to start, knowledge being searched, customer history being checked. The **Customer Service Workspace** (formerly Omnichannel for Customer Service) is built around this reality: a multi-session, multi-tab experience where the agent can hold parallel conversations and records without losing context.
## Sessions
Each *active conversation* or *focused work item* is a **session**. The agent can have multiple sessions open concurrently, switching between them like browser tabs. A session typically anchors on a customer interaction — a chat, a phone call, a case, an email being composed — and holds the relevant tabs alongside.
## The session pane
Sessions appear in a vertical list on the left of the screen. Active session is highlighted; idle sessions show a count of unread messages or pending actions. Closing a session ends it.
## Tabs within a session
Each session can have multiple **tabs** — typically the conversation (chat/voice/email), the customer record, the case, related knowledge articles, and any inspection or form the agent is filling. The tabs are independent — the agent can switch tabs without losing place in the conversation.
## The productivity pane
A right-side pane in each session holds **productivity tools** — knowledge search results, smart assist suggestions, conversation summary, related cases, suggested replies. The pane is contextual: opening the conversation tab shows conversation-related tools; opening the customer record shows customer-related tools.
## Smart Assist and Copilot
Real-time AI-driven assistance:
- **Conversation summary** — when the agent opens a chat already in progress (e.g. transferred from another agent), Copilot summarises what's happened in a sentence.
- **Suggested replies** — based on the conversation, AI suggests answer phrasings the agent can accept, edit, or reject.
- **Knowledge surfacing** — articles relevant to the current conversation appear without explicit search.
- **Case summarisation** — at handoff or escalation, Copilot drafts a structured case summary the agent reviews and saves.
## Capacity profiles
Multi-session works only if assignment respects agent capacity. Each agent has a **capacity profile** declaring how much work they can hold simultaneously — typically 1 voice call, 3 chats, 5 cases, no email. Unified Routing honours the profile: a chat won't route to an agent already at the chat cap.
**Channel-specific behaviour.**
- **Voice calls** — exclusive: an agent on a live voice call can browse other sessions but the voice conversation is the focus.
- **Chats** — concurrent: multiple chats run in parallel.
- **Emails** — long-running: emails can be composed across many short sessions without losing draft state.
- **Cases** — background: cases sit as sessions while the agent works on conversations, then come to focus when needed.
## Personalisation
Agents can configure their multi-session experience — number of tabs to remember, default productivity-pane tools, notification preferences. Supervisors can set defaults per role.
## Performance
The multi-session UI is data-heavy on the client. Slow networks degrade the experience; the configuration of how many sessions auto-load, how aggressively the productivity pane pre-fetches data, and which tools are enabled matters for agent satisfaction.
## Supervisor view
Supervisors see real-time dashboards of agent sessions, conversation health, escalation flags. Live conversation monitoring (whisper, barge, listen on voice; observe on chat) lets supervisors intervene on stuck calls.
## Configuration discipline
Tune the multi-session experience for each agent role. A first-line chat agent's workspace differs from an escalation specialist's. Don't ship one configuration to all agents.
## Operational reality
Once agents adapt to multi-session, they don't go back. Average handling time drops, customer satisfaction improves, agent satisfaction often improves too. The configuration investment is real but one-time.
---
# The outbox pattern with Service Bus
A resilient integration pattern for Dynamics 365 — combining an outbox table with Service Bus to deliver guaranteed-once messaging across systems.
Source: https://www.solvingdynamics365.com/guides/the-outbox-pattern-with-service-bus
Section: Integrations / Architecture patterns
Published: 2026-05-05
For mission-critical integrations between Dynamics 365 and external systems, naive direct calls have a problem: what happens when Dynamics 365 commits a transaction but the integration call fails? The change exists in Dynamics 365 but never reached the downstream system; data is now inconsistent. The **outbox pattern** solves this by combining a Dataverse "outbox" table with Azure Service Bus to guarantee that every committed change reaches downstream systems exactly once, eventually.
**The problem with direct integration calls.**
A typical pattern: a plug-in on Dataverse opportunity-close fires, calls an external API to push the sale to the back-office ERP, the API responds, the plug-in completes, the transaction commits.
What can go wrong:
- The API call succeeds but the Dataverse transaction rollbacks for unrelated reasons. The downstream system has the data; Dataverse doesn't. Inconsistency.
- The API call times out (5-minute plug-in limit). The plug-in fails; Dataverse rollbacks. From the user's perspective, the operation failed; but the downstream may have processed it.
- The API is temporarily unavailable. The plug-in fails; the user retries; but the rule is "do this only once".
These problems are why naive synchronous integration is unreliable for important data.
**The outbox pattern.**
The pattern decouples the *recording* of intent from the *delivery* of the message:
1. **Within the Dataverse transaction**: a plug-in (or flow) records a message into an **outbox table** in Dataverse. The outbox row holds the payload, target, and metadata. The Dataverse transaction commits atomically — either both the business change and the outbox row commit, or neither.
2. **Out of band**: a separate worker (Azure Function on a timer, a flow on schedule, a continuous-running service) reads new outbox rows, publishes them as Service Bus messages to the appropriate queue, then marks the outbox row as published.
3. **Service Bus** durably holds the message. The downstream consumer reads at its own pace.
4. **Idempotent consumer**: the downstream system processes each Service Bus message and is designed to be idempotent — receiving the same message twice produces the same result (no double-processing).
5. **Confirmation**: optional — the consumer acks back, and the outbox row marks complete.
**Why this works.**
- **Atomic outbox commit** — the business change and the message-to-send commit together. Either both happen or neither.
- **Service Bus durability** — once the message is on the queue, downstream can be offline for hours / days without losing it.
- **Idempotency** — the consumer can safely receive a message twice (e.g. if the publisher published, then crashed before marking the outbox row complete).
- **Retry** — failed deliveries retry from the queue; persistent failures land in the dead-letter queue for investigation.
**Implementation in Dataverse.**
- **Outbox table** — a custom Dataverse table with columns: payload (JSON), target, status (Pending / Published / Acked / Failed), created date, published date, retry count.
- **Plug-ins / flows** — insert rows into the outbox in the same transaction as the business change.
- **Publisher worker** — Azure Function on a timer, every 10–30 seconds, queries new outbox rows and publishes them.
- **Service Bus** — the durable channel.
- **Downstream consumer** — reads Service Bus messages, processes idempotently, optionally acks back.
## The change tracking alternative
If Dataverse change tracking is enabled, the publisher worker can poll change tracking instead of an explicit outbox table. The pattern is similar but uses Dataverse's built-in delta mechanism rather than a custom outbox.
**When to use the outbox pattern.**
- **Mission-critical integrations** where data loss is unacceptable.
- **High-volume integrations** where Service Bus's durability and decoupling matter.
- **Cross-system business processes** that span Dataverse and other systems.
**When not.**
- **Low-stakes integrations** where occasional inconsistency is recoverable. Direct calls or basic webhooks suffice.
- **Read-only integrations** where the consumer pulls from Dataverse. The outbox is about *push from Dataverse*, not pull.
- **Real-time UI-blocking calls** — outbox is asynchronous; users don't wait for downstream success.
**Trade-offs.**
- **Complexity** — multiple components to design, build, monitor. The reliability benefit must justify the complexity.
- **Latency** — outbox-based integration has small delay (seconds to a minute typically). For most business processes that's fine; for some it isn't.
- **Operational discipline** — monitor outbox depth, dead-letter queue, retries. Without active monitoring, problems hide.
**Common pitfalls.**
- **Outbox not in the same transaction** — defeats the purpose. The outbox insert must be atomic with the business change.
- **Consumer not idempotent** — duplicates cause double-processing. Use message IDs or natural keys.
- **No dead-letter handling** — failed messages accumulate silently. Build alerting.
- **Outbox not cleaned up** — millions of completed rows degrade Dataverse performance. Archive or delete old rows.
## Operational reality
The outbox pattern is canonical enterprise-integration practice; not specific to Dynamics 365. Adopting it for the integrations that matter is one of the highest-leverage reliability investments.
## Where to go next
The queue side is covered in [Service Bus integration with Dataverse](https://www.solvingdynamics365.com/guides/azure-service-bus-integration-with-dataverse) and the Business Central variant in [webhooks vs Service Bus](https://www.solvingdynamics365.com/guides/integrating-business-central-webhooks-vs-service-bus). For multi-step transactions on top of the outbox, [the saga pattern](https://www.solvingdynamics365.com/guides/saga-pattern-for-dynamics-365) and [eventually consistent integrations](https://www.solvingdynamics365.com/guides/eventually-consistent-integrations-with-dynamics-365); for the read-side alternative, [change tracking in Dataverse](https://www.solvingdynamics365.com/guides/change-tracking-in-dataverse).
---
# The Plug-in Registration Tool — a deep dive
How PRT registers Dataverse plug-ins — assemblies, steps, images, secure/unsecure configuration, and where the tool fits in modern ALM.
Source: https://www.solvingdynamics365.com/guides/plug-in-registration-tool-deep-dive
Section: Power Platform / Custom development
Published: 2026-05-01
The **Plug-in Registration Tool (PRT)** has been the workbench for Dataverse plug-in development for over a decade. It registers compiled .NET assemblies into a Dataverse environment, wires them to table events, defines step parameters and pre/post images, and exposes secure configuration. Despite modern alternatives (Power Platform Build Tools, solution-based registration), PRT remains the everyday tool for plug-in developers.
## Where PRT comes from
Part of the Dataverse SDK; downloadable as a `Microsoft.CrmSdk.XrmTooling.PluginRegistrationTool` NuGet package. Run-anywhere desktop tool, connects to a Dataverse environment.
**Core registration units.**
- **Assembly** — the compiled .DLL containing plug-in classes.
- **Plug-in class** — a C# class implementing `IPlugin`.
- **Step** — a registration tying a class to a table event with execution parameters.
- **Pre-image / Post-image** — captured snapshots of the row before/after the operation.
- **Service endpoint** — registration of an Azure Service Bus or Event Grid endpoint as a step target.
**Workflow.**
1. **Build** the plug-in DLL in Visual Studio.
2. **Connect** PRT to the Dataverse environment.
3. **Register Assembly** — pick the DLL; PRT inspects classes; registers as an assembly record.
4. **Register Step** — pick a class, table, event (Create/Update/Delete), stage (Pre/Post), execution mode (Sync/Async), filtering attributes (only fire on these column changes).
5. **Register Image** if needed — capture snapshot of specified attributes.
6. **Test** — trigger the event; verify the plug-in fired.
**Step parameters.**
- **Message** — `Create`, `Update`, `Delete`, `Retrieve`, `RetrieveMultiple`, `Associate`, `Disassociate`, custom action.
- **Primary table** — the table the event fires against.
- **Stage** — Pre-validation, Pre-operation, Post-operation.
- **Execution mode** — Synchronous (in transaction) or Asynchronous (background queue).
- **Filtering attributes** — limits firing to changes in specified columns.
- **Run in user's context / specific user** — security context for the plug-in.
- **Deployment** — Server (Dataverse), Offline (mobile offline), or Both.
**Stages explained.**
- **Pre-validation** — fires before the platform validates the operation; can be on any rollback. Used for very early gates (license checks, custom auth).
- **Pre-operation** — fires after validation but before the DB commit. Most common for mutation logic on the operation's record.
- **Post-operation** — fires after commit. Most common for cascading side effects.
**Sync vs async.**
- **Sync** — runs inline with the user's operation; failures roll back the operation. Maximum 2 seconds before the platform considers it slow.
- **Async** — runs in the system job queue; out-of-band from the user.
For validation, sync. For external integrations and side effects, async.
**Pre-image and post-image.**
- A plug-in's `IExecutionContext.PreEntityImages` / `PostEntityImages` give snapshots of the row.
- Required for Update steps that need to compare before/after.
- Each image has a name (typically `PreImage`, `PostImage`); the plug-in code references by name.
- Image attributes specify which columns are included — capturing only what you need.
**Secure / unsecure configuration.**
- **Unsecure** — string passed to the plug-in via `IPluginExecutionContext`; visible in PRT.
- **Secure** — encrypted; visible to the plug-in at runtime but not in the registration UI.
Use secure for API keys, credentials, sensitive parameters. Use unsecure for non-sensitive tuning (modes, flags).
## Solution-aware registration
Modern practice:
1. Create a solution.
2. Add the plug-in assembly to the solution.
3. Add the steps and images to the solution.
4. Export/import the solution to promote across environments.
PRT supports this by tagging registrations with solution membership. Promotion happens through solution import in each environment, not through re-registering with PRT in each.
**Modern alternatives.**
- **Power Platform Build Tools** (Azure DevOps task / GitHub Action) — automate registration as part of CI/CD pipeline. Reduces manual PRT clicking.
- **Solutions via packagedeployer** — package the assembly with metadata; promote together.
- **CLI commands** — `pac plugin push` from the Power Platform CLI.
For mature teams, PRT is the dev-time tool; promotion is automated.
**Common pitfalls.**
- **Forgot to add the step to a solution.** Step exists in dev but doesn't promote; downstream environment lacks it.
- **Wrong stage chosen.** Pre-validation for logic that should be post-operation; cascading effects don't happen.
- **Sync plug-in slow.** Drags user-facing operations; flip to async if validation isn't blocking-critical.
- **Image not registered or name mismatch.** Plug-in code refers to `"PreImage"` but registration created `"preimage"`; case-sensitive failure.
- **Secure configuration leaked.** Connection strings in unsecure config; visible to anyone with admin access; rotate immediately.
- **Plug-in chains causing recursion.** A plug-in updating its own table triggers itself; infinite loop; protect with depth checks (`IExecutionContext.Depth > 1` is a common guard).
## Operational discipline
PRT is the daily tool for plug-in developers but should never be the production deployment tool. Build/test with PRT; promote via solutions. The line between "registered in dev" and "registered in prod" should be the solution import pipeline, not someone clicking PRT in prod.
---
# The Power Platform admin centre
The Power Platform admin centre — what it does, who uses it, and how it relates to the Microsoft 365 and Dynamics 365 admin centres.
Source: https://www.solvingdynamics365.com/guides/power-platform-admin-center
Section: Power Platform
Published: 2026-05-01
The **Power Platform admin centre** at admin.powerplatform.microsoft.com is the central console for managing environments, capacity, governance, DLP, and increasingly Dynamics 365 itself. It sits alongside the Microsoft 365 admin centre and is gradually absorbing functions that used to live in Dynamics 365 admin or LCS.
## Environments
The main screen. List of every environment in the tenant with type, region, Dataverse status, version, and storage usage. Drill into one to manage users, security groups, backups, copying, resetting, and platform updates.
## Resources
Beyond environments, the admin centre shows tenant-wide resources: **capacity** (Dataverse storage broken into database/file/log), **API call usage**, **AI Builder credits**, **flow runs**, **per-app passes**, and licence assignments. Surface for cost monitoring and capacity planning.
## Analytics
Built-in dashboards for environment health, flow usage, app usage, Dataverse storage trends, API call patterns, and user adoption. The kind of thing that catches "we're about to hit the limit" three weeks before disaster.
## Data policies (DLP)
Define **DLP policies** that classify connectors as Business, Non-Business, or Blocked, and prohibit flows or apps from mixing classes. Policies apply per environment or globally. Effective DLP prevents accidental exfiltration through a Power Automate flow that posts Dataverse data to a personal Dropbox.
## Help + support
Open tickets to Microsoft for Power Platform issues directly from here, including for Dynamics 365 components.
## Settings
Tenant-level configuration: AI features, copilot opt-ins, on-premises data gateways, custom connectors, environment groups for fleet management, isolation settings.
## Solutions and apps
A managed view of solutions and apps across environments — useful for tracking what's deployed where. Pipelines deploy through here.
## Environment groups
A newer feature: group environments and apply a configuration policy (security group, DLP, backup schedule) across the whole group, rather than per environment. Helpful at scale.
## The future
Microsoft is consolidating admin experiences: many functions that historically lived in the legacy **Dynamics 365 admin centre** are being deprecated in favour of the Power Platform admin centre. Eventually LCS for F&O will follow suit — already, several F&O lifecycle tasks now appear in this console.
## Permissions
Access requires Entra roles — **Power Platform Administrator**, **Dynamics 365 Administrator**, or **Global Administrator**. Day-to-day admin should use scoped roles, not Global Admin, to limit blast radius.
---
# The resource hub in Project Operations
How resource management works in Dynamics 365 Project Operations — bookable resources, skills, calendars, requests, and the bookings model.
Source: https://www.solvingdynamics365.com/guides/resource-hub-in-project-operations
Section: Customer Engagement / Project Operations
Published: 2026-05-01
For a services business, resourcing is the operational heart of the system — who's free, who has the right skills, who can travel, who's most billable, who's underutilised. Dynamics 365 Project Operations models this through the **resource hub**, a workspace combining resource records, requirements, requests, and bookings.
## Bookable resources
A **bookable resource** is anyone or anything that can be scheduled. The basic types:
- **User** — an employee mapped to a Dataverse user.
- **Contact** — an external contractor.
- **Account** — a partner organisation.
- **Equipment** — physical equipment that can be assigned to projects.
- **Group** — a named team treated as a unit.
- **Crew** — a pre-defined multi-resource team.
- **Facility** — a meeting room or location.
Each bookable resource carries:
- **Skills** — what the resource can do (Architect, Project Manager, Senior Developer, Spanish-speaking, AWS-certified, etc.).
- **Role** — the primary job role.
- **Cost rate** — internal hourly cost.
- **Billing rate** — default billable rate.
- **Calendar** — working hours, holidays, time off.
- **Location** — for travel-time calculation and territory matching.
## Skills and proficiency
Skills are configured as a hierarchical taxonomy. Each resource's skills carry **proficiency levels** (1–5 or beginner-to-expert). Matching considers both presence and proficiency — a senior architect role requires Architect skill at proficiency 4+.
## Resource requirements
A project task or role identifies a need — "Senior Architect for 2 weeks starting March 1st, 80% utilisation, Spanish-speaking preferred, must be in EU for travel cost". The requirement captures the **specifications**; the matching engine finds candidates.
## The resource hub workspace
Inside Project Operations, the resource hub workspace shows:
- **Schedule board** — Gantt-style view of every resource's bookings across time, draggable for changes.
- **Resource utilisation** — billable vs total time per resource, with red/amber/green health indicators.
- **Open requirements** — unfilled resource needs across active projects, with priority and start date.
- **Request queue** — formal resource requests awaiting approval and assignment.
## Resource requests and approvals
Different organisations use different resourcing flows:
- **Direct booking** — project manager picks a resource and books directly.
- **Resource request workflow** — project manager submits a request to a resource manager who approves and assigns.
- **Hybrid** — direct for low-impact bookings, request flow for high-impact (long duration, senior resources, cross-region travel).
Workflows are configurable per organisation.
## Generic resources and substitution
Early in a sales pursuit, a deal is staffed with **generic resources** (placeholders representing roles, not named people) so utilisation forecasting works without committing real people prematurely. When the deal closes, generics are replaced with named bookable resources.
## Match-and-suggest
Project Operations uses an AI-assisted match function: given a requirement, suggest the best candidates ranked by:
- Skill match (presence and proficiency).
- Availability (calendar).
- Cost (internal cost rate).
- Past project performance.
- Location.
The resource manager reviews suggestions and makes the final pick.
## Bookings
A **booking** binds a resource to a project / task for a date range and capacity. Bookings have statuses (soft, hard, committed) — softs are pencilled in; hards are committed and notified.
## Integration with timesheets
Once booked, the resource sees the booking in their Project Operations workspace; time entered on the booked project task posts back as actuals against the booking.
## Reporting
Utilisation per resource, project, role, region; bench time (resources without bookings); pipeline coverage (do we have enough capacity for the projects we hope to win?).
## Operational reality
Resource hub adoption follows resource-manager discipline. Without the resource manager actively running the hub, the system surfaces inaccurate utilisation, requests pile up, and projects start without resourcing certainty. The technology supports the discipline; it doesn't replace it.
---
# The saga pattern for cross-system Dynamics 365 transactions
How to handle multi-system business transactions that need to be atomic across Dynamics 365 and external systems — orchestration vs choreography, compensation.
Source: https://www.solvingdynamics365.com/guides/saga-pattern-for-dynamics-365
Section: Integrations / Architecture patterns
Published: 2026-08-07
A business operation often spans multiple systems — placing an order updates Dynamics 365 CRM, debits inventory in F&O, charges the payment processor, ships from the WMS. Each system has its own transaction; there's no global transaction that wraps all four. If one fails partway, the others may have already committed. The **saga pattern** is how to handle this — multi-step business operations that must succeed-as-a-whole-or-rollback-the-side-effects, across systems that don't share a transaction context.
**The problem.**
Traditional database transactions guarantee ACID — all operations succeed atomically or all fail. Across systems, ACID doesn't work — there's no two-phase commit across Dataverse, F&O, the payment processor, and the WMS. Each commits independently. If step 3 fails after steps 1-2 succeeded, you need to undo steps 1-2 explicitly — a **compensating transaction**.
The saga pattern formalises this.
**The saga.**
A **saga** is a sequence of local transactions:
```
T1 → T2 → T3 → T4 (success path)
```
Each Ti is a transaction in one system. If any Ti fails, **compensating transactions** run in reverse:
```
C1 ← C2 ← C3 (undoing T1, T2, T3 if T4 fails)
```
Where Ci is the operation that undoes Ti's effects. The saga either reaches completion (all forward steps succeed) or fully rolls back (all completed forward steps are compensated).
**Two implementation styles.**
## Orchestration
A central **saga orchestrator** drives the sequence:
```
Orchestrator → System A: do step 1
System A: done
Orchestrator → System B: do step 2
System B: done
...
```
If a step fails, the orchestrator initiates compensation:
```
Step 3 failed
Orchestrator → System B: compensate step 2
Orchestrator → System A: compensate step 1
```
The orchestrator knows the full state and recovery logic. Typically built with Azure Durable Functions, Workflow Designer, or similar tooling.
## Choreography
No central orchestrator. Each system publishes events; subsequent systems react. A failure publishes a "rollback" event that triggers compensation in upstream systems.
Choreography decouples but distributes the saga logic. Harder to reason about; useful for very loosely-coupled systems.
For most Dynamics 365 cross-system business processes, **orchestration** is the cleaner pattern.
**Implementing a saga.**
**Order placement example.**
Steps:
1. **T1**: Create order in Dynamics 365 Sales (status = Draft).
2. **T2**: Reserve inventory in F&O.
3. **T3**: Charge payment via payment processor.
4. **T4**: Update Dynamics 365 order to Confirmed; release to WMS.
Compensations:
- **C1**: Cancel order in Dynamics 365 (status = Cancelled).
- **C2**: Release inventory reservation in F&O.
- **C3**: Refund payment via payment processor.
Implementation with an orchestrator (Azure Durable Functions):
```csharp
// Pseudocode for an orchestrator
public async Task PlaceOrderSaga(OrderRequest order)
{
try
{
await CreateOrderInD365(order);
try
{
await ReserveInventoryInFnO(order);
try
{
await ChargePayment(order);
await ConfirmOrderInD365(order);
// Success
}
catch
{
await ReleaseInventoryInFnO(order); // C2
throw;
}
}
catch
{
await CancelOrderInD365(order); // C1
throw;
}
}
catch
{
// Log; alert; possibly retry
throw;
}
}
```
In real implementations, durable orchestrators (Azure Durable Functions, Power Automate workflows with state, custom workflow engines) handle the retry logic, durability across restarts, and timeout handling.
**Compensation pattern principles.**
- **Compensations are semantically reversing, not bit-for-bit undo.** Cancelling an order leaves a "Cancelled" record — it's not deleted. The compensation reverses the *business effect*, not the *technical write*.
- **Compensations should be idempotent.** A compensation may also fail and retry; running it twice produces the same final state.
- **Some operations are not reversible.** Sending an email; debiting a card (sometimes — refunds may have time limits). Build with the trade-off in mind: irreversible operations need extra care upfront.
- **Order matters.** Compensations typically run in reverse order; compensating T3 first then T2 is the standard.
**Timeouts and SLAs.**
Long-running sagas need timeout handling:
- Step times out → consider that step failed → trigger compensation.
- Whole saga times out → manual intervention; alert operations.
**Visibility.**
A user placing an order shouldn't wait for the full saga to complete if it takes seconds-to-minutes. The pattern: acknowledge the order is being processed (return quickly); the saga runs asynchronously; the user is notified on success or failure.
This UX requires:
- Async API design.
- Status records the user can check.
- Notifications on completion.
## Power Automate as orchestrator
Simple sagas can be implemented as Power Automate flows. Limitations:
- Long-running flows have time limits.
- Compensation logic must be hand-written.
- State and visibility through flow run history.
For more complex sagas, Azure Durable Functions or custom orchestration is preferable.
**When to use the saga pattern.**
- **Genuine multi-system business operations** that must be atomic.
- **Operations crossing 3+ systems** where partial completion would be invalid.
- **Operations with meaningful side effects** that need explicit rollback.
**When not.**
- **Operations within a single system** — use that system's transaction.
- **Truly fire-and-forget** events — if partial completion is acceptable, no saga needed.
- **Read-only operations** — no rollback needed.
## Operational reality
Sagas add complexity. Justify the pattern by the business requirement; document the compensation logic clearly; test failure paths deliberately (chaos-engineering style); monitor sagas in production.
---
# The standard cost worksheet in Business Central
How Business Central's standard cost worksheet helps maintain and revalue standard-cost items — annual cost rolls, what-if analysis, and the GL impact.
Source: https://www.solvingdynamics365.com/guides/the-standard-cost-worksheet-in-business-central
Section: Business Central / Finance & accounting
Published: 2026-05-01
For manufacturers and distributors using **standard cost** as their inventory costing method, the **standard cost worksheet** is the tool that maintains and revalues item standards. It supports the annual cost roll, mid-year revaluations, and what-if scenarios — with the GL posting that reconciles inventory value to the new standards.
## Why standard cost
Standard cost stabilises inventory valuation independent of fluctuating actual purchase prices. Variances (between standard and actual purchase price, or between standard and actual production cost) post to dedicated variance accounts, making operational deviations visible. Common in manufacturing where production costs should be predictable for pricing and margin analysis, and in distribution for high-volume items where average-cost noise distorts margin.
## The annual cost roll
Once a year (typically before the new fiscal year), companies update the standard costs to reflect current input prices, current routing rates, and current overhead allocations. The standard cost worksheet is where this happens:
1. **Suggest Item Standard Cost** — populate the worksheet with current standards for selected items.
2. **Adjust** — calculate new proposed standards based on:
- Current vendor purchase prices for raw materials.
- Current production BOM and routing costs.
- Overhead rate applied to direct costs.
3. **Review** — the worksheet shows old standard, proposed new standard, % change, and the cost components that drove the change.
4. **Approve and post** — apply the new standards. The system updates the item card and posts revaluation journal entries.
## Components of standard cost
For a manufactured item, the standard breaks into:
- **Material cost** — sum of BOM components at their standard.
- **Capacity cost** — sum of routing operations' setup and run time at work-centre rates.
- **Subcontracting cost** — for subcontracted operations.
- **Capacity overhead** — applied as a rate on capacity time.
- **Manufacturing overhead** — applied as a percentage or fixed amount.
The worksheet rolls these components for each item, giving full transparency into where cost is changing.
## Revaluation journals
When the standard changes, the inventory value at the old standard differs from the inventory value at the new standard. The system calculates the difference per location, per item, per variant, and posts a revaluation journal:
- Debit / Credit Inventory (depending on direction of change).
- Offset to Revaluation Variance GL account.
This brings inventory to the new standard cleanly, with audit-trail journal entries for finance reconciliation.
## What-if analysis
The worksheet can be run without posting — calculate proposed standards, review the impact, adjust assumptions (e.g. test what a 5% raw material increase does to finished goods), and discard. Useful for budgeting and pricing simulations.
## Mid-year revaluation
For items where the annual roll isn't enough — a major commodity price move, a contract renegotiation, a new supplier — the worksheet supports mid-year revaluation of selected items. Same mechanism, smaller scope.
## The full inventory implication
Standard cost only works if **all transactions post at standard**. Sales orders, production orders, transfers, and consumption all use the standard. Variances between standard and actual flow to variance accounts on receipt and on production-order completion. Run **Adjust Cost — Item Entries** before period-end to capture all variances.
## Operational discipline
Document the standard cost roll process as an annual procedure — owner, timing, sign-offs, exception handling. Standard-cost discipline is finance and operations together; the worksheet is the bridge.
---
# The Success by Design methodology
Microsoft's current Dynamics 365 implementation methodology — iterative delivery, fit-to-standard, and the role of Solution Blueprint Reviews.
Source: https://www.solvingdynamics365.com/guides/the-success-by-design-methodology
Section: Implementation / Methodology
Published: 2026-05-01
**Success by Design (SBD)** is Microsoft's published implementation methodology for Dynamics 365, replacing the older waterfall-flavoured Sure Step. It is the framework FastTrack engineers use to engage with qualifying customer projects, and the de-facto standard most experienced partners now follow. Whether or not the project is officially FastTracked, the SBD content is freely available and worth applying.
## Core stance
SBD starts from a hard principle: **fit to standard** before fit to custom. Map every customer requirement against what Dynamics 365 does out of the box, configure to close the gaps, customise only when no acceptable standard exists. Customisation cost compounds across upgrades; configuration largely doesn't.
## The phases
SBD organises a project into five phases, each with characteristic outcomes:
1. **Initiate** — establish governance, scope, business case, FastTrack relationship.
2. **Implement** — iterative configuration and customisation, with regular alignment checkpoints. Often run in time-boxed sprints.
3. **Prepare** — UAT, training, cutover planning, integration testing at scale.
4. **Operate** — go-live and stabilisation.
5. **Optimize** — post-go-live continuous improvement, including release wave readiness.
Each phase is iterative, not gated; the phases overlap and feedback flows between them continuously.
## Solution Blueprint Review (SBR)
The headline ritual. Roughly mid-implementation, the partner and customer present a **solution blueprint** to Microsoft FastTrack: the conceptual architecture, customisations planned, integrations, data migration, performance, security, and risks. FastTrack reviews against a published rubric and provides written guidance — go, go-with-changes, or hard concerns to address. Many projects do informal SBRs even outside FastTrack.
## Go-Live Readiness review
Closer to deployment, FastTrack (or the partner) runs a readiness review against a checklist: data migration tested, integrations validated at scale, UAT signed off, training delivered, support plan ready, cutover dry-run completed.
## FastTrack
A Microsoft program providing free advisory engagement for qualifying customers — typically large or strategic, but eligibility has broadened. FastTrack engineers attend SBRs, review designs, and connect customers to engineering when the platform itself is the blocker.
## Templates and tools
Microsoft publishes SBD templates, checklists, and reference architectures on the SBD website and the FastTrack site. They're free.
## What partners do
Mature partners blend SBD with their own engagement IP — accelerators, vertical templates, run-book scripts — but the SBD vocabulary, deliverables, and checkpoints are increasingly the industry-common ones.
## Why it works
Iterative cadence catches misalignment early. Mid-project SBR forces honest scoping conversations before commitments turn into commitments. Fit-to-standard discipline keeps total cost of ownership bounded.
## Where to go next
The methodology it replaced is [Sure Step](https://www.solvingdynamics365.com/guides/the-sure-step-methodology) and the Microsoft programme that applies it is [FastTrack](https://www.solvingdynamics365.com/guides/fasttrack-for-dynamics-365). Its key artefacts have their own guides: [fit-gap analysis](https://www.solvingdynamics365.com/guides/fit-gap-analysis-for-dynamics-365) and [cutover planning](https://www.solvingdynamics365.com/guides/cutover-planning-for-dynamics-365). Whether a partner actually practises it is a question in [choosing a Dynamics 365 partner](https://www.solvingdynamics365.com/guides/choosing-a-dynamics-365-partner).
---
# The Sure Step methodology
Microsoft's older implementation methodology for Dynamics — the phases, deliverables, and what survived in modern partner practice.
Source: https://www.solvingdynamics365.com/guides/the-sure-step-methodology
Section: Implementation / Methodology
Published: 2026-05-01
**Microsoft Dynamics Sure Step** was the formal implementation methodology Microsoft published for its Dynamics product family from the late 2000s into the mid-2010s. It is no longer actively published — superseded by **Success by Design** and **FastTrack** — but a lot of partner practice still references it, and many long-running customers' methodology documents are descended from Sure Step.
## Why Sure Step existed
Before Sure Step, every Microsoft partner had a homegrown method. Quality varied wildly. Sure Step was Microsoft's attempt to give partners a common vocabulary, common deliverables, and a common gating model — so a customer migrating partners or moving from CRM to AX got a recognisable shape.
## The phases
Sure Step organised an implementation into six phases:
1. **Diagnostic** — sales-led discovery, business needs, high-level fit-gap, proposal.
2. **Analysis** — detailed requirements, fit-gap workshop, future-state design.
3. **Design** — solution design, integration design, data migration design, technical architecture.
4. **Development** — configuration, custom development (AL/X++/JS), reports, integrations, data migration tools.
5. **Deployment** — UAT, training, cutover preparation, go-live.
6. **Operation** — hypercare, support transition.
## Project types
Sure Step recognised that not every engagement needed all six phases at full weight. It offered project type *templates* — Standard, Enterprise, Rapid, Agile, Upgrade — that tuned the depth of each phase to the scope and complexity.
## Deliverables
Each phase had a catalogue of mandatory and optional deliverables — fit-gap document, solution design document, training plan, cutover plan, etc. Many partners still use templates descended from these.
## Roles
Sure Step named roles — Engagement Manager, Solution Architect, Application Consultant, Technical Consultant, Trainer — that became the partner-staffing vocabulary.
## What worked
The phased model, role definitions, and deliverable templates raised the quality floor of Microsoft partner work. It professionalised an industry that had been ad-hoc.
## What didn't
Sure Step was waterfall by design. It assumed requirements could be specified up front and translated through a chain of deliverables. As cloud delivery and continuous updates arrived, the rigidity hurt. By 2018 it was visibly out of step with how cloud ERP/CRM implementations actually run.
## The successor
**Success by Design** replaced Sure Step in 2019 as Microsoft's published methodology — iterative, fit-to-standard, with continuous checkpoints rather than gated phases. **FastTrack** programs add Microsoft-led oversight for qualifying engagements.
## Practical advice for customers
If your partner's proposal language sounds like Sure Step — six phases, "blueprint document", "configuration document" — ask how they incorporate Success by Design's fit-to-standard and Power Platform-first thinking. The names matter less than the actual delivery shape.
---
# Time and expense in Dynamics 365 Project Operations
How Project Operations captures time and expense — entry modes, approval workflows, billable vs non-billable, expense policy enforcement.
Source: https://www.solvingdynamics365.com/guides/project-operations-time-and-expense
Section: Customer Engagement / Project Operations
Published: 2026-05-01
A services business runs on time. Every billable hour captured, every chargeable expense logged, every approval routed promptly converts into invoiced revenue. **Time and expense** in Project Operations is the operational layer that turns work into cash. The workflow has more friction than the buttons suggest; designing it well is the difference between clean monthly billing and an end-of-month scramble.
**Time entry surfaces.**
- **Web entry** — the daily or weekly timesheet in the model-driven app.
- **Mobile app** — Project Operations mobile for on-the-go entry.
- **Microsoft Teams** — embedded time entry in Teams chat or tab.
- **Outlook** — convert calendar events to time entries (with Premium).
- **API / external** — automated capture from project management tools.
The variety matters because different roles enter time differently — consultants in front of a laptop vs technicians on the road.
**Time entry record.**
- **Project** — what we're billing or charging to.
- **Project task** — finer breakdown.
- **Role / billing type** — Senior Consultant, Junior Developer (drives rate).
- **Hours** — duration.
- **Date** — when work happened.
- **External description** — visible to customer on invoice.
- **Internal description** — for project manager visibility.
- **Billable flag** — billable / non-billable / over-cap.
## Billable vs non-billable
Not all time is billable. Reasons time is non-billable:
- **Internal work** — admin, training, all-hands meetings.
- **Pre-sales activity** — work before contract.
- **Re-work** — fixing our own mistakes; can't bill the customer.
- **Over-cap** — already exceeded the fixed-price budget; remaining work non-billable.
- **Non-billable customer** — internal projects.
The split matters for utilisation reporting: billable utilisation drives the firm's profitability, non-billable utilisation is overhead.
**Approval workflow.**
1. Resource submits the weekly timesheet (or daily depending on cadence).
2. Project manager approves project time.
3. Resource manager approves total time (sanity check on full week).
4. Approved time flows to billing and revenue recognition.
Approvals can be sequential or parallel; configuration determines flow. Most organisations use sequential: PM first, RM after.
## Rejections
Approver can reject specific entries with feedback:
- Time entered on wrong project.
- Description insufficient (won't survive customer scrutiny).
- Hours implausible (16h day requires justification).
Resource adjusts and resubmits. Audit trail captures the back-and-forth.
## Delegations
When approvers are out:
- **Delegate approval** to a backup.
- **Configurable per-user out-of-office** rules.
- **Escalation** if not approved within N days.
Without delegation, monthly close stalls during PTO.
## Expense entry
Similar workflow to time but with additional structure:
- **Expense category** — meals, transport, hotel, equipment.
- **Date and amount.**
- **Currency** — multiple currencies; conversion at entry or at approval.
- **Receipt attachment** — photo or PDF.
- **Billable to customer** — pass-through or absorb.
- **Project / task allocation.**
- **Payment method** — corporate card, personal reimbursement, cash.
**Expense policy enforcement.**
- **Per-category limits** — meals capped at $50/day.
- **Per-trip caps** — total expenses for a trip ≤ $X.
- **Receipt threshold** — receipts required above $25.
- **Pre-approval** for high-value expenses (airfare > $1,000).
- **Currency-specific rules** — different limits per region.
Violations either block submission or flag for additional approval.
## Corporate card integration
For expenses on corporate cards:
- Card transactions feed from the bank.
- Resource matches transactions to expense entries.
- Reconciliation per statement period.
- Outstanding (uncategorised) card charges escalated.
Without card integration, expense entry duplicates: enter expense, separately reconcile the corporate card statement. Painful.
## Pass-through expenses
Expenses billed to the customer:
- **Time-and-material contracts** — pass-through at cost or with markup.
- **Fixed-price** — expenses usually absorbed.
- **Cost-plus** — pass through with markup percentage.
Configuration determines invoicing; expense lines on invoices need clear customer-facing descriptions.
## Resource utilisation
Time data drives utilisation reporting:
- **Billable utilisation** — billable hours / total hours.
- **Target utilisation** — what the firm targets per role.
- **Variance** — over- or under-utilised resources.
A common pattern: senior consultants targeted at 70% billable, managers at 50%. Variance drives staffing decisions.
**Integration with billing.**
- Approved time and expenses flow to project actuals.
- Billing cycle (weekly, monthly) generates invoices from project actuals.
- T&M invoices list time and expenses; fixed-price invoices reference milestone amounts.
**Common pitfalls.**
- **Late time entry.** Resources don't enter weekly; monthly catch-up is unreliable.
- **Approval bottlenecks.** PMs delay approval; billing slips.
- **Wrong project coding.** Time on project X charged to project Y; revenue and cost misallocated.
- **Receipts missing.** Expenses without receipts; can't bill customer.
- **Policy violations not enforced.** Expense limits ignored; policy becomes decorative.
- **Time entry friction.** Cumbersome UI; resources avoid; data quality degrades.
## Operational rhythm
Daily time entry by resources; weekly approval by PMs and RMs; monthly billing cycle pulls approved entries. The discipline matters — late or messy time entry pushes invoicing late, which pushes cash collection late.
## Strategic positioning
Time and expense looks operational but is strategic — it's the most direct link between hours worked and revenue collected. Mature services organisations invest heavily in low-friction time entry, fast approval, and clean data; the payback in faster cash and accurate margins is significant. Treating time and expense as a chore — something agents resist and managers neglect — eventually costs the firm material money.
---
# Time sheets in Business Central
How time sheets work in Business Central — resource time capture, project posting, approval workflow, and integration with payroll.
Source: https://www.solvingdynamics365.com/guides/time-sheets-in-business-central
Section: Business Central / Service & projects
Published: 2026-05-01
**Time sheets** in Business Central let resources (typically employees and contractors) record the hours they spend on jobs (projects), service orders, or general activities. The data feeds project billing, project profitability, resource utilisation analysis, and — through integration — payroll. For services-led businesses, time sheets are the linchpin between work done and revenue / cost recognised.
## The setup
Each **resource** in Business Central represents a person, equipment item, or generic capacity unit. Resources have unit costs (the internal hourly cost) and unit prices (the billable hourly rate, defaulted to the job line). For time sheet functionality, the resource needs:
- A **Time Sheet Owner User** — the user who fills in the time sheet (typically the resource themselves; can be a supervisor for shared admins).
- An **Approver User** — the user who approves submitted time sheets.
## The time sheet
A weekly grid (or other period configured) where the resource enters hours per day against jobs, job tasks, service orders, or generic activity types (admin, training, sick leave). Each line captures:
- **Type** — Resource (general), Job, Service Order, Assembly Order, Absence.
- **Object reference** — which job + job task, which service order, etc.
- **Description** — what was done.
- **Hours per day** — across the week.
- **Status** — Open, Submitted, Approved, Rejected.
**The flow.**
1. **Resource fills in** the time sheet during the week or at end of week.
2. **Submit** — the resource finalises and submits. Status moves to Submitted; further editing is blocked unless rejected.
3. **Approve / Reject** — the approver reviews. Approved lines move to Approved status. Rejected lines come back to the resource with comments.
4. **Posted** — approved time becomes:
- **Job ledger entries** if associated with a job, contributing cost (cost rate × hours) and billable revenue (price × hours) per the job's billable plan.
- **Service ledger entries** if associated with a service order.
- **Resource ledger entries** for general resource work.
## Integration with billing
For billable jobs, approved hours feed into the **Job Sales Invoice** generation process. Hours billed are subtracted from the available billable plan, and the invoice draft shows time entries grouped per the configured billing rule.
## Integration with payroll
Time sheet hours can feed payroll systems via Power Automate flows, the API, or a partner connector. Common patterns:
- Hours per pay period exported to the payroll provider (Visma, Hogia, Lønn360, ADP, Paylocity, etc.).
- Differentiated rates — regular, overtime, weekend, holiday — captured via line type or absence type.
- Approval status as the trigger for payroll inclusion.
## Mobile
Time sheets are usable from the Business Central mobile experience for field workers and consultants who don't sit at a desktop.
## Workflow
Built-in workflow can route time-sheet approvals to a hierarchical chain — supervisor, then project manager, then department head — with escalation on delay.
## Reporting
Standard reports cover:
- Resource utilisation — billable hours vs total hours.
- Job profitability — actual cost vs billed revenue.
- Time sheet status — open, submitted, awaiting approval.
- Absence summaries.
**Common pitfalls.**
- **No time sheet discipline** — resources fill in at the end of the month, guessing what they did. Configure weekly approval cycles and enforce them.
- **Missing approver setup** — submitted time sheets sit indefinitely. Audit the approver setup quarterly.
- **Incomplete cost rates** — postings reflect partial cost when a resource's rate is zero. Maintain rates rigorously.
## When BC's time sheets aren't enough
Heavy services-led organisations with complex resourcing, multi-stage approvals across project managers and account managers, and sophisticated billing scenarios often outgrow BC's time sheets and move to **Project Operations** for a richer model.
---
# Tracing and logging in Dataverse
How to instrument Dataverse plug-ins and flows with tracing and logging — the trace service, Application Insights integration.
Source: https://www.solvingdynamics365.com/guides/dataverse-tracing-and-logging
Section: Customer Engagement / Dataverse platform
Published: 2026-05-01
Server-side code in Dataverse — plug-ins, custom workflows, low-code plug-ins — runs in a sandboxed environment with limited debugger access in production. The compensation is **tracing** and **logging**: instrument your code so issues are diagnosable post-hoc without reproducing them in dev. Mature teams treat instrumentation as a first-class engineering concern.
## The trace service
Plug-ins receive an `ITracingService` from the execution context:
```csharp
var tracingService = serviceProvider.GetService();
tracingService.Trace("Plug-in started for entity {0}", entity.LogicalName);
```
Each Trace call writes a line; traces accumulate per plug-in execution.
**Where traces go.**
- **Plug-in trace log table** in Dataverse — visible in admin UI.
- **Available for a configurable retention period** — typically days to weeks.
- **Per-execution** — one trace log record per plug-in invocation.
For most diagnostic needs, this is sufficient.
## Application Insights integration
For deeper observability:
- Configure App Insights for the Dataverse environment.
- Traces flow to App Insights additionally.
- Rich query, alerting, dashboarding.
App Insights is the modern, recommended approach for production Dataverse.
**What to trace.**
- **Method entry/exit** — for execution flow.
- **Key decision points** — branches, conditions taken.
- **External API calls** — request and response (minus sensitive).
- **Performance markers** — operation timing.
- **Errors and exceptions** — full context.
A balanced level — neither too sparse (can't diagnose) nor too verbose (can't see signal in noise).
**What NOT to trace.**
- **Passwords, API keys, tokens.**
- **PII** — full names, emails, identifiers (without business need).
- **Credit card data** — PCI violation.
- **Health data** — HIPAA violation.
Use redaction patterns: trace `customer ID redacted`, not `customer ID 12345`.
## Structured tracing
Better than free-text:
```csharp
tracingService.Trace("OperationName: {0}, RecordId: {1}, Duration: {2}ms",
operation, recordId, duration);
```
Structured patterns enable easier parsing and querying downstream.
## Tracing in low-code plug-ins
Power Fx in low-code plug-ins:
- `Trace()` function adds traces.
- Log to standard plug-in trace.
- Same access patterns.
**Tracing in flows.**
- Each action's input/output captured automatically.
- Loop iterations tracked.
- Failures detailed.
Flow run history is the trace; no explicit Trace calls typically needed for basic flows. For complex flows, use Compose actions to log specific values.
**Performance impact.**
- Tracing has overhead — string formatting, write to memory.
- For high-volume code paths, minimise traces.
- Don't trace in tight loops; aggregate and trace once.
A plug-in tracing 100 lines per record × 10K records = 1M trace lines = slow.
## Trace levels
Not built into Dataverse directly, but pattern:
- **Error** — failure.
- **Warning** — concerning but recoverable.
- **Info** — major checkpoints.
- **Debug** — verbose flow.
Configurable levels — Production at Warning+, Sandbox at Debug.
## Application Insights query
With App Insights, you query traces in Kusto Query Language (KQL):
```kql
traces
| where customDimensions.PluginName == "MyPlugin"
| where timestamp > ago(1h)
| order by timestamp desc
```
Rich querying replaces digging through individual plug-in trace records.
## Correlation IDs
Trace correlation across systems:
- A request entering Dataverse gets a correlation ID.
- Trace lines include it.
- External calls pass the ID.
- Receiver logs include it.
End-to-end traceability across system boundaries.
## Audit vs trace
Different:
- **Audit** — business-relevant change records (who changed what when); for compliance.
- **Trace** — technical execution information; for diagnostics.
Both valuable; don't conflate.
**Sensitive data handling.**
- **Redact before tracing** — `SSN: ***-**-1234`.
- **Hash identifiers** — for correlation without exposure.
- **Avoid full row dumps** — trace specific fields.
**Common pitfalls.**
- **No tracing.** First production issue; nothing to look at.
- **Verbose tracing.** Performance hit; noise in logs.
- **Sensitive data leaked.** Compliance issue.
- **Trace formatting expensive.** Even if log not written, string formatting cost.
- **Trace ignored.** Logs exist but nobody looks; instrumentation wasted.
**Operational rhythm.**
- **Daily** — review error traces.
- **Per incident** — deep dive on relevant traces.
- **Weekly** — trace pattern analysis (top errors, slow operations).
- **Monthly** — review what's traced; adjust verbosity.
## Strategic positioning
Tracing is the cheap insurance policy of server-side code. Investment in good instrumentation pays back the first time something goes wrong in production. App Insights elevates Dataverse to enterprise-grade observability. For any production deployment of meaningful scale, instrumenting plug-ins and flows is non-negotiable engineering practice. Tracing isn't optional; it's foundational. The teams that take it seriously have boring incident reviews; the teams that don't have long, painful ones.
---
# Tracking dimensions in Dynamics 365 Supply Chain
How batch, serial, owner, and licence plate tracking work in F&O — operational impact, traceability, and the trade-offs of each.
Source: https://www.solvingdynamics365.com/guides/tracking-dimensions-in-f-and-o
Section: Finance & SCM / Supply chain & inventory
Published: 2026-05-01
Of the inventory dimensions in Dynamics 365 Supply Chain Management, **tracking dimensions** are the ones that give individual units their distinct identity. Configuring them well — batch on food and pharma, serial on high-value items, licence plate in advanced warehousing — supports the traceability and operational requirements without imposing unnecessary overhead.
## Batch tracking
A **batch** (or *lot*) groups units produced or received together — same production run, same supplier delivery, same harvest. Each batch has:
- **Batch number** — unique identifier.
- **Manufacturing date** — when produced.
- **Expiry date** — for perishable items.
- **Best-before date** — for food / pharma.
- **Batch attributes** — fat %, alcohol %, brix, pH, etc. for process industries.
- **Inventory status** — Available, Quarantined, etc.
Picking can be **FEFO** (first-expired-first-out) to prioritise oldest stock; reservations can target specific batches. Traceability reports show full history per batch — where it came from, what was made from it, where each unit went.
Used in: food, beverage, pharma, chemicals, cosmetics, building materials, paint, lubricants.
## Serial tracking
A **serial number** uniquely identifies each individual unit. Each serial has:
- **Serial number** — unique identifier.
- **Manufacturing date** — when produced.
- **Warranty start / end dates** — for service tracking.
- **Inventory status**.
Every transaction touching the unit references the serial: receipt, transfer, pick, ship, return. The result is full chain-of-custody — given any serial, you can trace exactly where it's been and what's happened to it.
Serial tracking has substantial overhead — every scan, every receipt, every pick requires the serial. Reserved for items where it justifies the cost:
- High-value items (industrial equipment, vehicles, jewellery).
- Compliance-regulated items (medical devices, aerospace components, certain electronics).
- Items with warranty obligations.
- Items where authenticity matters (luxury goods).
## Owner tracking (consignment)
**Owner** is a dimension that tracks who actually owns the inventory — useful for **consignment** scenarios where inventory is physically held but not yet sold:
- **Vendor-managed inventory (VMI)** — supplier owns the stock until you consume it.
- **Consignment to customer** — you ship stock to a customer's site but it remains yours until the customer uses it.
- **Multi-owner shared warehousing** — 3PL operations where one warehouse holds inventory for multiple owners.
Owner tracking lets the warehouse manage physical inventory while accounting recognises legal ownership correctly.
## Licence plate (LP)
A **licence plate** is a label identifying a physical unit of multiple items — a pallet, a tote, a carton, a shipping container. Operations on the LP cascade to its contents: scan one LP, move 50 items in one action.
Licence plates are essential in advanced WMS scenarios:
- Receiving where supplier consolidates many items on one pallet.
- Cross-docking where shipments transit a warehouse without put-away.
- Bulk picking where one LP holds an entire customer order.
LPs can nest — a pallet LP contains carton LPs that contain item-level LPs. Operations at any level cascade to children.
## Combining tracking dimensions
Items can have multiple tracking dimensions active simultaneously: batch + serial (medical devices in batches with each unit serialised), batch + owner (consignment of specific batches), serial + licence plate (serialised items consolidated on a pallet for shipping).
## Item tracking setup
Per item, configure:
- **Which tracking dimensions are active.**
- **Capture-required setup** — must serial be entered at receipt? At pick? At shipment? At return?
- **Auto-generation rules** — serial / batch numbers generated automatically per pattern, or required to enter manually.
**Operational implications.**
- **Receipt** — more dimensions = slower receipt. Mobile scanners help.
- **Shipping** — tracked items require scan validation at pick / pack / load.
- **Quality / quarantine** — entire batches can be quarantined and released atomically.
- **Recall** — given a problem batch, the system identifies every customer who received it.
- **Cost** — tracked-dimension granularity affects cost accounting precision.
## Operational reality
Activate tracking only where the value justifies. A consumer-goods distributor with simple SKUs doesn't need serial tracking; an industrial-equipment distributor probably does. Audit per item category.
---
# Trade allowance and rebate management in Dynamics 365 Supply Chain
How trade allowance and rebate programs work in Dynamics 365 SCM — funds, deals, accruals, claims, and the integration with sales and finance.
Source: https://www.solvingdynamics365.com/guides/trade-allowance-and-rebates-in-f-and-o
Section: Finance & SCM / Supply chain & inventory
Published: 2026-05-01
For wholesale distributors, consumer-goods manufacturers, and retailers, **trade allowances and rebates** are a large slice of the commercial relationship — supplier-funded promotions, volume rebates, retroactive discounts, marketing allowances, slotting fees. Done well, they're a strategic lever; done badly, they're an unreconciled mess that eats margin. Dynamics 365 Supply Chain Management ships a **Trade Allowance Management** module to keep them visible.
## The conceptual model
A trade-allowance program is:
- A **fund** — money the supplier is providing for a defined purpose (e.g. Q3 promotional support, volume rebate on certain SKUs).
- A **trade allowance agreement** — the rules: who's eligible (customers, customer hierarchy), what's covered (items, item categories), what's earned (% of sales, fixed amount, volume bands), and what's required to earn it (proof-of-performance, sales volume threshold).
- **Accruals** — the periodic recording of *earned but unpaid* allowance against transactions as they happen.
- **Claims** — the formal request from the customer for payment of the accrued amount, with supporting evidence.
- **Settlements** — the actual payment (or credit memo) that closes the claim.
## Funds
A **fund** holds the budgeted amount the supplier has allocated. Funds can be customer-specific, customer-group-specific, or product-specific. They have validity periods and status (open, closed). Spending is tracked against the fund, so the supplier sees committed vs available.
## Agreements
A **trade allowance agreement** binds a fund to specific customers and products with the calculation rule. Examples:
- Volume rebate: "Customer X earns 2% on sales of Item Category Y exceeding 100,000 units in Q3".
- Promotional allowance: "Customer X receives 5,000 EUR for end-cap display of Item Z in March".
- Slotting fee: "Customer X receives a one-time 25,000 EUR for new product listing".
Multiple agreements can run in parallel for the same customer.
## Accruals
As sales transactions happen, the system **accrues** the relevant trade allowance. A sale of 1,000 units of Item Y to Customer X automatically accrues 2% × revenue against the volume rebate agreement (if Customer X has earned enough). Accruals post to a **trade allowance accrual GL account** — typically a contra-revenue or expense-side balance — recognising the liability before the customer claims.
## Claims processing
When the customer claims (typically monthly or quarterly), the supplier reviews the claim against the accrued amount, validates proof-of-performance, and approves a settlement. Settlement posts a credit memo to the customer, debits the accrual account, and clears the liability.
## Integration with sales
Pricing on sales orders can reflect trade-allowance-derived discounts at posting (immediate visibility) or accrue separately for later settlement. Both patterns are supported.
## Reporting
Standard reports show:
- Funds: budgeted vs accrued vs settled vs available.
- Customer scorecards: trade-allowance earnings, ROI of promotional spend.
- Accrued liability by customer for finance reconciliation.
- Aged claims awaiting settlement.
## Limits
The standard module covers most distributor and CPG patterns. For deeply retailer-specific allowances (chargebacks, deductions, complex deal structures across many channels), customers often layer a specialist trade-promotion management (TPM) tool.
## Operational reality
The biggest trap is not adopting accruals systematically — running trade allowances as ad-hoc credit memos at quarter-end. Accrue at the transaction, and the management view is real-time.
---
# Training strategies for Dynamics 365 rollouts
Designing effective training for a Dynamics 365 implementation — formats, audiences, timing, materials, and the role of Task Recorder and Copilot.
Source: https://www.solvingdynamics365.com/guides/training-strategies-for-dynamics-365-rollouts
Section: Implementation / Project execution
Published: 2026-05-01
Training delivers the value of an implementation to the people who actually use the system. Underinvest and adoption stalls. Overinvest in the wrong format and the budget evaporates. A few principles separate the training programs that work from the ones that don't.
## Roles, not modules
Build training around what each role *does* in their day, end to end. The AR clerk's training is not "Customer module" — it's "raise an invoice, post a credit memo, send a reminder, run an ageing report, handle a dispute, reconcile". Cross-functional and integrated.
## Layered formats
A complete training program usually combines:
- **Live, role-based sessions** — the core, delivered in person or remote, with practical exercises. Two to four hours per role.
- **Train-the-trainer for champions** — go deeper, expose configuration rationale.
- **Quick reference cards** — one page per task, laminated for the desk. Fundamental for keystrokes-and-clicks workflows like point-of-sale or warehouse scanning.
- **Recorded videos** — for repeat reference and for new hires after go-live.
- **A searchable knowledge base** — internal SharePoint or Confluence, owned by the customer.
- **Floor walking** — physical or virtual presence in the first week, sitting with users.
Avoid an over-reliance on long recorded courses. They get watched once, not referenced.
## Timing
Schedule formal training **two to three weeks before go-live**. Earlier means users forget; later means there's no time to absorb. Champions get earlier exposure (during UAT).
## Realistic data
Train on **the customer's actual data**, not Cronus or Adventure Works. Customers cannot generalise from demo data; familiar item codes, customer names, and chart of accounts is what makes training stick.
## Task Recorder (F&O)
Microsoft's **Task Recorder** captures user actions in F&O as a structured step list with screenshots, replayable in the Help pane inside the application. Use it to build organisation-specific guidance that appears *in context* on the page.
## Help in BC
Business Central supports per-tenant **tooltips** and **page help** that override or supplement Microsoft's defaults. Use them for the customer's specific tweaks and policies.
## Copilot
Increasingly, Dynamics 365's embedded copilots answer "how do I" questions in natural language. Don't replace formal training, but they reduce reliance on memorised screen flow.
## Measure
Track training attendance, post-training assessment scores, and a follow-up survey two weeks after go-live. Use the data to plan refresher sessions.
## Continuing training
New hires, role changes, new features in each release wave — training is not a one-off. Schedule a quarterly cadence for the first year, dropping to ad-hoc afterwards.
## Don't outsource it entirely
Partner-led training is fine for the core curriculum; the customer's own people deliver the company-specific overlay better than any external consultant.
---
# Transportation management in Dynamics 365 SCM
How the Transportation Management module in F&O handles rates, routing, loads, freight reconciliation, and where it stops being enough for serious shippers.
Source: https://www.solvingdynamics365.com/guides/transportation-management-in-f-and-o
Section: Finance & SCM / Supply chain & inventory
Published: 2026-05-01
The **Transportation Management (TMS)** module in Dynamics 365 SCM extends order management into the freight world — rating shipments, building loads, planning routes, generating shipping documents, and reconciling freight invoices. It's a meaningful capability for mid-market shippers, with clear ceilings beyond which dedicated TMS platforms (BluJay, MercuryGate, Manhattan, Oracle TMS) start to win.
**Core entities.**
- **Carriers** — the transportation providers. Each carrier has services (LTL, FTL, parcel) and rate engines.
- **Routes** — origin-destination definitions; can include intermediate stops.
- **Loads** — the container holding shipped goods, with a carrier, a route, and load lines from one or more orders.
- **Shipments** — the warehouse-side outbound (already in WMS); loads aggregate one or more shipments.
- **Rate engines** — code that computes freight cost for a load.
- **Rate routes / Rate masters** — rate cards per carrier per route.
- **Freight bills** — what the carrier billed; reconciled against the system's rated cost.
## Rating
Two types:
- **Spot rates** — manual entry for ad-hoc shipments.
- **Contract rates** — uploaded rate cards (per weight, per mile, per pallet, per container).
Rate engine extensibility means partner ISVs add specific carrier rate APIs (FedEx, UPS, DHL) for real-time quotes. Without an API, you upload tariff sheets and the engine looks up rates.
## Load building
The **Load Planning Workbench** lets a planner consolidate open shipments into loads:
- Filter by ship-from, ship-to, carrier, equipment type.
- Assign shipments to loads based on weight, volume, route compatibility.
- Calculate utilisation (% of vehicle capacity).
- Multi-stop routing (truck visits two customers on one trip).
For high-volume operations, load building is the planner's daily task; for low-volume, it's automated by rules.
## Routing
Routes can be:
- **Direct** — origin to destination, one carrier.
- **Multi-leg** — pickup, hub consolidation, line-haul, last-mile delivery.
- **Pool point** — collected at a pool point and forwarded.
Multi-leg routing supports international shipments crossing border with brokerage steps.
## Shipping documents
TMS generates:
- **Bill of lading (BOL)** — the carrier's contract.
- **Packing list** — what's in the shipment.
- **Commercial invoice** — for international.
- **Carrier-specific labels** — UPS, FedEx, DHL labels via integration.
- **Custom documents** — country-specific export paperwork.
For parcel carriers, the workflow ends with a label printed at the pack station; for LTL/FTL, paperwork rides with the driver.
## Freight reconciliation
Carrier invoices arrive after the shipment. The reconciliation workflow:
1. Freight invoice imported (EDI, file, manual entry).
2. System matches invoice line to load and rated cost.
3. Variances flagged (rate difference, weight reweigh, accessorials).
4. Approved invoices post to AP as cost; variances post to a freight variance account or get disputed.
Done right, freight reconciliation recovers material savings; done poorly, freight overcharges sneak through.
## Hazardous goods
Items flagged as hazmat carry **hazmat group** codes. TMS enforces:
- Carrier eligibility (not all carriers handle hazmat).
- Documentation generation (hazmat declarations).
- Mode restrictions (some hazmat can't fly).
## Container management
For ocean and rail freight, **container** tracking integrates:
- Container booking against carriers.
- Stowage planning.
- Customs documentation per container.
## Integration with WMS
Once a load is planned, the warehouse pick logic respects load assignment — pickers pick to load destination, pack to load. The handover is bidirectional: WMS reports actual ship weight back, which can trigger reweigh adjustments in TMS.
**Where TMS in F&O stops being enough.**
- **Complex multi-modal optimisation** — sophisticated TMS platforms run mathematical optimisation across thousands of shipments daily; F&O's load building is rule-based.
- **Spot market integration** — real-time spot quotes across freight marketplaces; F&O doesn't natively integrate.
- **Visibility services** — Project44, FourKites integration for in-transit tracking; F&O integrates via partner connectors.
- **Yard management** — F&O has basic yard features; deep yard ops typically use a dedicated YMS.
**Common pitfalls.**
- **Rate cards out of date.** Carriers renegotiate; rate cards need to follow. A monthly rate refresh cadence avoids surprise variances.
- **Accessorials not modelled.** Detention, fuel surcharges, residential surcharges accumulate; if not in the rate engine, they appear as variances.
- **Load planning skipped.** Planners ignore load building, just dispatch each shipment individually; missed consolidation savings.
- **No freight invoice reconciliation.** Pay-on-receipt; carriers overbill systematically when they sense no scrutiny.
- **Carrier API integration cost underestimated.** Integration with FedEx, UPS, DHL is ongoing work as APIs change.
## Decision
F&O TMS is well-suited to mid-market shippers with consistent lanes and moderate carrier counts. Beyond that, a dedicated TMS connected to F&O via integration delivers more capability than trying to push F&O TMS past its design envelope.
---
# Travel time configuration in Field Service
How Dynamics 365 Field Service calculates and respects travel time — Bing Maps integration, routing constraints, and the impact on scheduling.
Source: https://www.solvingdynamics365.com/guides/travel-time-configuration-in-field-service
Section: Customer Engagement / Field Service
Published: 2026-05-01
For service organisations dispatching technicians, **travel time** is often a quarter to a third of the working day. Underestimating it causes missed appointments and angry customers; overestimating it wastes capacity. Dynamics 365 Field Service builds travel time into the scheduling and dispatch model — but the configuration controls how realistic the numbers actually are.
## Source of travel times
Field Service uses **Bing Maps** (or alternative map providers, configurable) to compute travel time between locations:
- Resource start location → first booking location.
- Booking → next booking.
- Last booking → resource end location.
Travel time is a function of:
- **Distance** (straight-line vs road network).
- **Mode** (driving, walking, public transit).
- **Time of day** — Bing Maps factors in traffic patterns.
- **Day of week** — weekday rush hour differs from weekend.
For non-real-time scheduling (planning tomorrow), historical traffic patterns are used. For real-time re-optimisation (during the day), live traffic data refines the estimate.
## Configuration
Each **resource** has:
- **Start location** — where they begin the day (typically home address; can be the depot).
- **End location** — where they end the day (often the same as start).
- **Travel mode** — Driving (default), Walking, Public Transit, Cycling.
- **Travel charges** — billable hourly cost during travel (typically reduced from on-site billing rate).
## Booking-level travel
Each booking has a separate **travel time** field showing the calculated travel from the previous booking (or start location). The schedule board displays travel as a grey block before each booking, visually showing how much of the day is on the road vs on customer site.
## Constraints
Travel-aware scheduling respects:
- **Maximum travel time per booking** — refuse to schedule a job that would require more than 90 minutes of travel.
- **Maximum daily travel** — cap the total travel across all bookings in a day.
- **Resource territory boundaries** — keep bookings within the resource's geographic area.
- **Optimisation weights** — minimise travel as a scheduling objective (see the Resource Scheduling Optimization guide).
## Cross-day travel
For multi-day projects (e.g. installation jobs spanning several days at the same customer), the system models overnight stays and morning return travel rather than calculating one massive travel time. Configure overnight policies per resource.
## Real-time updates
As the day unfolds, actual travel times diverge from planned. The mobile app captures real-time positions; the schedule board updates predicted arrival times for downstream bookings. Customers can receive **arrival window notifications** based on updated estimates.
## Travel charges
Many service organisations charge customers for travel time at a different rate from on-site work. The configuration lets travel post to a separate revenue line (or be embedded in the on-site charge). Per-customer overrides handle contracts that include or exclude travel charging.
## Alternative routing providers
For customers needing more sophisticated routing (commercial vehicle routing with weight/dimension constraints, hazmat routing, multi-stop optimisation beyond what Bing offers), integration with **commercial-vehicle-routing services** is available through partner ISVs.
**Common pitfalls.**
- **No resource start location configured** — defaults to a generic point and produces wild travel estimates.
- **Outdated location data on customers** — drives wrong travel calculations. Validate customer addresses periodically.
- **Travel as billable / non-billable confusion** — be explicit per contract whether the customer pays for travel.
- **Cross-region routing** — Bing maps quality varies by region; verify for less-mapped countries.
## Operational reality
Travel time accuracy directly drives schedule reliability. Spending the configuration time on it returns hours of dispatcher work per week and reduces customer "where's my technician" calls.
---
# Unified commerce architecture on Dynamics 365
What unified commerce actually means on Dynamics 365 — one product master, one pricing engine, one order, one customer across store, web, and call centre.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-for-retail-unified-commerce-architecture
Section: Industries / Retail
Published: 2026-09-02
"Omnichannel" meant a retailer had a store system, a web shop, and a call centre, and had built enough integration between them that a customer could mostly move across. "Unified commerce" means there is one system underneath — one product master, one pricing engine, one order object, one customer record — and the channels are front ends. The difference is not marketing; it decides whether cross-channel returns, real-time inventory, and consistent promotions are configuration or a multi-year integration programme. This guide sets out how **Dynamics 365 Commerce** delivers the unified shape, and where the edges are.
## The four things that must be single
**One product master.** Commerce products live in headquarters (the Finance and Supply Chain Management product master) with retail-specific enrichment — categories, attributes, images, variants — and are released to channels through assortments. The web shop, the POS, and the call centre read the same product. There is no catalogue sync because there is no second catalogue.
**One pricing engine.** Trade agreements, price groups, discounts, and promotions are evaluated by the same pricing engine in every channel, running on the Commerce Scale Unit. A promotion set up once applies at the till, in the basket online, and on a call-centre order, subject to channel eligibility. Microsoft has been extending this same engine toward Supply Chain Management sales orders under the *unified pricing management* feature, which is the direction of travel for B2B retailers who also sell through account managers.
**One order.** Whether it was created at a register, on the storefront, or in the call centre, the order is a headquarters sales order with an originating channel. Fulfilment, returns, and customer history operate on that object. This is the property that makes "return anywhere" and "buy online, collect in store" straightforward.
**One customer.** Customers are headquarters customer records, created asynchronously from any channel and consolidated in the global address book. Loyalty, purchase history, and preferences attach to that record.
If a proposed architecture breaks any of these four — a separate PIM that channels read from independently, a storefront with its own promotions engine, an order management layer that owns orders and syncs them down — it is integrated commerce with extra steps. Sometimes that is the right call, but it should be a conscious one.
## The runtime shape
Headquarters holds master data and finance. The **Commerce Scale Unit** (CSU) runs the channel-facing services: pricing, cart, order creation, inventory lookup, customer lookup. Every channel is a client of the CSU — the Store Commerce app, the first-party e-commerce site, the call-centre order-entry forms, and any custom client built on the Commerce SDK.
That client-of-CSU model is what makes headless commerce a first-class option rather than a workaround. A retailer can run a React storefront on Vercel, a native mobile app, and a marketplace connector, all calling the same Retail Server APIs, with cart and pricing behaving identically. The first-party storefront is the quickest path when its templating is good enough; headless is the path when brand experience or existing front-end investment matters more.
## Where Customer Insights fits
Unified commerce gives you one *transactional* customer. It does not give you the marketing view: web behaviour, email engagement, survey responses, the loyalty app. **Customer Insights – Data** stitches those sources into a unified profile with segments and measures, and **Customer Insights – Journeys** acts on them. The clean architecture is Commerce as the system of record for identity and transactions, Customer Insights as the analytical and activation layer, and a deliberate decision about which attributes flow back into Commerce for use at the till (clienteling) and which stay in the marketing stack.
The failure mode is running loyalty tiers in Commerce, segments in Customer Insights, and a promotion engine in a third-party email tool, then discovering that three systems disagree about who is a gold customer.
## Inventory across channels
Unified inventory is the piece that requires the most operational discipline. Commerce reads on-hand from headquarters and from channel databases; the **Inventory Visibility** add-in for Supply Chain Management provides the near-real-time, cross-channel picture that ship-from-store and endless aisle depend on. Without accurate store counts, unified commerce promises availability the store cannot honour. See [endless aisle](https://www.solvingdynamics365.com/guides/dynamics-365-for-retail-endless-aisle) and [click-and-collect](https://www.solvingdynamics365.com/guides/dynamics-365-for-retail-click-and-collect) for the fulfilment side.
## What still needs partners
Even on a genuinely unified platform, expect partners for payments beyond the reference Adyen connector, tax engines for complex US sales-tax estates, fiscalisation outside the countries Microsoft's framework covers, marketplace connectors, advanced search and merchandising on the storefront, and returns-management or fraud-screening specialisms. None of those break the unified shape as long as they act as services to the CSU rather than as competing systems of record.
## Business Central plus Shopify
For SMB retailers, **Business Central** with the Shopify connector and a partner POS is a good stack, but it is integrated commerce. Shopify owns the online product presentation, its own discounts, and the online order until it syncs; the POS ISV owns store transactions; BC owns inventory and finance. Cross-channel returns, consistent promotions, and unified customer history require deliberate integration work, and some of it will not be possible. That is acceptable for one to a few dozen stores with modest omnichannel ambitions. When the requirements list starts reading like the four "singles" above, the honest answer is Commerce, and the [retail overview](https://www.solvingdynamics365.com/guides/dynamics-365-for-retail) covers that trade-off.
## Decision test
Ask one question of every component in the proposed architecture: which system is the source of truth for products, prices, orders, and customers, and does this component read from it or compete with it? If the answer is "compete", either the component goes or unified commerce is not what is being built.
---
# Upgrading AL code across Business Central versions
How to keep AL extensions working through Business Central's twice-yearly release waves — breaking changes, deprecations, and code migration patterns.
Source: https://www.solvingdynamics365.com/guides/upgrading-al-code-across-bc-versions
Section: Business Central / AL & development
Published: 2026-05-01
Business Central updates twice a year, and the platform underneath an AL extension changes with each wave. Most extensions survive without intervention, but the ones that don't fail spectacularly — sometimes silently. The strategy is to test early, fix deprecations as they're announced, and never skip a wave on production code.
## What can break
Microsoft does not change its own database table fields, IDs, or method signatures lightly, but it does:
- Mark fields and methods as **obsolete** with the `[Obsolete(...)]` attribute, ahead of removing them. Obsolete code still compiles but emits warnings.
- Remove fields and methods that have been obsolete for at least two waves.
- Change the **default implementation** of a method (signature stays the same, behaviour changes).
- Add fields to standard tables — usually safe, unless your extension assumed a fixed schema.
- Change the **runtime version** required by the platform, forcing extensions to bump their `runtime` in `app.json`.
## The compatibility commitment
Microsoft documents breaking changes per wave in the *Application BreakingChanges.md* file in the BC GitHub repo. Any field, method, or behaviour deprecation goes through a published warning period before removal — extensions that act on the warnings stay safe.
**The upgrade workflow.**
1. **Six weeks before GA**, install the preview build into a sandbox.
2. **Pull the new symbols** in VS Code (`AL: Download symbols`). The compiler now sees the new platform.
3. **Build**. Warnings flag deprecated symbols; errors flag genuinely broken code.
4. **Fix and refactor** — replace obsolete APIs with current ones, adjust to behavioural changes.
5. **Run tests** (you do have an automated AL test suite; see the test framework guide).
6. **Republish** to the sandbox, then to UAT, then to production along with the platform update.
## Data upgrade codeunits
Schema-changing extensions need **upgrade codeunits** that migrate stored data when the new version installs — e.g. moving values from a removed field to a replacement. Microsoft's documentation has the boilerplate.
## Per-tenant extensions (PTEs)
PTEs are the most upgrade-fragile because Microsoft does not pre-test them. Treat every wave as a maintenance task on every PTE.
## AppSource apps
Microsoft runs your AppSource app against preview builds and notifies you if it fails. You still have to fix it, but the surface signal is automatic.
## Don't skip waves
Skipping makes the next upgrade worse, not better.
## Where to go next
The cadence you are upgrading against is [release waves](https://www.solvingdynamics365.com/guides/business-central-release-waves); the diagnostics you will read are in [AL compiler errors](https://www.solvingdynamics365.com/guides/al-compiler-errors-in-business-central). Tests that catch behavioural change are [the AL test framework](https://www.solvingdynamics365.com/guides/al-test-framework), automation is [AL-Go CI/CD](https://www.solvingdynamics365.com/guides/business-central-cicd-with-al-go), and the safety net AppSource adds is in [per-tenant extensions vs AppSource](https://www.solvingdynamics365.com/guides/per-tenant-extensions-vs-appsource).
### Frequently asked questions
**What can break an AL extension on a release wave?**
Fields and methods removed after at least two waves of obsolete warnings, changed default implementations behind unchanged signatures, new fields on standard tables that break fixed-schema assumptions, and runtime version bumps that force an app.json change.
**How do I test an extension against the next version?**
About six weeks before general availability, install the preview build in a sandbox, download the new symbols in VS Code, build and act on obsolete warnings, run the AL test suite, then republish to sandbox, UAT, and production alongside the platform update.
**Where does Microsoft publish breaking changes?**
In the Application BreakingChanges.md file in the Business Central GitHub repository. Every deprecation goes through a published warning period before removal.
**Why are per-tenant extensions the most fragile?**
Microsoft does not pre-test them, unlike AppSource apps which are run against preview builds automatically. Treat every wave as a maintenance task on every per-tenant extension, and never skip a wave.
---
# User acceptance testing for Dynamics 365
Running an effective UAT cycle on Dynamics 365 — scenarios, environment, exit criteria, and what to test that's actually worth testing.
Source: https://www.solvingdynamics365.com/guides/user-acceptance-testing-for-dynamics-365
Section: Implementation / Project execution
Published: 2026-05-01
[User Acceptance Testing (UAT)](https://www.solvingdynamics365.com/glossary/uat) is the customer's chance to validate that Dynamics 365 — configured, customised, and integrated — actually does what their business needs. Done well, UAT catches the painful gaps before go-live; done badly, it confirms what the demo already confirmed and gives false confidence.
## The point of UAT
Not to test that the software works (Microsoft and the partner already did that). To test that the **business processes**, end-to-end, in this customer's specific operational context, with this customer's data and integrations, produce the expected results.
## Scenarios over screens
Build UAT around real business scenarios, not feature lists. A scenario reads like: *"Process a customer order from quote to invoice for a customer in Sweden, with a discount, drop-shipped, paid 30 days net, intrastat-relevant."* Each scenario crosses multiple screens, modules, integrations, and roles — and is what fails when something's wrong.
## Coverage
Aim for:
- 100% of core operational scenarios (order to cash, procure to pay, period close, payroll, etc.).
- All workflow paths, including rejection and rework.
- All integration points, with both happy and unhappy paths.
- Critical reports run with real-looking data.
- Edge cases the customer's industry / region demands (e.g. country-specific tax filings).
## Environment
UAT runs in a **dedicated sandbox** copied from production-ready configuration with **realistic data volumes** and **all production integrations** connected to test endpoints. Testing against an empty demo company is theatre, not UAT.
## Real users
UAT is run by **the people who'll use the system**, not by IT and not by the partner. The salesperson tests the sales process. The AR clerk tests AR. The shop-floor lead tests production reporting. If users are too busy for UAT, they'll be too busy to use the system after go-live.
## Scripts vs exploration
A blend works best: scripted scenarios cover the must-have flows; **exploratory testing** for half a day per user catches the edges no script anticipated. Both feed the defect log.
## Defect management
A clear bug-tracker — Azure DevOps, Jira, or simple in the partner's PSA — with severity, priority, status, and owner. Triage daily. Severity 1 (showstopper) and 2 (workaround painful) must close before go-live; lower severities can ship to backlog.
## Exit criteria
Before declaring UAT complete, the business signs off:
- All scenarios executed.
- All sev 1 / sev 2 defects resolved or formally accepted.
- Performance acceptable at expected user load.
- Training material aligned with what users tested.
- Integrations operating end-to-end at scale.
## What UAT isn't
It isn't a substitute for the partner's earlier system, integration, and performance testing. By the time UAT starts, those tests should be green. UAT is the business confidence check.
## Where to go next
UAT sits between [test automation](https://www.solvingdynamics365.com/guides/test-automation-for-dynamics-365) and [cutover](https://www.solvingdynamics365.com/guides/cutover-planning-for-dynamics-365), on data prepared through [test data management](https://www.solvingdynamics365.com/guides/test-data-management-for-dynamics-365). The people side — who tests, how they are prepared — is [change management](https://www.solvingdynamics365.com/guides/change-management-for-dynamics-365) and [training strategies](https://www.solvingdynamics365.com/guides/training-strategies-for-dynamics-365-rollouts).
---
# Utilisation reporting for professional services on Dynamics 365
How to report consultant utilisation from Dynamics 365 Project Operations — the definitions finance and delivery argue about.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-for-professional-services-utilization-reporting
Section: Industries / Professional services
Published: 2026-09-02
Utilisation is the one number every professional services firm watches, and the one number no two firms define the same way. Dynamics 365 **Project Operations** captures everything needed to calculate it — approved time, bookings, resource capacity — but it does not ship a report that matches any particular firm's definition, and the built-in utilisation view uses one definition that finance may not accept. This guide is about getting to a utilisation number the partners trust. For the wider fit see [Dynamics 365 for professional services](https://www.solvingdynamics365.com/guides/dynamics-365-for-professional-services).
## Settle the definition before touching Power BI
Utilisation is hours in the numerator divided by hours in the denominator. The fights are all about which hours.
**Numerator choices.** Billable hours only (chargeable utilisation), or billable plus internal project hours such as pre-sales and R&D (productive utilisation). Most firms report both and manage to chargeable.
**Denominator choices.** Calendar working hours (every weekday, eight hours), available hours (calendar minus approved leave and public holidays), or contracted hours for part-timers. Calendar-hours utilisation is lower and punishes people for taking holiday; available-hours utilisation is what delivery managers want. Finance often wants calendar hours because it ties to cost. Pick one as the headline and publish the other as a secondary measure, but do not let two teams present two numbers as "utilisation" to the board.
**Approved versus submitted.** Time that is submitted but not approved is real work but not yet billable. Report on approved time for the headline and show the unapproved backlog as its own number; a large backlog is a management problem, not a utilisation problem.
Write these decisions down. The Power BI model implements them, and every argument about a consultant's number goes back to the document.
## Where the data lives
In Project Operations on Dataverse:
- **Time entries** hold actual hours by resource, project, task, date, and billing type, with an approval status. This is the numerator.
- **Bookable resources** carry the work-hours calendar that defines capacity, and a target utilisation percentage per resource. This is the denominator.
- **Bookings** (hard and soft) against projects and tasks are the forward-looking view — forecast utilisation, as opposed to actual.
- **Resource assignments** on project tasks are the plan; they matter for forecasting but should not feed actual utilisation.
- **Leave** is not a first-class Project Operations concept. Most firms model it as bookings against an internal "absence" project, or pull it from Dynamics 365 Human Resources or the HR system. This is the step most often skipped, and it is the reason available-hours utilisation is wrong in so many first reports.
The **resource utilisation view** on the schedule board calculates utilisation from bookings against calendar capacity, colour-coded against each resource's target. It is a good resourcing tool. It is not an actuals report, and it uses bookings, so a consultant booked at full time who logged half the hours still shows as fully utilised. Use it for forward planning; do not put it in front of finance as the utilisation number.
## Building the report
Power BI over Dataverse is the standard path — either the Dataverse connector directly, or Azure Synapse Link or Fabric for larger firms. The model needs a date table, a resource dimension with cost centre and practice from the bookable resource, a capacity fact built from the work-hours calendar (expanding the calendar into hours per day is the fiddly part), and the time-entry fact filtered to approved status.
Measures that earn their place:
- Chargeable and productive utilisation, actual, by resource, practice, and period.
- Forecast utilisation from hard bookings for the next twelve weeks, so resourcing can act before the actual number drops.
- Unapproved time backlog in hours and days-old.
- Bench: resources with forecast utilisation below a threshold in the next four weeks.
A firm that also runs Project Operations with Finance and Operations for accounting can build the same measures over the project hour transactions in F&O; the definitions are the same, the tables differ, and mixing the two sources in one model creates reconciliation work with no benefit.
## The traps
**Contractors.** Subcontracted resources appear as bookable resources of type Contact or Account and log time the same way. Including them in firm-wide utilisation flatters or distorts the number depending on how they are used. Report them separately.
**Partial approval and rejected time.** Rejected entries that are resubmitted can be double-counted if the model does not filter on the current status. Filter on status, not on the approval record.
**Overtime.** A consultant who logs ten hours against an eight-hour calendar day is at 125 percent utilisation. Decide whether to cap at capacity. Most firms do not cap the individual number but cap the aggregate reported to the board, and say so.
**Calendar drift.** Resources whose work-hours calendar was never updated after a change to part-time hours produce wrong capacity forever. Put a quarterly check of calendars against HR data into the run book.
**Projects with no billing type.** Time on a task whose project or contract line has no billing setup is neither billable nor non-billable and drops out of a naive numerator. Make it show as an exception.
## Business Central firms
Firms running projects in **Business Central** have time sheets, resource capacity, and resource ledger entries, which support a simpler utilisation calculation. The capacity setup is more basic and there is no bookings concept for forecast utilisation. A Power BI model over resource ledger entries and resource capacity entries gives actual utilisation; forecast requires a planning tool or a spreadsheet. For a firm of a few dozen consultants that is fine; for a firm that needs to see the bench four weeks out, it is the argument for Project Operations.
## Using the number
Utilisation is a lagging indicator of resourcing decisions made weeks earlier. The report is useful only if forecast utilisation from bookings is reviewed weekly by the people who assign work. A beautiful actuals dashboard reviewed monthly changes nothing.
---
# VAT and sales tax setup in Business Central
How Business Central calculates and reports VAT — VAT posting groups, EU rules, OSS, reverse charge, and country reporting.
Source: https://www.solvingdynamics365.com/guides/business-central-vat-setup
Section: Business Central / Compliance & localisation
Published: 2026-05-01
Updated: 2026-08-31
VAT and sales tax are the area of Business Central where country localizations matter most. The core engine is the same everywhere, but every country layers its own rules and reports on top.
## The posting-group model
Business Central calculates VAT by intersecting two posting groups on every transaction line: the **VAT business posting group** (who you are trading with — domestic customer, EU customer, export, reverse-charge subcontractor) and the **VAT product posting group** (what's being sold — standard goods, food, services, exempt). The intersection in the **VAT posting setup** table defines the rate, the GL accounts to post to, the calculation type (normal, reverse charge, sales tax, full VAT), and the EC reporting category.
## Setup discipline
Every customer, vendor, and G/L account default a posting group, so most postings get the right VAT without manual intervention. Mistakes typically come from new countries, new product categories, or split-purpose accounts; spend the time getting defaults right.
## EU rules
Built-in support for EU intra-community supplies, reverse-charge purchases, triangulation, and the **EC Sales List**. The **VAT Statement** report builds country-specific VAT returns line by line by combining VAT entries.
## One-Stop Shop (OSS)
For EU B2C cross-border sales, Business Central supports the **OSS** scheme, with VAT calculated at the customer's country rate and a separate OSS return posted to the supplier's home tax authority.
## Reverse charge
Both EU reverse charge and country-specific domestic reverse-charge schemes (construction services, scrap metal, mobile phones, gold) are supported through the posting setup type.
## Sales tax (US/Canada)
A separate sales-tax engine, configurable by tax area, tax jurisdiction, and tax group, handles state, county, and city tax composition. For high-volume US businesses, ISV partners deliver Avalara or Vertex integrations from AppSource.
## Country reporting
**VAT returns** (Making Tax Digital in the UK, SAF-T, real-time invoice reporting in Spain/Italy/Hungary, e-invoicing) ship per country, either from Microsoft or from a localization ISV. Always verify country coverage before committing to BC for a particular jurisdiction.
## Unrealized VAT and the VAT date
Two settings deserve a deliberate decision at implementation rather than a default. **Unrealized VAT** shifts the tax point from invoice to payment — cash-accounting schemes, and mandatory in some jurisdictions for certain flows. It changes which GL accounts VAT sits on and when it hits the return, so switching it on later is painful; decide up front with your accountant. The **VAT date** (separate from posting date and document date) determines which VAT reporting period an entry lands in. Since its introduction it has quietly become the most important date on late-arriving supplier invoices: a January invoice posted in February can carry a January VAT date and land on the right return. Decide who is allowed to backdate it and lock closed VAT periods with the VAT return period controls, or your filed return and BC will drift apart.
## Implementation discipline
The posting-group model is elegant and unforgiving: a wrong intersection posts confidently at the wrong rate, at volume, until someone notices — often the tax authority. What works in practice:
- **Keep the matrix small.** Every business and product posting group multiplies the setup table. Resist a group per edge case; most SMBs need well under ten product groups.
- **Test the matrix, not the concept.** Before go-live, post one test document through *every* combination that can occur — domestic sale, EU B2B sale, export, reverse-charge purchase, import — and have the accountant sign off the VAT entries each produces.
- **Watch data migration.** Migrated customers and vendors arrive with whatever posting groups the migration mapped, and a NAV-era mapping copied forward uncritically is a classic source of wrong-rate postings in month one. Sample-check aggressively after [data migration](https://www.solvingdynamics365.com/guides/business-central-data-migration).
- **Guard the manual override.** Users can change VAT groups on a document line. Sometimes that's legitimate (zero-rated export evidence); mostly it's a mistake. Restrict who can, and review VAT entries by group monthly — a five-minute pivot that catches most setup drift.
## When something posts wrong anyway
Don't edit your way out. Posted VAT entries are immutable by design; the fix for a wrong-rate posting is a credit memo or a correcting entry that reverses the original VAT and posts it correctly, keeping the audit trail contiguous. For systematic errors discovered late (a whole quarter at the wrong rate), involve the accountant before mass-correcting — some jurisdictions want a disclosure alongside the correction, and the mechanics differ if the return has been filed.
## Audit and corrections
Posted VAT entries are immutable; corrections post a counter-entry. The VAT register is the canonical audit trail, and the posted VAT return periods tie each entry to the return it was reported on. If you operate in multiple countries, remember that VAT correctness is a property of the **country localization**, not of the base product — verify both the rules and the digital-filing formats per jurisdiction as part of [country setup and localisation](https://www.solvingdynamics365.com/guides/country-setup-and-localisation-in-business-central) before committing.
---
# Vendor collaboration in Dynamics 365 SCM
How the Vendor Collaboration portal in F&O lets suppliers interact directly with the buyer's system — orders, ASNs, invoices, and the operational benefits.
Source: https://www.solvingdynamics365.com/guides/vendor-collaboration-in-f-and-o
Section: Finance & SCM / Supply chain & inventory
Published: 2026-05-01
For mid-to-large operations dealing with many suppliers, the cost of email-and-PDF-driven procurement is real: typos in order acknowledgments, missing shipping notices, AP departments chasing invoices, manual three-way matching. **Vendor Collaboration** in Dynamics 365 SCM gives suppliers structured, secure access to relevant parts of the buyer's system — they see their POs, acknowledge them, confirm shipments, submit invoices, and update their own contact data, all without email.
## The architecture
Vendor Collaboration runs as a **scoped Power Pages portal** sitting in front of F&O's vendor data. Suppliers sign in with their own identities (Microsoft accounts, Entra B2B, or guest accounts depending on configuration), and the portal exposes specific entities scoped to the supplier's own data only. No supplier can see any data belonging to another supplier.
**What suppliers do in the portal.**
- **View open purchase orders.** Every PO sent to the supplier appears with full line detail, pricing, quantity, delivery date.
- **Acknowledge purchase orders.** The supplier confirms (accepts, partially accepts with proposed changes, or rejects) each PO. Acknowledgments post back as workflow notifications to the buyer's purchasing team.
- **Submit advance shipping notices (ASNs).** Before goods ship, the supplier creates an ASN with shipment date, tracking number, line-level quantities. The ASN arrives in F&O as expected receipt data.
- **Submit invoices.** The supplier creates an invoice referencing the PO and shipment, with line-level detail. The invoice queues in F&O's incoming-document pipeline for approval and posting.
- **Update vendor master data.** Address, contact, bank account changes are submitted by the supplier; the buyer's vendor master administrator approves or rejects.
- **View payment status.** The supplier sees which of their invoices are approved, paid, on hold, with promised payment dates.
- **View consumption data** — for vendor-managed inventory (VMI) scenarios, the supplier sees the buyer's inventory levels and consumption to plan replenishment.
## Onboarding suppliers
Each supplier needs to be invited to the portal, granted appropriate roles, and assigned the relevant data scope. The onboarding flow can be self-service (the supplier requests access via a registration form, the buyer approves) or admin-driven (the buyer invites individually). Vendor users authenticate against their own organisation's identity provider through Entra B2B, so the supplier's IT controls their access lifecycle.
## Permission scoping
A supplier user's roles control what they can see and do:
- **Read-only view** of orders and invoices.
- **Active responder** for acknowledgments and ASNs.
- **Self-service editor** for their own profile.
Different users at the same supplier can have different roles — a customer-service rep handles acknowledgments; an AP-side counterpart handles invoicing.
## The buyer-side workflow
Inside F&O:
- Supplier acknowledgments appear in the purchasing buyer's workspace for review.
- Submitted ASNs queue for receipt processing in the warehouse.
- Submitted invoices flow into the vendor-invoice approval workflow.
- Master-data change requests route to the vendor-master administrator.
**Benefits.**
- **Reduced AP friction** — invoices arrive as structured data, not PDFs requiring data entry.
- **Improved on-time receiving** — ASNs tell the warehouse exactly what's arriving.
- **Faster cycle time** — supplier responses are minutes, not days of email back-and-forth.
- **Better master data** — suppliers maintain their own contact and banking data.
- **Audit trail** — every interaction logged.
**Limits.**
- **Supplier adoption** — small suppliers may resist portal use; need a fallback for paper / email.
- **Setup overhead per supplier** — onboarding each supplier is real work; only worth it for suppliers with meaningful volume.
- **EDI overlap** — large suppliers may already use EDI; the portal duplicates effort.
## Operational reality
Vendor Collaboration pays off when most procurement volume flows through portal-enabled suppliers. Pilot with the top 20% of suppliers (by spend or volume) first; expand from there.
---
# Vendor performance tracking for public sector on Dynamics 365
How public bodies track supplier performance on Dynamics 365 Finance and Supply Chain Management — delivery and quality data from receipts and quality orders.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-for-public-sector-vendor-performance
Section: Industries / Public sector
Published: 2026-09-02
Public bodies are required to buy fairly, and increasingly required to show that the suppliers they keep buying from actually perform. Contract management regimes, audit offices, and value-for-money reviews all ask the same questions: did the vendor deliver on time, was the quality right, were the invoices accurate, and was the framework used as intended? Dynamics 365 Finance and Supply Chain Management captures the transactional evidence for all four as a by-product of normal purchasing. It does not ship a vendor scorecard. This guide covers where the evidence lives, how to turn it into a score, and the process rules that apply when the score has consequences. For the competition side, see [procurement transparency](https://www.solvingdynamics365.com/guides/dynamics-365-for-public-sector-procurement-transparency).
## The evidence is already there
Most vendor-performance programmes fail by starting with a survey. Start with the transactions.
**Delivery performance.** Every purchase order line has a requested date, a confirmed date from the vendor's acknowledgement (through vendor collaboration or keyed by the buyer), and an actual receipt date from the product receipt. On-time is actual against confirmed; in-full is received quantity against ordered. Both are queries over the purchase line and receipt tables, and the only setup decision is which date counts as the promise — insist on confirmed dates, or the measure is against the buyer's wish rather than the vendor's commitment.
**Quality.** Where goods are inspected, quality orders at receipt record pass or fail per test, and nonconformances record what was wrong and what was done. Vendor-related nonconformances by vendor and period are the quality measure; the [quality management](https://www.solvingdynamics365.com/guides/quality-management-in-f-and-o) guide covers the setup. For services, quality is a rating on the purchase order line or on a case, which brings the evaluation criteria below into play.
**Invoice accuracy.** Invoice matching produces price variances and quantity variances per invoice; the share of a vendor's invoices that match first time and the value of variances are the accuracy measure. Vendors that consistently invoice above the agreed price are found here, not in a survey.
**Agreement compliance.** Purchase agreements record committed prices and quantities; releases against them show whether the vendor honoured the framework price and whether the organisation used the framework rather than buying off-contract. Off-contract spend by category is as much a measure of the buyers as of the vendor.
**Responsiveness.** Time from RFQ issue to reply, and from order to acknowledgement, both timestamped when vendor collaboration is used.
## Adding judgement: vendor evaluation criteria
Supply Chain Management includes **vendor evaluation criteria**: named criteria grouped and assigned to procurement categories, against which users rate vendors after purchases. The ratings aggregate to a vendor's score per category and are visible on the vendor and in the RFQ comparison. It is a lightweight mechanism — a small set of criteria, a star scale, comments — and that is its virtue. Use it for the things transactions cannot measure: communication, problem resolution, professionalism on site.
Two rules make it defensible in a public body: ratings are entered against a specific purchase or contract, not free-floating, and the raters are the people who received the goods or service, not procurement. A rating without a transaction behind it is an opinion, and opinions are what a supplier challenge will attack.
## Certifications and compliance
Public bodies must confirm vendors hold required certifications — insurance, safety, data protection, professional accreditation — and that they remain current. **Vendor certifications** on the vendor record hold the certification type, number, and expiry, with alerts as expiry approaches; the [alerts and notifications](https://www.solvingdynamics365.com/guides/alerts-and-notifications-in-f-and-o) guide describes the alert mechanism. Policy can prevent orders to vendors whose mandatory certification has lapsed, either by putting the vendor on hold or through a workflow check. Debarment and exclusion lists maintained by governments are external; checking them is a step in vendor onboarding and periodic review, typically a Power Automate flow calling the list's service where one exists, and a manual check where it does not.
## The scorecard
With the evidence in place, the scorecard is a Power BI model over purchase lines, receipts, quality orders, invoice matching, agreements, evaluation ratings, and certifications, keyed on vendor and procurement category. Weight the measures per category — delivery matters more for goods, ratings more for services — and publish a score per vendor per quarter. The [Power BI for Dynamics 365](https://www.solvingdynamics365.com/guides/power-bi-for-dynamics-365) guide covers the data path; Synapse Link or the data lake export is the right source for this volume. Keep the weighting simple and documented, because the vendor will ask for it.
Consider also giving vendors sight of their own score through vendor collaboration or a Power Pages page. Supplier-relationship programmes that share the score get fewer challenges and better performance than ones that spring it at contract review.
## Consequences, and the process around them
This is where public sector differs from private. A private company can quietly stop buying from a vendor. A public body that excludes a vendor from a framework, declines to renew, or scores it down in a competition on the basis of past performance must follow a fair process: the vendor must have known the criteria, been told of poor performance, and had the chance to improve. The system supports this with the vendor hold status and its reason codes, the documented ratings and their dates, and correspondence stored against the vendor — but the process is the contract manager's, and the score should feed a conversation before it feeds a decision.
Using past performance in a new competition is regulated in most jurisdictions and permitted only where announced in the procurement documents. The RFQ scoring criteria can include it; whether they may is a legal question to settle before the criteria are published.
## Business Central bodies
Business Central records receipts, invoice variances, and vendor blocked status, and has no evaluation criteria or certification tracking. Smaller public bodies build the delivery and invoice-accuracy measures in Power BI from BC's purchase and receipt data, hold certifications as attributes or a small custom table with expiry, and record service ratings in a Dataverse or SharePoint list. That is enough for a body with a few hundred vendors; it is the argument for Supply Chain Management for one with thousands.
## Start small
Delivery on-time and invoice first-time-match for the top fifty vendors by spend, reviewed quarterly with the contract managers. Add quality and ratings once those two numbers are trusted. Vendor-performance programmes that launch with a twelve-measure scorecard and a survey to every supplier produce a report nobody reads and a set of scores nobody will defend.
---
# Vendor selection for Dynamics 365 implementations
How to select an implementation partner for Dynamics 365 — RFP process, evaluation criteria, demo and reference checks.
Source: https://www.solvingdynamics365.com/guides/vendor-selection-for-dynamics-365
Section: Implementation / Vendor & contracting
Published: 2026-05-01
Choosing the right implementation partner is one of the highest-leverage decisions in any Dynamics 365 program. The partner affects timeline, quality, cost, and long-term success more than most other early decisions. A structured selection process produces better outcomes than gut-feel choices.
## Partner ecosystem realities
Microsoft has thousands of certified partners; they differ wildly:
- **Specialised boutiques** — deep in a specific module or industry.
- **National / regional consultancies** — broader capability, local presence.
- **Global SIs** — Accenture, Deloitte, KPMG, etc. — for complex, multi-country.
- **Industry specialists** — vertical expertise.
Match partner profile to project profile.
**RFP / RFQ process.**
1. **Define scope** — what you need.
2. **Identify candidate partners** — 4-8 typically.
3. **Issue RFP** with structured questions.
4. **Receive proposals.**
5. **Evaluate.**
6. **Shortlist** to 2-3.
7. **Deep dive** — meetings, demos, references.
8. **Decision.**
The structured process produces comparable inputs.
**Evaluation criteria.**
- **Technical capability** — Dynamics 365 expertise depth.
- **Industry knowledge** — your vertical.
- **Methodology** — implementation approach.
- **Team** — who actually delivers.
- **References** — recent, relevant.
- **Commercial terms** — pricing model, contracts.
- **Cultural fit** — work style alignment.
- **Local presence** — for face-to-face needs.
Weighted scoring across these makes evaluation transparent.
**Common RFP questions.**
- Recent similar implementations (last 12 months).
- Specific modules expertise.
- Industry vertical experience.
- Proposed team — named individuals.
- Methodology documents.
- Risk management approach.
- Quality assurance practices.
- Change management approach.
- Support post-go-live.
- Pricing model — fixed, time and materials, hybrid.
**Red flags.**
- **Generic responses** — same words for every project.
- **Inflated team size** — many B-team members.
- **Unrealistic timelines** — promising what can't be delivered.
- **Lowball pricing** — change orders coming.
- **Recent partnerships only** — Microsoft listing but no real depth.
- **No references** in your industry / scale.
- **Pressure to commit fast.**
Each warrants further investigation.
## Reference checks
Critical step often rushed:
- **Recent customers** — last 12-24 months.
- **Similar profile** to yours — size, industry, complexity.
- **Mix of perspectives** — IT, business, executive.
Questions for references:
- What went well?
- What didn't?
- Would you choose them again?
- How was post-go-live support?
- Cost vs budget?
- Timeline vs commitment?
- How did they handle conflict?
**Demo evaluations.**
- **Don't just see slides** — see actual Dynamics work.
- **Test scenarios specific to your needs.**
- **Watch how they handle gaps** — "we don't have an exact example" honesty matters.
- **Note who presents** — same people who'll deliver?
**Pricing models.**
- **Fixed price** — partner takes risk; clear budget; less flexible.
- **Time and materials** — flexible; budget risk on you.
- **Hybrid** — fixed for defined scope, T&M for unknowns.
- **Outcome-based** — pay for results; rare in implementation.
Each fits different project profiles. Fixed for well-understood scope; T&M for exploration.
## Statement of Work (SOW)
The contract:
- Scope definitions.
- Deliverables.
- Timeline.
- Cost.
- Acceptance criteria.
- Change management process.
- Risk and assumptions.
Vague SOWs lead to scope creep and dispute; specific SOWs hold both sides accountable.
## Multi-partner deployments
Sometimes:
- **Prime + sub-partners** — prime contractor coordinates.
- **Independent multi-partners** — direct relationships.
- **In-house + partner** — split execution.
Adds coordination complexity but may be right for specialised needs.
**Microsoft involvement.**
- **Microsoft FastTrack** — for large customers, Microsoft engineers support.
- **Account team** — Microsoft account managers know partners' specialisations.
- **Microsoft can recommend** partners but won't pick.
Engage Microsoft early for guidance.
**Common pitfalls.**
- **Cheapest wins.** Pricing wars hide quality differences.
- **Brand-name only.** Big consultancy doesn't mean right team.
- **No reference rigor.** Quick calls miss real signal.
- **Scope vague at signing.** Both sides interpret differently; conflict.
- **Single decision-maker.** Should involve IT, business, executive.
**Decision-making.**
- Scorecard from RFP.
- Reference feedback.
- Demo observations.
- Cultural fit assessment.
- Final discussion among stakeholders.
Document the rationale; choosing partner is a major commitment.
**Post-selection.**
- **Kick-off** — set expectations.
- **Joint planning** — milestones, deliverables.
- **Governance structure** — steering committee.
- **Performance metrics** — track against agreement.
## Strategic positioning
The partner choice shapes the project. Spending more time in selection pays back in delivery. Common mistake: rushing the selection to start implementation faster — usually adds time and cost.
For decision-makers:
- Run a structured process.
- Weight expertise over price.
- Verify references rigorously.
- Test cultural fit.
- Commit only after thorough evaluation.
The investment is days; the impact is the project's success or struggle. Done well, the partner becomes an extension of your team; done poorly, the partner becomes a source of friction and missed expectations.
---
# Virtual network data gateway for Dynamics 365
How the virtual network (VNet) data gateway enables Dynamics 365 and Power Platform to access data in private Azure VNets — architecture, configuration.
Source: https://www.solvingdynamics365.com/guides/virtual-network-data-gateway-for-dynamics-365
Section: Integrations / Azure services
Published: 2026-05-01
Dynamics 365 and Power Platform often need to reach data sitting in private networks — Azure SQL Databases with private endpoints only, on-prem databases via ExpressRoute, services behind firewalls. Traditionally, this required the **on-premises data gateway** — a Windows service installed in the customer environment. The **virtual network data gateway** is a managed alternative: fully Microsoft-hosted, deployed into the customer's Azure virtual network, no Windows server to maintain.
**The on-premises gateway recap.**
- A Windows service installed in customer infrastructure.
- Polls Microsoft cloud for work.
- Bridges Power Platform / Dynamics requests to private data.
- Customer-managed — patching, scaling, monitoring.
- Available for over a decade; mature; widely used.
**The virtual network data gateway.**
- **Managed by Microsoft** — no Windows server to install or patch.
- **Deployed into customer's Azure virtual network** — a subnet hosts the gateway.
- **Accesses resources inside the VNet** — Azure SQL with private endpoint, Azure Function, etc.
- **Connects to Microsoft cloud** through standard mechanisms.
The headline benefit: customer's data stays inside their VNet; Microsoft's compute reaches in temporarily to fetch what's needed.
**Architecture.**
```
Power Platform / Dynamics 365
|
v
Microsoft cloud (gateway service)
|
v
Customer Azure VNet
subnet for gateway
|
v
Customer private resources
```
The gateway is provisioned in the customer's VNet but operated by Microsoft. The customer controls the VNet, the NSG rules, the resources it accesses; Microsoft operates the gateway runtime.
**Configuration.**
1. Customer Azure subscription has a VNet with appropriate routing.
2. A subnet is dedicated for the gateway.
3. Subnet is delegated to `Microsoft.PowerPlatform/vnetaccesslinks`.
4. In Power Platform admin, the gateway is created referencing the VNet/subnet.
5. Data sources in the VNet are added to the gateway's connections.
6. Power Apps, flows, and Power BI reports use the gateway to reach the private resources.
The setup is mostly Azure VNet plumbing plus a Power Platform reference.
**Use cases.**
- **Azure SQL with private endpoint** — public access disabled; gateway reaches via private endpoint.
- **Azure Function with VNet integration** — internal logic accessible to Power Automate.
- **Private Azure Storage** — files in storage accounts without public access.
- **Azure Cosmos DB private** — private endpoints.
- **Custom Azure-hosted APIs** — internal services accessible only inside VNet.
- **On-prem via ExpressRoute** — if VNet is connected to on-prem via ExpressRoute, gateway reaches on-prem resources too.
**Comparison with on-premises gateway.**
| Aspect | On-prem gateway | VNet gateway |
|---|---|---|
| Hosting | Customer Windows server | Microsoft managed |
| Patching | Customer | Microsoft |
| Scaling | Manual / replica | Auto |
| HA | Cluster of installs | Built-in |
| Data path | Through customer infrastructure | Through Azure |
| Use case | On-prem databases | Azure VNet resources |
VNet gateway is the modern path for Azure-resident private resources; on-prem gateway remains for true on-prem data.
**Authentication and authorisation.**
- **Power Platform / Dynamics user** authenticates to Power Platform.
- **Gateway** authenticates to data source (SQL credentials, managed identity, OAuth).
- **Identity flow** depends on connector — some support pass-through, some require fixed credentials.
For SQL access, the cleanest pattern is managed identity for the gateway connecting to SQL.
**Performance.**
- **Throughput** — comparable to direct connections.
- **Latency** — slight added latency from cross-region or VNet routing.
- **Connection pooling** — gateway maintains connection pools.
For high-volume queries, gateway performance is reasonable; bulk data movement still benefits from ADF or other dedicated tools.
**Networking specifics.**
- **NSG rules** — control what the gateway subnet can reach.
- **Private endpoints** — point to specific resources without public routing.
- **DNS** — Azure Private DNS Zones for name resolution.
- **Service endpoints** — for some Azure services if needed.
VNet design matters; misconfigured networking gives confusing errors.
**Monitoring.**
- **Connection health** — visible in Power Platform admin.
- **Query metrics** — request counts, latency.
- **Errors** — connection failures logged.
The managed gateway has better observability than the on-prem alternative; Azure-native logs.
**Common pitfalls.**
- **NSG too restrictive.** Gateway can't reach target; cryptic errors.
- **Wrong subnet delegation.** Subnet not delegated to Power Platform service; gateway provisioning fails.
- **Private endpoint DNS broken.** Gateway resolves to public IP, doesn't find resource; private DNS zones needed.
- **No high availability planning.** Single gateway; outage affects all dependent flows.
- **Connection limits.** Many flows hitting the same gateway; throttling.
- **Cost surprise.** VNet gateway has hourly cost; budget.
## Cost
VNet gateway is paid per gateway hour:
- Reasonable for moderate usage.
- Multiple gateways multiply cost.
- Compare to on-prem gateway (free, but Windows server cost).
For Azure-resident workloads, VNet gateway often wins on TCO once Windows server admin is included in on-prem gateway cost.
**Migration from on-prem gateway.**
- Add VNet gateway alongside.
- Reconfigure connections to use VNet gateway.
- Validate flows still work.
- Decommission on-prem gateway.
Migration is gradual; both can coexist during transition.
## Strategic positioning
The VNet data gateway is Microsoft's path forward for Power Platform / Dynamics 365 private network access. For new deployments where data sits in Azure VNets, it's the default. For existing on-prem gateway deployments, evaluate moving to VNet gateway as Azure infrastructure modernises.
The benefit isn't transformative — connections work either way — but operational simplicity (no Windows servers, no patching, no clustering) compounds over time. For modern, Azure-centric data architectures, the VNet gateway removes a longstanding piece of customer-managed infrastructure. Worth adopting for new work; worth migrating to gradually for existing.
---
# Virtual tables in Dataverse
How Dataverse virtual tables expose external data as if it were native — providers, OData connectors, refresh patterns.
Source: https://www.solvingdynamics365.com/guides/dataverse-virtual-tables
Section: Customer Engagement / Dataverse platform
Published: 2026-05-01
Sometimes data should not be copied into Dataverse — it lives authoritatively in another system, replicating it would create sync headaches, and consumers just need read access. **Virtual tables** solve this by making external data appear as Dataverse tables without storing the rows. To a model-driven app or a Power Automate flow, a virtual table looks like any other; underneath, every query is routed to the external source.
**What virtual tables provide.**
- A Dataverse table shape (columns, datatypes, primary key).
- No row storage in Dataverse.
- Read and (optionally) write operations forwarded to an external system in real time.
- Native participation in model-driven app forms, views, and Power Automate triggers (in some cases).
**What they don't provide.**
- High-performance large dataset queries (every query is a remote call).
- Full Dataverse features (auditing, change tracking, calculated columns, traditional plugins).
- Reliability if the external source is slow or unavailable.
## The virtual provider model
A virtual table needs a **virtual data provider** — a connector that translates Dataverse queries into requests the external source can answer. Three common providers:
- **OData virtual provider** — out-of-the-box for OData-compliant sources (SharePoint lists, OData-published systems, F&O entities).
- **Cosmos DB / SQL providers** — bridge to specific data stores.
- **Custom virtual providers** — built in C# implementing `IVirtualEntityDataSource`, registered as plugins.
Custom providers give the most flexibility — any backend with an API can become a virtual table by writing the provider.
## Creating a virtual table
In the maker portal:
1. Tables → New table → Virtual.
2. Choose the data source (configured virtual provider).
3. Select the external entity to surface.
4. Map external fields to Dataverse columns; set the primary key.
5. Save and publish.
The table now appears in views, forms, and flows alongside native tables.
## Query forwarding
When a user queries the virtual table:
- Dataverse parses the FetchXML / OData query.
- The virtual provider translates it to the external system's query language.
- The external system returns results.
- Dataverse marshals them back as if they came from internal storage.
Latency is the external system's response time plus the marshaling overhead. For sub-second external systems, the experience feels native. For slow systems, it doesn't.
## Read vs read-write
Virtual tables are most often **read-only**:
- Display data without copy.
- Simplify model-driven app integration.
- Avoid sync logic.
**Read-write** virtual tables exist when the external system supports updates and the provider is built to handle them. CRUD operations route to the external system, but with caveats around transactionality and error handling — if a Power Automate flow updates the virtual table and the external system rejects, the flow sees an error but has no native rollback semantics.
**Use cases.**
- **F&O data in a Power Apps front end** — surface customer balances from F&O without copying.
- **Reference data from a master data hub** — countries, currencies, product catalogue maintained elsewhere.
- **External system inventory or pricing** — read in Power Apps; user sees current data, system of record stays external.
- **Compliance / audit data** — query without bringing data under Dataverse's residency boundary.
**Limitations to know.**
- **Performance under load** — every query is a network call; high-traffic scenarios hit the external system directly.
- **No traditional plugins/workflows** — fewer extension points.
- **Limited offline support** — model-driven mobile offline doesn't replicate virtual tables.
- **Auditing limited** — Dataverse audit tracks calls but not external-side changes.
- **Search limitations** — Dataverse search (the global search bar) often doesn't index virtual tables fully.
## Comparison to Power Automate "fetch on demand"
Some scenarios that look like virtual table candidates are better served by a Power Automate flow that fetches data on demand and displays in a canvas app — simpler to build, no provider development.
## Comparison to dataflow replication
When data is high-volume, read-heavy, and tolerates some latency, replicating to a real Dataverse table via dataflow can outperform a virtual table at scale.
**Common pitfalls.**
- **Virtual table for high-traffic master data.** Every view load fans out to the external system; the external system becomes a bottleneck for the whole app.
- **No caching layer.** A custom provider that hits the external API every query without caching is expensive.
- **Schema drift.** External system changes a field; virtual table fails to load until the mapping is updated.
- **Auth complexity.** The provider needs auth to the external system; managing service principals or OAuth flows reliably is real work.
- **Treating virtual tables as if they were standard.** Expectations of plugins, audit, advanced queries don't apply.
## Decision framework
Use virtual tables when:
- Data must remain authoritative externally.
- Volume per query is small and per-row latency tolerable.
- Replication would create sync complexity or compliance issues.
Use replicated standard tables when:
- Data volume is moderate and reads are frequent.
- Power Apps responsiveness matters.
- Full Dataverse features (workflows, plugins, audit) are needed.
The two approaches are complementary; many environments use both — virtual tables for some scenarios, replicated tables for others.
---
# Warehouse mobile workflows in Dynamics 365 Supply Chain
How handheld warehouse workflows work in Dynamics 365 SCM — configurable mobile workflows, scanning, license plates, and where they fit operationally.
Source: https://www.solvingdynamics365.com/guides/warehouse-mobile-workflows-in-f-and-o
Section: Finance & SCM / Supply chain & inventory
Published: 2026-05-01
The advanced **Warehouse Management** module in Dynamics 365 Supply Chain Management is one of the standout features that justifies stepping up from Business Central. At its heart is a **configurable mobile workflow engine** that drives handheld scanner devices on the warehouse floor — purpose-built for performance, glove-friendly use, and customisable without code.
## The model
A **mobile workflow** is a sequence of steps a warehouse worker performs through their handheld device — scan a license plate, scan an item, confirm a quantity, scan a destination location, complete the move. Each step is defined in the workflow designer with prompts, validation, and conditional branching. Workflows live in F&O's setup; they're solution-package-portable like other configuration.
## Pre-built workflow types
Microsoft ships configurations for the standard warehouse operations:
- **Receipt** — inbound from purchase orders, transfer orders, return shipments.
- **Put-away** — directed put-away to bins.
- **Pick** — pick for outbound shipments, transfers, production consumption.
- **Pack** — packing into outbound containers.
- **Load** — loading onto outbound shipments.
- **Counting** — cycle counting and full physical inventory.
- **Movement** — moving stock between bins.
- **Production** — material picking for production orders, finished-goods reporting.
- **Quality** — quality inspection sampling and disposition.
Each pre-built workflow can be cloned and customised — change the prompts, skip optional steps, add validation rules, branch on conditions.
## License plates
A **license plate (LP)** is a label representing a logical unit of inventory — a pallet, a tote, a carton. License plates are the unit of movement: scan one license plate to move many items at once. License plates can be nested (a pallet LP contains many carton LPs each containing many items). Operations on the LP propagate to its contents.
## The handheld experience
The mobile interface is deliberately minimal — large buttons, short prompts, scannable barcodes. Workers operate at speed without paging through menus. Each step's UI is generated from the workflow definition, with text and barcode-input emphasis.
## Hardware
F&O's mobile experience runs on Windows-based industrial PDAs, Android devices via the **Warehouse Management mobile app** (the modern, recommended option), iOS devices, and forklift-mounted vehicle terminals. Bluetooth and Bluetooth+WiFi scanners pair with the device. Voice-pick devices integrate through partner add-ons.
## Wave processing
Outbound order flow runs through **waves**: groups of orders released together for picking. Wave templates define the bundling logic (orders by route, by carrier, by priority). When a wave releases, the system computes pick plans, generates LP shipments, and queues pick work for handhelds.
## Slotting and replenishment
Bin replenishment (moving stock from bulk to pick bins) is automated based on min/max thresholds, demand profiles, or scheduled jobs. Slotting (the assignment of items to optimal pick bin locations) can run on an ABC-velocity basis or through advanced WMS optimisation modules.
## Why this matters
A well-configured advanced WMS in F&O can run a complex distribution warehouse with hundreds of operators, multiple shifts, and thousands of orders per day at the kind of throughput that lower-tier WMS systems struggle with. The trade-off is real: implementation is substantial, and the workflow design demands warehouse-domain expertise.
## Beyond the standard
Customers with very specific WMS needs (mezzanines with pick-to-light, dynamic slotting based on real-time analytics, robotic AS/RS integration) extend through partner ISVs or via the open APIs.
---
# Warehouse pick and put-away in Business Central
How Business Central's warehouse module organises inbound put-away and outbound picking — the three warehouse modes, directed put-away and pick.
Source: https://www.solvingdynamics365.com/guides/warehouse-pick-and-put-away-in-bc
Section: Business Central / Inventory & warehouse
Published: 2026-05-01
Business Central can run anything from a one-bin back room to a multi-zone advanced warehouse with directed put-away and pick. The configuration lives at the **Location** level: each location has a **Warehouse** profile that dictates which documents and which warehouse activities apply. Understanding the three modes and what each one enables is the foundation of warehouse design in BC.
**The three location modes.**
- **No warehouse activities.** Inventory moves with the source document (purchase receipt, sales shipment, transfer). No separate warehouse paper. Suitable for tiny operations with one bin and one person.
- **Basic warehousing.** Inventory put-away and inventory pick documents are introduced — a separate warehouse activity per source document. Bin codes are tracked. Still one warehouse activity per source.
- **Advanced warehousing.** Warehouse receipts and warehouse shipments aggregate multiple source documents. Put-away worksheets and pick worksheets break the work into optimised tasks. Directed put-away and pick (with zones, bin types, and put-away templates) becomes available.
The location card flags `Require Receive`, `Require Put-away`, `Require Shipment`, `Require Pick`, and `Bin Mandatory` to encode which features apply.
**Inbound: receive → put-away.**
In advanced warehousing:
1. Vendor truck arrives. Warehouse operator opens or creates a **Warehouse Receipt** for the location.
2. Operator pulls in lines from open purchase orders or transfer orders that have arrived.
3. The receipt posts when goods are physically received at the dock. This creates `Posted Whse. Receipt` and inbound `Warehouse Entry` records, but inventory isn't yet at its bin.
4. A **Put-away Worksheet** breaks the receipt into put-away tasks; the system suggests bins using the **Put-away Template** on the item or default rules.
5. Warehouse operator works the **Warehouse Put-away** document, scanning items into bins. Posting the put-away moves the inventory from the receive zone to its destination bins.
**Outbound: shipment → pick.**
1. Sales order or transfer is released. The location requires a shipment, so the order doesn't ship directly.
2. Operator creates a **Warehouse Shipment** and pulls in lines from open released orders.
3. A **Pick Worksheet** consolidates pick work; the system suggests bins to pick from using **Pick Template** logic, prioritising FEFO if configured.
4. Warehouse operator executes the **Warehouse Pick**, moving items from bins to the ship zone.
5. The shipment posts; inventory leaves the warehouse, the source order's `Qty. Shipped` updates, and inventory ledger entries are written.
Basic warehousing skips the worksheet step — pick and put-away are created directly from the source document, one warehouse activity per order.
## Bins and bin types
A **Bin** is a physical location in the warehouse. **Bin Types** (`Receive`, `Ship`, `Pick`, `Put-away`, `QC`) define what flows can use the bin. A bin can be multiple types simultaneously (e.g. both `Pick` and `Put-away`). The default bin for an item determines where the system suggests putting new stock without explicit instruction.
## Zones
Zones group bins for logical traversal (Receiving, Bulk Storage, Pick Face, Shipping). Zone-aware put-away templates implement strategies like "put bulk to bulk storage, but if the pick face is below minimum, replenish there first."
## Replenishment
Once bulk and pick-face bins are separated, **Movement Worksheets** generate internal moves to replenish pick faces from bulk. This is a small but important workflow — without it, pickers run out at the pick face while bulk stock sits.
## Mobile and barcoded operations
Out-of-the-box BC has a basic web app suitable for tablet use, but most serious warehouses run a third-party **Warehouse Mobile** extension or AppSource app (Insight Works, Tasklet, Warehouse Insight) for scanner-driven picking. The data model underneath is the same — warehouse entries, warehouse activities — but the UI is optimised for barcode scanning.
**Common pitfalls.**
- **Choosing advanced when basic suffices.** Advanced warehousing has more configuration and more steps. Don't pick it if you have one bin per location.
- **Bin mandatory turned off.** Without bin mandatory, the bin codes become advisory; the system happily ships from a non-existent bin. For accurate stock, bin mandatory should be on.
- **No replenishment process.** Picks fail at the pick face because bulk wasn't moved. Movement worksheets must run, often automated by job queue.
- **Manual put-away.** Skipping the put-away template means operators choose bins themselves — slower, less consistent, harder to optimise.
## When to outgrow BC's warehouse
For most mid-market 3PL or wholesale operations, BC advanced warehousing plus a mobile add-on is sufficient. The migration to D365 Supply Chain Management's warehouse module typically happens when you outgrow BC's single-tenant scale (>1M warehouse entries per month) or need features BC lacks: wave planning at scale, complex labour standards, advanced shipping cartonisation, deep TMS integration.
---
# Webhooks in Business Central
How webhook subscriptions work in Business Central — subscribing, renewing, payloads, and the realities of consuming change notifications.
Source: https://www.solvingdynamics365.com/guides/webhooks-in-business-central
Section: Integrations / Eventing & messaging
Published: 2026-05-01
Business Central can push change notifications to external systems via **webhook subscriptions**, so consumers don't need to poll. It's the recommended way to integrate when external systems need to react to BC changes promptly. The mechanics are simple; the operational discipline is what catches people out.
## The model
An external system registers a **subscription** with BC, declaring:
- The **resource** to watch — a v2.0 API entity set, e.g. `companies({id})/customers` or a specific table via a custom API.
- The **change types** — `created, updated, deleted`.
- The **notification URL** — where BC will POST notifications.
- The **client state** — a token the subscriber chooses, returned in notifications for verification.
BC validates the URL during subscription creation by POSTing a validation token; the URL must return it within seconds, exactly as received. This is how BC verifies the subscriber owns the URL.
## Notifications
When a watched resource changes, BC POSTs a notification (or batch of notifications) to the URL. The payload contains **resource URLs** and change type but **not** the changed data itself — the subscriber must GET the resource to see what changed.
This indirection is deliberate: it keeps notifications small, lets the subscriber filter by re-checking permissions, and avoids stale data over slow subscribers.
## Retry and durability
BC retries failed deliveries for a limited window with exponential backoff. After repeated failures, the subscription is deactivated and the subscriber must re-create it. **There is no message replay** — if your endpoint is down past the retry window, those notifications are lost. Build for reliability.
## Subscription expiry
Subscriptions auto-expire (typically after 3 days). Consumers must **renew** before expiry by extending the subscription. Renew at half the lifetime to handle clock skew and downtime.
## Authentication
Notifications are POSTed *as Business Central* to the subscriber's URL — no auth header is added by BC. The subscriber authenticates the call by checking that the **client state** matches the value it gave at subscription time. Treat client state like a shared secret.
## Throttling
A tenant has a finite number of active webhook subscriptions and a cap on notification rate. High-change tables (item ledger, GL entry) generate many notifications; subscribe to higher-level entities (sales orders, posted invoices) where possible.
## Scale pattern
Don't subscribe directly from a single endpoint to a high-volume entity. Use a webhook → Service Bus or Storage Queue → worker pattern: the webhook handler quickly enqueues the notification and returns 200; a worker processes it asynchronously with retries. This decouples the subscriber's processing time from BC's expectation of a fast 200 response.
## When to use
Real-time integration of moderate volume — sync a sales order to a shipping service the moment it's released. For bulk or batch needs, use the API directly with `If-Modified-Since` or change-tracking semantics.
---
# Webhooks vs events in Dataverse
How Dataverse exposes change notifications — webhooks, service endpoints to Azure Service Bus / Event Hub / Event Grid.
Source: https://www.solvingdynamics365.com/guides/webhooks-vs-events-in-dataverse
Section: Integrations / Eventing & messaging
Published: 2026-05-01
When something happens in Dataverse — a record created, updated, or deleted — external systems often need to react. Dataverse provides multiple mechanisms to publish these events: plug-in step → webhook, plug-in step → service endpoint (Service Bus, Event Hub, Event Grid). Each has different reliability, scale, and operational characteristics.
## The plug-in step pattern
All event publication originates from the same place: a plug-in step registered against a table event. The step's destination determines the mechanism:
- **In-process plug-in** — runs in Dataverse, mutates the row or related rows.
- **Webhook** — Dataverse POSTs to an external HTTPS endpoint.
- **Service endpoint** — Dataverse publishes to Azure Service Bus, Event Hub, or Event Grid.
Each is configured via the Plug-in Registration Tool or solution-aware code, with similar registration metadata.
**Webhooks.**
- Dataverse calls an HTTPS URL with the event payload.
- Endpoint receives, returns 200 (or fails).
- Synchronous delivery — Dataverse waits for the response before continuing (with timeout).
- Retries on failure (limited retries; eventually gives up).
- Authentication via shared key or no auth (with caution).
Best for:
- Custom logic running in Azure Functions, Logic Apps, or your own services.
- Quick integration without infrastructure.
- Scenarios where occasional event loss is tolerable.
Limitations:
- **Reliability** — receiver failures lead to dropped events after retry exhaustion.
- **Scale** — Dataverse blocks while waiting for response; slow receivers impact source.
- **Ordering** — no strict ordering guaranteed.
**Azure Service Bus.**
- Dataverse publishes to a Service Bus queue or topic.
- Decoupled — events buffered for subscribers.
- Strong reliability — guaranteed delivery to receivers.
- Subscribers process at their own pace.
- Higher infrastructure cost; needs Service Bus namespace.
Best for:
- High-reliability integrations.
- Heavy downstream processing.
- Multiple consumers of the same event.
**Azure Event Hub.**
- High-throughput event ingestion.
- Optimised for many events per second.
- Used with telemetry-style scenarios.
Best for:
- Very high-volume event streams.
- Analytics ingestion.
- Event sourcing patterns.
**Azure Event Grid.**
- Event routing with topic/subscription model.
- Multiple subscribers per event.
- Native integration with many Azure services.
- Generally lower cost for moderate volumes than Service Bus.
Best for:
- Pub/sub patterns with multiple receivers.
- Routing events to various Azure services.
- Cross-product Azure-centric integrations.
**Comparison table.**
| Aspect | Webhook | Service Bus | Event Hub | Event Grid |
|---|---|---|---|---|
| Coupling | Tight | Loose | Loose | Loose |
| Reliability | OK | High | High | High |
| Volume | Low-mid | Mid-high | Very high | Mid-high |
| Setup complexity | Low | Mid | Mid | Mid |
| Cost | None | Per msg | Per ingestion | Per operation |
| Use case | Simple webhook | Critical integration | Telemetry | Pub/sub routing |
**Synchronous vs asynchronous.**
- **Synchronous (Pre/Post-op stage)** — plug-in fires inline with the Dataverse operation; user waits.
- **Asynchronous (Post-op + async)** — fires after commit, queued, executed by Dataverse's async job processor.
For external publication, asynchronous is almost always right — sync webhooks block the user's experience.
## Payload format
The payload varies:
- **Native Dataverse format** — `ExecutionContext` serialised.
- **CloudEvents** — when configured for Event Grid in CloudEvents schema mode.
CloudEvents is the modern, interoperable format; preferred for new integrations.
**Authentication.**
- **Webhook** — shared key (header value), or HTTP Basic.
- **Service Bus** — connection string (SAS key) with policy.
- **Event Hub / Event Grid** — similar SAS-based auth.
Service principal-based auth is preferred over shared keys; setup is more complex but more secure.
## Filtering at source
Reduce noise by only publishing events that matter:
- **Filtering attributes** — only fire when specific columns change.
- **Conditional execution** — plug-in checks before publishing.
Source-side filtering reduces downstream volume.
**Replay and dead-letter handling.**
- **Service Bus** — dead-letter queue for failed messages; messages can be inspected and re-processed.
- **Event Hub** — events persist for configurable retention; consumers can replay.
- **Event Grid** — dead-letter to storage; advanced retry policy.
- **Webhook** — no dead-letter; permanent loss after retries.
For critical integrations, never use webhooks alone — the lack of dead-letter handling is operationally risky.
## Idempotency
Receivers should be idempotent — handle the same event twice without bad side effects. All event mechanisms have at-least-once delivery; duplicates happen.
**Monitoring.**
- **Plug-in execution failures** — visible in Dataverse async job logs.
- **Service Bus metrics** — message counts, dead-letter counts.
- **Webhook failures** — show in Dataverse but not retrievable beyond a window.
Service Bus and Event Grid provide much richer observability than webhooks alone.
**Common pitfalls.**
- **Webhook for critical events.** Receiver failure = event lost; downstream system out of sync. Use Service Bus or Event Grid for reliability.
- **No idempotency at receiver.** Duplicate events cause duplicate side effects.
- **Source-side filtering missing.** All updates published; downstream system overwhelmed.
- **Authentication via shared keys.** Keys leak in code or logs; security incident.
- **No dead-letter handling.** Failed events disappear; integration silently incomplete.
- **Synchronous webhook with slow receiver.** Dataverse operations slow for users; blame the system.
## Strategic positioning
Choose the mechanism per integration's needs:
- **Internal Power Platform integrations** — Power Automate flows triggered by Dataverse events, no Service Bus needed.
- **Lightweight external** — webhook to Azure Function.
- **Critical external** — Service Bus or Event Grid.
- **Very high-volume telemetry** — Event Hub.
The cost of choosing wrong: brittle integrations. The cost of choosing right: infrastructure investment that pays back in reliability. Most production integrations should use Service Bus or Event Grid; webhooks are for prototypes and low-stakes scenarios.
## Where to go next
Deeper on each destination: [Service Bus integration](https://www.solvingdynamics365.com/guides/azure-service-bus-integration-with-dataverse), [Event Grid with Dataverse](https://www.solvingdynamics365.com/guides/event-grid-with-dataverse), and the reliability pattern that makes any of them safe, [the outbox pattern](https://www.solvingdynamics365.com/guides/the-outbox-pattern-with-service-bus). Receivers need [idempotency](https://www.solvingdynamics365.com/guides/idempotency-in-dynamics-365-integrations); the step that publishes is a plug-in, whose failure modes are in [plug-in exceptions explained](https://www.solvingdynamics365.com/guides/dataverse-plugin-exceptions-explained).
### Frequently asked questions
**What are the options for publishing Dataverse events externally?**
A plug-in step registered on a table event whose destination is a webhook (HTTPS POST) or a service endpoint to Azure Service Bus, Event Hub, or Event Grid. All are configured through the Plug-in Registration Tool with similar metadata.
**Why not use webhooks for critical integrations?**
Webhooks have limited retries and no dead-letter queue, so a failing receiver eventually means a permanently lost event. Service Bus and Event Grid buffer, guarantee delivery, and dead-letter failures for inspection and replay.
**Should the publishing step be synchronous or asynchronous?**
Asynchronous, almost always. A synchronous webhook makes the user wait for the external receiver, and a slow receiver makes Dataverse feel slow.
**Do receivers need to be idempotent?**
Yes. Every mechanism delivers at least once, so duplicates happen. Receivers must handle the same event twice without duplicate side effects.
**Which Azure service fits which scenario?**
Service Bus for critical integrations with heavy downstream processing; Event Grid for pub/sub routing to multiple Azure subscribers at moderate volume; Event Hub for very high-volume telemetry-style streams.
---
# What is Business Central?
A practical introduction to Microsoft Dynamics 365 Business Central — the SaaS ERP for small and mid-sized businesses.
Source: https://www.solvingdynamics365.com/guides/what-is-business-central
Section: Business Central / Overview
Published: 2026-05-01
Updated: 2026-08-27
Microsoft Dynamics 365 Business Central is a cloud-first ERP designed for small and mid-sized businesses — typically organisations between roughly five and several hundred users that need accounting, inventory, sales, purchasing, and basic operations in one connected system. It is the modern, SaaS-delivered successor to **Dynamics NAV** (and to Navision before that), and it inherits the same posting engine, dimensional accounting, and journal-and-document data model that made NAV popular for over two decades.
## Where Business Central came from
Business Central's lineage runs back to **Navision Financials**, a Danish product first released in the mid-1990s and acquired by Microsoft in 2002. Under Microsoft it became **Dynamics NAV**, and in 2018 the SaaS version was rebranded and re-platformed as Business Central. The upgrade is not just cosmetic: the AL programming language replaced C/AL, extensions replaced code customisations, and the client moved fully to a browser-based web experience. But the underlying data model — the same general ledger, the same item and customer cards, the same posting routines — is recognisable to anyone who worked with NAV in the 2010s.
That continuity matters. It means the deep functional knowledge accumulated across a global partner ecosystem transferred forward. It also means Business Central has 25+ years of localisation work behind it: statutory VAT and payroll handling, chart-of-accounts templates, e-invoicing formats, and country-specific reports for dozens of jurisdictions ship in the box.
## What it actually does
Functionally, Business Central covers the full financial core — general ledger, accounts payable and receivable, bank reconciliation, fixed assets, intercompany postings, and country-specific VAT and sales tax — plus inventory and warehouse management, sales and purchase order processing, light manufacturing, jobs and project accounting, and service management. It ships with role-tailored workspaces, deep Excel and Outlook integration, and built-in Power BI reports.
The **Essentials** SKU covers finance, sales, purchasing, inventory, projects, and service. The **Premium** SKU adds manufacturing (production BOMs, routings, capacity planning) and service management (service orders and contracts). Most implementations run on Essentials; Premium is warranted when the business actually assembles or manufactures goods rather than only trading them.
Copilot inside Business Central assists with bank reconciliation, sales line suggestions, marketing text generation, and chart explanations. These are targeted features, not a general chat surface — they sit inside the pages where the work happens.
## Who it's for
Business Central is aimed squarely at the mid-market. A single-country retailer with 20 users, a wholesaler with 80 users across three warehouses, a professional-services firm with 150 consultants — all fit the profile. So do subsidiaries of larger groups that want a lightweight ERP for a small country while the parent runs SAP or Dynamics 365 Finance and Supply Chain Management centrally.
Below the entry point, businesses often stay on QuickBooks, Xero, Fortnox, or Visma until they hit either a complexity ceiling (inventory across multiple locations, jobs, foreign-currency reporting) or a compliance one (statutory audit, group consolidation). Above it, once a business runs at scale across many legal entities with heavy manufacturing and warehouse workloads, migration to Dynamics 365 Finance and Supply Chain Management is the typical next step.
The line is not sharp. Business Central handles up to a few hundred concurrent users comfortably and supports multi-entity groups through **intercompany postings** and **consolidation**. A 500-user business is not automatically too big for it — the deciding factor is usually the shape of the operations, not the headcount.
## Extensibility and updates
What makes Business Central distinctive among mid-market ERPs is its extensibility model. Partners and customers extend the product through **AL extensions** distributed via **AppSource**, which means upgrades are non-breaking and the base application stays clean. Extensions can add pages, fields, tables, and business logic without touching the underlying object model, and they can subscribe to events raised by the base app or by each other.
Microsoft ships two minor updates per year — commonly called **Wave 1** (April) and **Wave 2** (October) — plus monthly hotfixes and cumulative updates. Tenants are automatically updated, with a configurable update window and the ability to schedule the major version bumps up to a few weeks. The **release plans** are published months in advance, so functional consultants and partners can prepare.
For customers moving from NAV, this cadence is the biggest cultural change. On-premise NAV upgrades were multi-year projects. On Business Central Online, the platform upgrades itself every month, and the customer's job is to keep extensions healthy through the upgrade cycle. That shifts the partner relationship from "big-bang project once every five years" to a steady flow of small changes.
## Licensing
Business Central is sold as **Essentials** or **Premium** per named user, with a lower-cost **Team Member** license for read-and-light-write roles (approvers, viewers, time entry), and an **External Accountant** license for the company's accountant. A tenant chooses either Essentials or Premium for its Full Users — you cannot mix. Team Members can sit on top of either.
There are also **Device** licenses for shared shop-floor terminals and **Attach** licenses for scenarios where users need multiple Dynamics 365 apps but only pay the base price once. Full pricing is published in the [Dynamics 365 licensing guide](https://go.microsoft.com/fwlink/?LinkId=866544) and is refreshed roughly annually.
## Implementation and partners
Business Central is almost always implemented by a Microsoft partner over a project of two to six months, though very small deployments can be self-served or delivered in weeks. The partner ecosystem is deep: several thousand firms globally, with strong regional coverage in the Nordics, DACH, Benelux, the UK, and Australia — a direct legacy of the NAV heritage.
Business Central also runs on-premise, but the vast majority of new implementations are SaaS (Business Central Online), which is hosted on Azure in Microsoft data centres. On-premise remains supported and continues to receive updates, and there is a genuine use case for it — sovereignty requirements, industry-specific integration constraints — but the platform is clearly designed cloud-first.
For a typical mid-market implementation, expect: a fit-gap workshop, a base configuration, a data migration from the legacy system, one or two Wave-aligned rounds of extensions for the gaps that remain, integration to bank and payroll, key-user training, and go-live. Steady-state after go-live is a small ongoing partner relationship for the semi-annual waves plus ad-hoc change requests.
## Where to go next
Next reads: [Business Central licensing and pricing](https://www.solvingdynamics365.com/guides/business-central-licensing-and-pricing) with current list prices on the [pricing page](https://www.solvingdynamics365.com/pricing/business-central), then the [finance module](https://www.solvingdynamics365.com/guides/business-central-finance-module) and [dimensions design](https://www.solvingdynamics365.com/guides/business-central-dimensions-design), which shape every report you will run. [Business Central environments](https://www.solvingdynamics365.com/guides/business-central-environments) covers the operational model. If you are weighing it against the enterprise tier, read [Business Central vs Finance and Operations](https://www.solvingdynamics365.com/guides/business-central-vs-finance-and-operations); if you are coming from NAV, [Business Central vs Dynamics NAV](https://www.solvingdynamics365.com/guides/business-central-vs-dynamics-nav).
### Frequently asked questions
**Who is Business Central for?**
Small and mid-sized businesses — typically companies that have outgrown entry-level accounting but do not need an enterprise ERP. It covers finance, sales, purchasing, inventory, warehousing, projects, and light manufacturing.
**What is the difference between Essentials and Premium?**
Essentials is the standard full-user license. Premium adds manufacturing and service management. A tenant cannot mix the two — all full users are either Essentials or Premium — so one department needing service management forces everyone up to Premium.
**How often is Business Central updated?**
Microsoft ships two major updates per year, in April and October, plus monthly hotfixes. Online tenants update automatically within a configurable window, and AL extensions are designed to survive upgrades without breaking.
**What happened to Dynamics NAV?**
Business Central is the evolution of Dynamics NAV. The biggest cultural change for NAV customers moving to Business Central Online is the update model: instead of a multi-year upgrade project every few versions, the platform updates itself continuously and the job becomes keeping extensions healthy.
---
# What is Dynamics 365 Customer Service?
Microsoft's case management and omnichannel customer support platform — what it does, how it scales, and where Copilot fits.
Source: https://www.solvingdynamics365.com/guides/what-is-dynamics-365-customer-service
Section: Customer Engagement / Customer Service
Published: 2026-05-01
Updated: 2026-08-27
Dynamics 365 Customer Service is Microsoft's case management and omnichannel support platform. It runs the customer-facing operations of contact centres, service desks, B2B support teams, and inbound enquiry handling across industries — everywhere a customer's problem needs to be tracked, routed to the right person, resolved against a service commitment, and reported on afterwards.
## Where it fits
Customer Service is one of the CRM-lineage Dynamics 365 apps, sharing Dataverse with Sales, Field Service, Marketing, and Customer Insights. That shared platform is the primary reason a Microsoft-shop CIO picks it: a case opened by a support agent references the same Account and Contact records the sales team owns, the same product catalog, and the same customer history. When the case escalates into a field visit, Field Service picks up the same record without integration.
In the market, Customer Service competes primarily with Salesforce Service Cloud, ServiceNow Customer Service Management, and Zendesk. It wins when the customer already runs Microsoft 365 and Teams heavily, when there is a Dynamics 365 ERP or Sales deployment upstream, or when the Copilot integration matters more than best-of-breed contact-centre depth.
## The case lifecycle
The core object is a **case** — a single unit of customer trouble — created from email, chat, voice, web form, social, or a customer portal. Cases have a **status reason** (In Progress, On Hold, Waiting for Customer, Resolved), a **priority**, an **SLA**, an owning **queue** or agent, parent/child relationships for related cases, and a configurable resolution process backed by a business process flow.
**Routing rules** assign incoming cases to queues based on attributes — product line, customer tier, keyword match, language. **Unified routing** layers AI on top: cases are classified with a machine-learning model trained on the tenant's own history, then matched to an agent whose skills and availability best fit. The classical "queue assign" and the modern "unified routing" coexist — a large support estate typically uses both, with routing rules as the gate and unified routing as the assignment.
## Omnichannel
Customer Service ships with a unified agent desktop and channel integrations for **voice** (built on Azure Communication Services), **live chat**, **SMS**, **email**, **WhatsApp**, **Facebook Messenger**, **Apple Messages for Business**, **Microsoft Teams**, and a self-service **web widget** embedded on any site.
Agents handle multiple sessions at once with a smart productivity pane — one active conversation in the main pane, up to a configurable number of parked sessions in the sidebar, plus knowledge search, macros, and Copilot suggestions overlaid on top. Supervisors get a live view of queue load, agent occupancy, and channel health from an operations dashboard.
Voice is the newest and most sophisticated channel: it uses ACS under the hood for the call transport, provides IVR flows built with the same low-code designer, and produces a real-time transcript that Copilot can summarise mid-call.
## Knowledge management
A built-in **knowledge base** supports authored articles with version control, translations (multi-language publishing), scheduled publishing, and separate internal / external visibility. Articles surface contextually inside the case form — the system recommends articles based on case attributes — and on the customer portal for self-service.
Federated knowledge search across external systems (SharePoint, ServiceNow, custom sources) uses **Copilot Studio** connectors so agents can search one place and hit multiple back ends.
## SLAs and entitlements
**SLAs** track first-response and resolution targets per channel and priority, with warning thresholds, escalations, and business-calendar awareness (support hours, holidays, timezone). Multiple KPI clocks can run on one case — response time separately from resolution time separately from time-in-status.
**Entitlements** track contract balances — cases remaining, hours remaining, terms per product — per customer and channel. When a case is created, the applicable entitlement is stamped on it automatically, decremented on close, and the entitlement's SLA is applied.
## Copilot
AI features include real-time **case summary** (the case's history condensed for an agent picking it up mid-flight), **email draft replies** in the agent's tone, **conversation summary** at end of chat that writes back to the case timeline, **knowledge search** in natural language, and **agent assist** suggesting next-best replies as the conversation happens.
Supervisors get **sentiment monitoring** across all live conversations, **conversation intelligence** across calls and chats with keyword tracking, and Copilot-generated summaries of team performance for the daily standup.
Copilot for Service is separately licensed as an add-on to Customer Service Enterprise. It is also sold as a standalone that connects to Salesforce Service Cloud, so a customer running Salesforce today can pilot the Copilot experience without moving off it.
## Self-service and bots
**Copilot Studio** agents (previously "Power Virtual Agents") deflect cases from human agents by answering routine questions, taking simple actions like resetting a password or checking an order status, and handing off cleanly to a human when the conversation exceeds their capability — carrying the transcript, the identified topic, and any collected variables into the case that gets created.
Customer portals built with **Power Pages** give customers a place to log and track cases, browse the knowledge base, and manage their entitlements. A portal is not required — many organisations run Customer Service purely through inbound channels — but it is common for B2B support where customers want visibility.
## Reporting
Out-of-the-box dashboards cover case volume, resolution times, agent productivity, and SLA performance. **Customer Service Analytics** ships as a Power BI app with deeper reports — trend analysis, customer effort scores, backlog aging. **Omnichannel Insights** does the same for the omnichannel channels — conversation-level analytics rather than case-level.
Custom dashboards are built with Power BI against Dataverse directly. The data is well-structured and documented, and the shared Dataverse means dashboards can join Customer Service data with Sales pipeline or Field Service work orders without ETL.
## Licensing
Sold per user in **Professional** and **Enterprise** tiers.
**Professional** is a light SKU limited to case management and one channel — usable for a small internal support desk, rarely right for a customer-facing contact centre. **Enterprise** is the working baseline: full case management, multiple channels, SLAs, entitlements, and full customisation.
Add-ons on top of Enterprise cover the paid channels: **Voice** (per user, adds the ACS-powered voice channel), **Digital Messaging** (chat, SMS, social), **Chat** (chat only, subset of Digital Messaging), and **Customer Service Insights**. Copilot for Service is a separate add-on.
Attach licensing lets users who already hold another Dynamics 365 app add Customer Service at a reduced base price — useful for sales-plus-service deployments where the same seats work both apps.
## Where to go next
The service-commitment machinery is in [SLA management](https://www.solvingdynamics365.com/guides/sla-management-in-customer-service) and [entitlements](https://www.solvingdynamics365.com/guides/entitlements-in-customer-service); assignment in [routing rules](https://www.solvingdynamics365.com/guides/customer-service-routing-rules); telephony in [omnichannel voice](https://www.solvingdynamics365.com/guides/omnichannel-voice-in-customer-service). For the competitive picture, [Customer Service vs Zendesk](https://www.solvingdynamics365.com/guides/dynamics-365-customer-service-vs-zendesk) and [vs ServiceNow](https://www.solvingdynamics365.com/guides/dynamics-365-customer-service-vs-servicenow). List prices and the channel add-in bill are on the [Customer Service pricing page](https://www.solvingdynamics365.com/pricing/customer-service).
### Frequently asked questions
**What is the difference between routing rules and unified routing?**
Routing rules assign cases to queues on attributes such as product line, customer tier, or language. Unified routing adds machine-learning classification and skills- and availability-based assignment to a specific agent. Large support estates use both: rules as the gate, unified routing as the assignment.
**Which channels does Dynamics 365 Customer Service support?**
Voice built on Azure Communication Services, live chat, SMS, email, WhatsApp, Facebook Messenger, Apple Messages for Business, Microsoft Teams, and an embeddable web widget. Voice, digital messaging, and chat are paid add-ons on top of the Enterprise licence.
**Is Customer Service Professional enough for a contact centre?**
Rarely. Professional is limited to case management and a single channel and suits a small internal support desk. A customer-facing contact centre needs Enterprise for multiple channels, SLAs, entitlements, and full customisation.
**How do SLAs and entitlements work together?**
An entitlement records a customer's contract balance — cases or hours remaining, per product and channel. When a case is created the matching entitlement is stamped on it and its SLA applied; the SLA then runs response and resolution clocks with warning thresholds, escalations, and business-calendar awareness.
**Who does Dynamics 365 Customer Service compete with?**
Salesforce Service Cloud, ServiceNow Customer Service Management, and Zendesk. It wins when the organisation runs Microsoft 365 and Teams heavily, has Dynamics 365 Sales or an ERP upstream, or values Copilot integration over best-of-breed contact-centre depth.
---
# What is Dynamics 365 Field Service?
Microsoft's field service management app — work orders, scheduling, mobile, connected assets, and the operations model behind a modern service business.
Source: https://www.solvingdynamics365.com/guides/what-is-dynamics-365-field-service
Section: Customer Engagement / Field Service
Published: 2026-05-01
Updated: 2026-08-27
Dynamics 365 Field Service is Microsoft's application for organisations that send technicians or engineers to a customer site to perform work. Typical customers are equipment manufacturers running maintenance contracts, facilities-management firms, utilities, telecoms, medical-device service teams, and home-service businesses — anywhere a work order, a person, a vehicle, and an asset at a customer location have to line up in time and space.
## Where it fits
Field Service is one of the CRM-lineage Dynamics 365 apps, running on the same Dataverse as Sales, Customer Service, Marketing, and Customer Insights. The shared platform matters because the field service business rarely stands alone: a case opened in Customer Service becomes a work order in Field Service, an asset installed by Sales gets serviced by Field Service, and the technician's arrival photo lands on the same customer timeline as the sales conversation.
In the market, Field Service competes primarily with **ServiceNow Field Service Management**, **Salesforce Field Service**, **IFS Field Service Management**, and specialised products like **ServiceMax** (for equipment manufacturers). It wins on integration into Microsoft 365 and Dynamics 365, on the maturity of its scheduling engine, and on the fact that IoT-connected scenarios (Azure IoT feeding work orders) are a first-class capability rather than a partner add-on.
## Work orders
The central object is the **work order**, generated from a case, a phone-logged incident, a preventive maintenance schedule, an IoT alert, or a customer portal request. It carries the customer, the asset being worked on, the location (with geocoded coordinates), the products and services required, the estimated time, the skills needed, priority, SLA, and a status lifecycle that runs Scheduled → Travelling → On Site → Complete → Posted.
Work orders can be simple (one visit, one technician) or complex (multi-day, multi-technician, with dependencies between tasks). **Requirement groups** model the "one person to unload the equipment plus two more to install it plus a certified electrician to sign it off" scenario without contorting the data model.
An **incident type** template configures the standard work: the tasks, the parts, the skills, and the estimated duration for a "boiler service" or a "meter replacement". Work orders created from an incident type inherit all of it and can be tuned per booking.
## Scheduling
A configurable **schedule board** lets dispatchers drag work orders onto technicians. Filters, colour codes, capacity views, and heat maps make the day's plan legible; conflict detection prevents double-booking.
The **schedule assistant** finds available slots for a single work order against skills, working hours, travel time, and stock — the answer to "when could Emma fit this in this week". It's used both by dispatchers picking up ad-hoc bookings and by self-service portals letting customers pick their own slot.
**Resource Scheduling Optimization (RSO)** is the optional engine that plans the whole day for the whole fleet — an NP-hard combinatorial problem of routes, skills, time windows, SLA priorities, and travel time. RSO can be run on demand, on a schedule, or continuously; it typically lifts productive time on a fleet by 5–15% over hand-scheduling. It carries its own licence.
## Mobile app
Technicians work from a first-class **mobile app** that runs on iOS and Android, online and offline. Offline is the key word: field crews spend a serious portion of the day in low- or no-coverage zones, and an app that only works online is not usable.
The app carries the day's bookings, navigation to each site, customer history, asset records including previous work orders on that asset, knowledge articles, parts inventory on the truck, and the forms to record time on and off, parts used, photos of the work, customer signatures, and inspection results. Custom forms are built with the same Power Apps designer used for the model-driven Dataverse apps.
**Location tracking** on the mobile app feeds real-time arrival estimates back to dispatch and to the customer. **Vehicle information** (odometer, fuel) can be recorded per visit for fleet compliance.
## Connected assets and IoT
A hierarchical **customer asset** model tracks equipment installed at customer sites — parent asset, sub-components, serial numbers, warranty status, maintenance history, technical specs. Warranty and contract entitlements attach to the asset, so the right terms apply to any work on it.
**IoT integration** through Azure IoT or Connected Field Service lets devices raise alerts that automatically generate work orders — the "the boiler is going to fail" scenario. Anomaly detection on the device data can decide whether to dispatch a technician, order a spare part in advance, or attempt a remote reset first. When a remote fix works, the incident closes without a truck roll — the highest-margin outcome in field service.
**Copilot in Field Service** summarises the work order for a technician on arrival, drafts the completion notes from the technician's spoken summary, and finds relevant knowledge articles inside the mobile app.
## Inventory and parts
Truck-stock inventory is tracked per resource. Parts consumed on a job decrement the truck's stock and trigger replenishment against warehouse master data. Non-stock parts are ordered to the customer site or the local depot with lead-time visibility.
For manufacturers, **serialised parts** and **batch tracking** carry through, so warranty claims and recall notices tie back to the specific unit installed at a specific site.
Integration to Business Central or Dynamics 365 Supply Chain Management makes the warehouse master data the source of truth; Field Service becomes the consumption layer.
## Customer experience
Customers receive arrival windows, real-time technician tracking (an ETA that updates as the technician moves), and post-job surveys (via Customer Voice or an external tool). A self-service portal built with **Power Pages** lets customers log requests, see the status of open work, and pick appointment slots.
**SLA management** tracks response and resolution commitments per customer or asset. Missed SLAs escalate through configurable rules; kept SLAs feed the customer's account manager for renewal conversations.
## Contract and billing
**Agreements** model recurring service — a monthly boiler check, a quarterly compliance inspection — and generate work orders on the agreed cadence with the agreed pricing. The agreement carries the SLA, the included parts, and the labour rates.
Billable work rolls up to invoice: labour hours, parts consumed, and travel per the agreement terms. Billing flows out to Business Central, Dynamics 365 Finance, or a third-party ERP through standard integrations. For services businesses running Project Operations alongside Field Service, project accounting picks up the profitability roll-up.
## Licensing
Sold per user. Two main SKUs plus a specialised one:
**Field Service** — the standard licence for technicians, dispatchers, and admins. Covers all functionality on the desktop and mobile app.
**Field Service Contractor** — a lower-cost licence for third-party contractors who need mobile access to receive and complete work orders but no dispatch or admin capability.
**Frontline Worker** — a device-based option for high-volume technician fleets where per-user pricing doesn't fit the economics.
**Resource Scheduling Optimization** carries a separate add-on licence. Copilot for Field Service is licensed as part of Field Service Enterprise or as an add-on.
Attach licensing lets users who already hold another Dynamics 365 app add Field Service at a reduced base price — common in equipment-manufacturer deployments where the same seats run Sales and Field Service.
## Where to go next
Follow a job through [the work order lifecycle](https://www.solvingdynamics365.com/guides/work-order-lifecycle-in-field-service), plan a fleet with [Resource Scheduling Optimization](https://www.solvingdynamics365.com/guides/resource-scheduling-optimization), and equip technicians with [the Field Service mobile app](https://www.solvingdynamics365.com/guides/field-service-mobile-app). [Connected Field Service and IoT](https://www.solvingdynamics365.com/guides/connected-field-service-and-iot) covers the device-triggered scenarios. If you are unsure whether this or Project Operations is the right app, [Field Service vs Project Operations](https://www.solvingdynamics365.com/guides/field-service-vs-project-operations) draws the line.
### Frequently asked questions
**What is a work order in Dynamics 365 Field Service?**
The central record: customer, asset, geocoded location, required products, services and skills, estimated duration, priority, SLA, and a status lifecycle that runs Scheduled, Travelling, On Site, Complete, Posted. Work orders are created from cases, phone calls, preventive maintenance schedules, IoT alerts, or a customer portal.
**What is Resource Scheduling Optimization and do I need it?**
RSO is the optional engine that plans an entire fleet's day against routes, skills, time windows, SLA priorities, and travel time. It typically lifts productive time 5–15% over hand-scheduling and carries its own licence. Small teams get by with the schedule board and the schedule assistant.
**Does the Field Service mobile app work offline?**
Yes — offline is the central design requirement. Technicians carry bookings, navigation, asset history, knowledge articles, truck stock, and forms for time, parts, photos, signatures, and inspections, and the app syncs when coverage returns.
**How does IoT fit into Field Service?**
Through Connected Field Service and Azure IoT, device alerts create work orders automatically. Anomaly detection can decide whether to dispatch, pre-order a part, or attempt a remote reset first — and a successful remote fix closes the incident without a truck roll.
**Which Field Service licences exist?**
Field Service for technicians, dispatchers, and admins; Field Service Contractor for third parties who only need mobile work-order access; and a device-based Frontline Worker option for high-volume fleets. RSO is a separate add-on, and attach pricing applies to users who already hold another Dynamics 365 app.
---
# What is Dynamics 365 Finance?
Microsoft's enterprise finance app — multi-entity general ledger, AP/AR, fixed assets, budgeting, and consolidations at scale.
Source: https://www.solvingdynamics365.com/guides/what-is-dynamics-365-finance
Section: Finance & SCM / Overview & platform
Published: 2026-05-01
Updated: 2026-08-27
Dynamics 365 Finance is Microsoft's enterprise-grade financial management application — the upper-tier counterpart to Business Central's finance module. It descends from the **Dynamics AX** general ledger and is aimed at organisations that operate across many legal entities, currencies, and jurisdictions, typically with revenues from a hundred million up into the multi-billions.
## Multi-entity, multi-currency, multi-everything
Finance models a **legal entity** as the unit of statutory reporting, with its own chart of accounts, fiscal calendar, currencies, and posting layers. A tenant can hold hundreds of legal entities sharing master data through **data sharing policies** and a **global address book**, with intercompany accounting wired in so that transactions between entities balance automatically.
This is where the product earns its price. A group with 40 legal entities across Europe, LATAM, and APAC can share vendors, customers, items, and employees through data-sharing while keeping local statutory postings, local charts of accounts, and local reporting compliant. Businesses that started on one ERP per country and hit the wall trying to consolidate them are the archetypal Finance customer.
## General ledger
A single **shared chart of accounts** can be reused across entities, layered with up to ten **financial dimensions** (Department, Cost Centre, Project, Region, Product Line, and so on) and analysed through **Financial Reporting** (the descendant of Management Reporter). Dimensions are set-based rather than segment-based, so a report can slice on any subset independently — a change from segment-based ledgers where the chart of accounts itself carried the analytical structure.
Multiple **posting layers** (Current, Operational, Tax) let you post the same transaction differently for statutory and management views without a parallel ledger. The Tax layer is heavily used in jurisdictions where the tax view of an asset or a deferred revenue differs materially from the accounting view.
## Accounts payable and receivable
Vendor and customer invoicing, **payment proposals**, settlements with cash discounts and write-offs, ageing, and centralised payments across legal entities. Strong support for **electronic invoicing** through the Globalisation Studio's e-invoice profiles per country, **bank automation** through direct bank feeds or file-based statement import, and **AI-assisted matching** for payments and invoices.
Vendor collaboration lets suppliers submit invoices directly through a portal; on the customer side, **customer portals** and **B2B commerce** integration cover self-service.
## Fixed assets and revenue recognition
Multiple **depreciation books** run in parallel per asset — tax, IFRS, US GAAP, and internal management can all coexist on the same physical asset. Proposals for depreciation, transfers, splits, and disposals are journal-driven; asset lifecycle costs (acquisition, capitalisation, disposal, impairment) roll up into the general ledger through configurable posting profiles.
The dedicated **Revenue Recognition** module covers ASC 606 and IFRS 15 with bundles, allocations, contract management, and residual-method treatment. It replaced the older Revenue Recognition in Sales and Marketing and is the current recommended path for subscription and services businesses.
## Budgeting, planning, and consolidations
**Budget control** with optional commitment accounting stops purchase orders and expense reports that would overrun a budget bucket. **Budget planning** workflows let distributed contributors build a consolidated plan through Excel templates and route-based approvals. Neither replaces a full corporate-performance-management tool (Anaplan, OneStream, Board), but for mid-complexity groups they're often sufficient.
Native **consolidations** of multiple legal entities into a reporting entity — with currency translation, intercompany eliminations, and adjustments — again cover moderate complexity without a separate CPM system. For very large or highly acquisitive groups, a specialised CPM product is still the norm.
## Tax and regulatory
Country-specific localisations cover VAT / sales tax calculation, statutory reporting, electronic invoicing, and audit files (SAF-T, GDPdU, DATEV, SII) for dozens of countries. Microsoft maintains the localisation packs, and the ISV ecosystem fills gaps where local formats change ahead of Microsoft's release cycle.
The **Globalisation Studio** and the underlying **Electronic Reporting** framework are configurable — a partner or in-house team can define a new e-invoice format or a statutory report without code, which matters as more countries roll out real-time e-invoicing mandates.
## Licensing and implementation
Sold per user, with **Full User**, **Activity User**, and **Team Member** tiers. Attach licenses reduce the cost of adding a second Dynamics 365 app to users who already hold one. The Team Member license is genuinely restricted — read-only for finance, with narrow write access — so most core finance staff need a Full User.
Implementation almost always involves a global system integrator: Avanade, EY, Deloitte, PwC, Sikich, or a large regional partner. Projects run from six months for a subsidiary rollout to two years or more for a global template. Post go-live, the shared platform means Finance and Supply Chain roll forward together on Microsoft's release cadence — two major waves a year plus monthly service updates.
## Where to go next
Go deeper with [financial dimensions in Dynamics 365 Finance](https://www.solvingdynamics365.com/guides/financial-dimensions-in-dynamics-365-finance), [environments and LCS](https://www.solvingdynamics365.com/guides/dynamics-365-finance-environments-and-lcs), and the update discipline in [One Version and updates](https://www.solvingdynamics365.com/guides/dynamics-365-one-version-and-updates). [Year-end close in F&O](https://www.solvingdynamics365.com/guides/year-end-close-in-f-and-o) shows the periodic routines in practice. If you are deciding between tiers, [Business Central vs Finance and Operations](https://www.solvingdynamics365.com/guides/business-central-vs-finance-and-operations) draws the line, and the [Finance and Operations pricing page](https://www.solvingdynamics365.com/pricing/finance-and-operations) has current list prices.
### Frequently asked questions
**What is the difference between Dynamics 365 Finance and Business Central?**
Finance is the enterprise-tier ledger descended from Dynamics AX, built for groups with many legal entities, currencies, and statutory regimes; Business Central is the SMB ERP. Finance costs roughly three times more per user, is implemented by global system integrators over six months to two years, and pays off when you need a shared chart of accounts, posting layers, native consolidations, and dozens of localisations in one tenant.
**Is Dynamics 365 Finance the same product as Finance and Operations?**
Finance is one half of what Microsoft calls the Finance and Operations apps. Finance and Supply Chain Management share one application core, one database, and one object model — effectively one product licensed as two — so a Finance-only deployment can add Supply Chain later without integration work.
**How many financial dimensions does Dynamics 365 Finance support?**
Up to ten financial dimensions on a shared chart of accounts. They are set-based rather than segment-based, so a report can slice on any subset independently without the chart of accounts having to carry the analytical structure.
**Does Dynamics 365 Finance handle IFRS 15 and ASC 606 revenue recognition?**
Yes. The dedicated Revenue Recognition module covers bundles, allocations, contract management, and residual-method treatment. It replaced the older revenue recognition feature in Sales and Marketing and is the recommended path for subscription and services businesses.
**Who implements Dynamics 365 Finance and how long does it take?**
Almost always a global system integrator or a large regional partner. Six months for a subsidiary rollout is the fast end; a global template takes two years or more, and consulting effort dominates total cost in the first two years.
---
# What is Dynamics 365 Human Resources?
Microsoft's HR core app — employee records, organisational structure, benefits, leave, and compensation, integrated with payroll partners.
Source: https://www.solvingdynamics365.com/guides/what-is-dynamics-365-human-resources
Section: Customer Engagement / Human Resources
Published: 2026-05-01
Updated: 2026-08-27
Dynamics 365 Human Resources is Microsoft's HR application. It is most accurately described as **HR core** — the system of record for employees, organisations, positions, benefits, leave, and compensation — designed to integrate with specialist payroll, talent acquisition, and learning systems rather than replace them.
## Where it fits
The HR software market splits into three parts. **Talent acquisition** (Workday Recruiting, Greenhouse, SmartRecruiters). **HR core** (Workday HCM, Oracle HCM, SAP SuccessFactors, UKG Pro, Dayforce HCM, Dynamics 365 HR). **Payroll** (Dayforce, ADP, UKG, SD Worx, country-specific specialists like Fortnox in Sweden). The three are increasingly bought together as suites but they solve different problems.
Dynamics 365 HR is a competitive HR-core product for Microsoft-centric organisations that don't need a full end-to-end Workday-shaped suite. It wins on the Microsoft integration angle — Teams-native workflows, Copilot in HR, F&O integration, Entra ID identity — and on the price for organisations already committed to the Microsoft stack. It loses when the buyer wants talent acquisition, HR core, and full multi-country payroll from one vendor with one contract, which is the Workday-scale play.
## Workers, jobs, and positions
The core data model distinguishes three concepts that HR practitioners take for granted but that engineers building integrations often confuse.
A **job** is a generic role definition. "Accountant", "Welder", "Software Engineer". It carries the job description, the compensation grade, the required skills. Jobs live at the organisational level, not tied to any specific person or reporting line.
A **position** is a specific instance of a job somewhere in the org chart. It has a reporting line (the manager's position), FTE (full or fractional), location, cost centre, budget, and start / end dates. Positions can be **vacant** (approved but unfilled), **filled** (someone occupies them), or **planned** (approved for a future date).
A **worker** is a person, whether currently employed, on leave, terminated, or a contingent contractor. One worker can hold multiple positions (a fractional CFO who is CFO at two group companies), and positions can be filled by different workers over time.
This model matters because most people-driven decisions in HR happen at the position level (headcount planning, budgeting, org-chart moves) while payroll and compliance happen at the worker level. Getting the two aligned is the primary integration job when Dynamics 365 HR feeds a payroll system.
## Personnel administration
Employee records, contracts, identification numbers, dependents, addresses, work eligibility documents, and a full audit history of changes are first-class. The audit history matters for compliance — an HR system that can't answer "when did we change this employee's grade and who approved it" fails regulatory review.
Self-service through the **Employee Self-Service** workspace lets staff update personal data, view payslips (where the payroll integration surfaces them), request leave, enrol in benefits, and complete required training. **Manager Self-Service** covers team calendars, approval queues, position management for the manager's org, and compensation planning.
Both self-service surfaces embed in Teams — Copilot for HR pushes into the Teams-native experience for onboarding-question answering, policy lookup, and self-service triage of common employee requests.
## Leave and absence
Leave plans are highly configurable — **accrual rules** (fixed per period, based on service length, based on grade, blended), **carry-over policies**, **blackout periods** (no leave during month-end close, during peak retail), **multi-level approval** (line manager, then departmental), **calendar-aware deductions** (weekend and holiday awareness), and **country-specific holiday calendars**.
Manager self-service includes team calendars showing who is off when, approval queues with SLAs, and delegation for when a manager is themselves on leave. **Copilot** in leave handling drafts responses to leave requests based on team coverage — useful for high-volume operational teams where a manager approves dozens of requests a week.
## Benefits
**Benefit plans** with eligibility rules (grade, tenure, geography), life-event handling (marriage, child birth, relocation), vendor integration via standard files, and worker enrolment flows. **Open enrolment** events are supported with date-bounded windows and automated communication.
The benefits module is more North America-centric than the rest of the product — the deep US health-insurance flows have more depth than the equivalent for European countries where statutory frameworks cover more of the ground. For non-US customers with complex benefits (private health plans, share schemes, salary sacrifice), the benefits module is a starting point rather than a complete answer.
## Compensation
Fixed and variable compensation plans, **grades and levels**, merit-based and performance-based increases, eligibility rules, and **compensation review** processes routed through workflow. Comp reviews can be annual, bi-annual, or role-specific; multi-manager sign-off is standard.
Variable compensation covers bonus plans, commissions (for revenue-carrying roles), retention plans, and stock plans. Integration to payroll ensures the awarded amounts flow through to pay runs; integration to Sales (for commission plans) can tie payouts back to booked revenue.
## Performance and skills
Performance reviews, goals, competency models, and skills tracking are included at a baseline level. The depth is adequate for standard annual reviews and OKR-style goal management. Deeper **talent-development experiences** — 360 feedback, structured mentorship, career-pathing platforms, learning experience platforms — typically integrate from third parties (Cornerstone, Docebo, Culture Amp).
**Skills** as a first-class concept is getting more attention across the HR software category, and Dynamics 365 HR has been building out its skills framework alongside the wider Microsoft skills story (which connects to Viva Skills and to Copilot's understanding of what employees do).
## Payroll
Microsoft does **not** ship full payroll for most countries. This is a deliberate product decision — payroll is deeply country-specific, changes with every fiscal year, and requires country-specific certification. Microsoft chose not to enter that battle.
Instead, Dynamics 365 HR exposes APIs and pre-built integrations to **Dayforce, ADP, UKG, SD Worx**, and others. Customers select a payroll partner per country and integrate through the standard hooks. The trade-off is honest: another vendor to manage, but proven country-specific payroll rather than a Microsoft attempt at a compromise.
For organisations that want everything in Microsoft, this is the biggest gap. For organisations that are pragmatic about buying specialist payroll where the specialists are strongest, it is the right call.
## Architecture
Dynamics 365 HR was originally a separate app with its own environment model. In 2023 Microsoft **merged it back into the Finance and Operations stack**, so it now shares the F&O data model, runs in the same environments as Finance and SCM, and uses the same platform tooling.
For customers running F&O this consolidation is helpful — one platform, one deployment story, integrated data. For customers on the standalone HR product, the merger required a migration project. For new implementations in 2026, the merged model is the only option.
**Dataverse-side integration** (to Sales, Customer Service, Field Service) is via **Dual-write** — real-time bidirectional sync between the F&O side (where HR lives) and Dataverse (where the CRM apps live). This is important for scenarios like Field Service technicians needing HR data (skills, certifications) or Sales representatives seeing quota assignments from HR compensation data.
## Copilot in HR
**Copilot for HR** covers three main workflows:
- **Employee self-service Copilot** — answers routine employee questions in Teams (leave policy, benefits detail, payroll timing) from HR policy documents.
- **HR triage Copilot** — for HR business partners, summarises employee history and suggests handling for a specific case.
- **Compensation planning Copilot** — assists managers building comp proposals with peer benchmarking and budget-fit checking.
Copilot for HR is a newer addition to the Copilot roster and its depth trails the more established Copilot for Sales / Service, but the employee self-service surface is the highest-leverage one for large organisations where HR business partners are stretched.
## Licensing
Per worker per month for the core product, with different price points for full HR functionality vs employee self-service. Attach licensing lets HR sit alongside other Dynamics 365 apps at a reduced base price.
The economics work best for organisations with 500+ employees and a serious HR core requirement. Below that scale, standalone payroll-plus-basic-HR from a specialist (Fortnox, Personio, HiBob) is often cheaper and quicker to deploy.
## The short version
Dynamics 365 HR is Microsoft's HR core. It handles employee records, positions, leave, benefits, and compensation, and integrates with specialist payroll systems rather than replacing them. Sits on the F&O platform since 2023. Best fit for Microsoft-shop organisations that want HR core inside the same platform as their finance and operations, and that are pragmatic about buying payroll from a specialist.
## Where to go next
Module guides: [leave and absence](https://www.solvingdynamics365.com/guides/dynamics-365-hr-leave-and-absence), [benefits management](https://www.solvingdynamics365.com/guides/dynamics-365-hr-benefits-management), and [performance management](https://www.solvingdynamics365.com/guides/dynamics-365-hr-performance-management). Because HR now lives on the Finance and Operations platform, [what is Dynamics 365 Finance](https://www.solvingdynamics365.com/guides/what-is-dynamics-365-finance) describes the environment it runs in, and [dual-write](https://www.solvingdynamics365.com/guides/dynamics-365-dual-write-integration) is how its data reaches the CRM apps.
### Frequently asked questions
**Does Dynamics 365 Human Resources include payroll?**
Not for most countries. Microsoft deliberately integrates with specialist payroll providers — Dayforce, ADP, UKG, SD Worx, and country specialists — through APIs and pre-built connectors rather than shipping its own multi-country payroll.
**What is the difference between a job, a position, and a worker?**
A job is a generic role definition; a position is a specific instance of that job in the org chart with a reporting line, FTE, cost centre, and dates; a worker is a person who fills positions over time. Headcount planning happens at position level, payroll and compliance at worker level.
**Is Dynamics 365 HR a separate product from Finance and Operations?**
Not any more. In 2023 Microsoft merged it back into the Finance and Operations stack, so it shares the F&O data model, environments, and tooling. For new implementations the merged model is the only option.
**What size organisation is Dynamics 365 HR right for?**
The economics work best above roughly 500 employees with a genuine HR-core requirement. Below that, a specialist payroll-plus-basic-HR product such as Fortnox, Personio, or HiBob is often cheaper and faster to deploy.
**How does HR data reach the CRM apps?**
Through dual-write, which syncs the Finance and Operations side (where HR lives) with Dataverse. That is how Field Service can see technician skills and certifications, or Sales can see quota assignments derived from compensation data.
---
# What is Dynamics 365 Project Operations?
Microsoft's project-based services app — opportunity to cash for professional-services firms, with resourcing, scheduling, time, expenses, billing.
Source: https://www.solvingdynamics365.com/guides/what-is-dynamics-365-project-operations
Section: Customer Engagement / Project Operations
Published: 2026-05-01
Updated: 2026-08-27
**Dynamics 365 Project Operations** is Microsoft's professional-services automation (PSA) application — the system that runs an opportunity-to-cash flow for businesses that sell project work. Typical customers are consulting firms, marketing and creative agencies, IT services firms, engineering practices, and architecture firms. Project Operations sits deliberately across the CRM/ERP boundary because a services business needs both sides of the house tightly integrated: an opportunity in the sales funnel has to turn into a resourced project, and the hours consultants log against that project have to turn into revenue and cost postings in the ledger.
## Where it fits
In the wider PSA market, Project Operations competes with **Salesforce Services Cloud (Copado / Financial Force lineage)**, **Microsoft Dynamics 365 successors like Certinia**, **Deltek**, and specialist products like **Kantata**, **Kimble** (now Kantata), **Replicon PSA**, and **Wrike / Smartsheet** at the lighter end. It wins when the buyer already runs Microsoft business apps (Sales in front, F&O or Business Central at the back), when the deep Copilot integration matters, and when the shared Dataverse means an opportunity, a project, and an invoice can share the same account record without a middleware layer.
The line between Project Operations and simpler project management tools matters. Wrike, Smartsheet, and Microsoft Planner cover task management well but they are not PSAs — they don't touch billing, cost accounting, or revenue recognition. Project Operations is a PSA. If the business needs a WBS but not project accounting, it is over-scoped; if the business needs project accounting, task-tracker tools are under-scoped.
## The three deployment modes
Project Operations is one product but operates in three modes depending on the customer's back office. The mode decides most of the architecture and much of the implementation cost.
**Lite deployment** — runs entirely on Dataverse, with financial postings integrated to **Business Central**, QuickBooks, Xero, or SAP via APIs. The right fit for SMB services firms whose financials sit in BC or a small-business accounting system. Fastest to deploy, cheapest to run, ceiling at moderate complexity.
**Resource / non-stocked deployment** — runs on the **Finance and Operations** stack with full F&O accounting integration. Time and expense post directly to F&O's general ledger through project accounting; there is no middleware. Right for services firms already on F&O or heading there; also right for large services firms whose complexity Lite cannot handle (multi-currency, multi-entity project accounting, IFRS 15 revenue recognition).
**Stocked / production deployment** — extends the F&O deployment with manufacturing and inventory. Right for firms that build and install physical goods as part of the project — engineering firms delivering equipment, construction firms with material take-offs, systems integrators building custom hardware plus services. Combines project services with deliverable goods on the same work order and the same project profit line.
The mode choice is not reversible without a re-implementation, so it deserves serious analysis at the start of a Project Operations engagement — not as an afterthought.
## Opportunity to quote
Sales pursues an opportunity in the Sales app; when it's qualified as project work, a **project quote** is configured with phases, tasks, roles, hours, and billing terms. Billing types cover fixed-price, time-and-materials, capped T&M, milestone billing, and mixed contracts where different work streams inside one contract carry different terms.
The quote is priced from a **rate card** by role, seniority, and geography, adjusted with client-specific discounts and prepaid retainers, and reviewed through a configurable approval flow. On win, it converts to a **project contract** that carries the pricing, the milestones, the billing schedule, and the deliverables into project execution.
## Project plan and WBS
A **work breakdown structure (WBS)** with tasks, dependencies, durations, effort estimates, and assignments. Baseline and current schedules are tracked separately so slippage against the baseline is visible.
Resourcing is done from a **resource hub** that shows availability, skills, location, cost rate, and current utilisation. Assignment can be by named resource (Emma is on this) or by generic role (a senior Java developer, to be named later). Generic assignments carry through the plan until they're replaced with real names, so the plan can be built before the resource conversations are finished.
For firms coming from Microsoft Project or Smartsheet, the WBS experience is different — simpler in some places (no Gantt-chart theatre), richer in others (integrated resource cost, integrated billing). The learning curve is short but the mental model shift matters.
## Time and expenses
Consultants enter time on a weekly **timesheet** and expenses through receipts and policy-aware approvals. Both flow through workflow approval — the project manager first, then whatever additional approval the policy demands (an expense over a threshold routes to the finance director, mileage over a limit needs a business-purpose note).
Approved time and expenses post to the project for billing and cost. In Lite deployment, the postings flow to the connected finance system; in F&O deployments, they post directly to the general ledger, WIP, and project accounting through the F&O project posting framework.
**Copilot in Project Operations** speeds up time entry — draft a week's timesheet from the consultant's Teams meetings and calendar, review, adjust, submit. Not perfect on the first try, but a serious lift over a blank grid.
## Billing
Invoicing runs at the cadence defined in the contract — monthly retainers, milestone billing, on-completion, on-approval, or scheduled instalments. Invoices can hold multiple billable types (T&M plus fixed-fee plus expense recovery) on a single invoice, with multiple currencies where the contract requires it.
Drafts are routed through review by the engagement partner, the client-partner, or finance — configurable — before posting to the back-office system for collection. Credit notes and re-billing follow the same flow in reverse.
## Reporting
Built-in dashboards for project margin, resource utilisation, billable mix (billable vs non-billable hours), backlog, forecast vs actual, and cash forecast from open invoices. Practice-level reports roll up the individual projects into service line and firm KPIs.
The reporting depth is adequate for most services firms; deeper analytics ship as a Power BI app on top of Project Operations data in Dataverse or Fabric. Firms that need very rich portfolio management (predictive cash forecasting, capacity planning across a global practice) typically layer a specialist tool on top for the CFO reporting even while keeping Project Operations as the source of truth.
## Integration
Project Operations shares Dataverse with Sales, Customer Service, and Field Service, so an opportunity in Sales flows through to a project and a client account carries the full history. Financial postings go to F&O directly (in F&O deployments) or to BC / third-party accounting via connectors (in Lite deployments).
**Copilot** across the Dynamics 365 family means a project manager can query pipeline, resource load, and billing status in natural language across apps. **Power BI** ties the operational data to whatever wider CFO reporting matters.
## Licensing
Sold per user. Two SKUs plus a lightweight one:
**Project Operations** — the standard licence for project managers, resource managers, and consultants who need the full application.
**Project Operations — Team Member** — a lightweight licence for consultants who only need to submit timesheets and expenses. Priced substantially lower than the full licence; the right choice for the majority of a services firm's headcount.
Attach licensing lets Sales seats add Project Operations at a reduced price — common where account managers pursue and stay engaged on project work.
## The short version
Project Operations is Microsoft's PSA. It runs the opportunity-to-cash flow for services firms. Three deployment modes (Lite on Dataverse, F&O for larger firms, Stocked for build-plus-services) — the choice decides the whole architecture. It fits Microsoft-shop services businesses well; it competes with specialist PSAs on capability and typically wins on integration into the wider Microsoft business apps stack.
## Where to go next
The deployment-mode decision is expanded in [Project Operations deployment types](https://www.solvingdynamics365.com/guides/project-operations-deployment-types). Daily operation is covered in [time and expense](https://www.solvingdynamics365.com/guides/project-operations-time-and-expense) and [resource management](https://www.solvingdynamics365.com/guides/project-operations-resource-management). For the two adjacent products people confuse it with, see [Field Service vs Project Operations](https://www.solvingdynamics365.com/guides/field-service-vs-project-operations) and [Business Central Jobs vs Projects](https://www.solvingdynamics365.com/guides/business-central-jobs-vs-projects).
### Frequently asked questions
**What are the three Project Operations deployment modes?**
Lite runs on Dataverse with financials in Business Central or a third-party accounting system; Resource (non-stocked) runs on Finance and Operations with direct project accounting; Stocked (production) adds manufacturing and inventory for firms that build and install goods. The choice is not reversible without a re-implementation.
**Is Project Operations a project management tool like Microsoft Project or Smartsheet?**
No — it is a professional services automation (PSA) system that runs opportunity-to-cash: quoting, resourcing, time and expense, billing, and project accounting. If you need a work breakdown structure but no project accounting it is over-scoped; if you need project accounting, task trackers are under-scoped.
**Which billing models does Project Operations support?**
Fixed-price, time-and-materials, capped time-and-materials, milestone billing, and mixed contracts where work streams inside one contract carry different terms. Pricing comes from a rate card by role, seniority, and geography, adjusted with client-specific discounts and retainers.
**Do all consultants need a full Project Operations licence?**
No. The Team Member licence covers consultants who only submit timesheets and expenses and is the right choice for most of a services firm's headcount. Project managers, resource managers, and consultants who need the full application take the full licence.
**Who does Project Operations compete with?**
Certinia, Deltek, Kantata (formerly Kimble), Replicon PSA, and at the lighter end Wrike and Smartsheet. It wins when Sales, Copilot, and Business Central or Finance and Operations are already in place and a shared account record across opportunity, project, and invoice matters.
---
# What is Dynamics 365 Sales?
Microsoft's CRM app for B2B sales teams — leads, opportunities, forecasting, and the Copilot for Sales experience.
Source: https://www.solvingdynamics365.com/guides/what-is-dynamics-365-sales
Section: Customer Engagement / Sales
Published: 2026-05-01
Updated: 2026-08-27
Dynamics 365 Sales is Microsoft's CRM app for B2B sales teams. It is the modern, Dataverse-native descendant of the original Microsoft Dynamics CRM Sales module, and the centre of gravity for everything Microsoft does in the front office.
## Where Sales fits in the Dynamics 365 family
Sales is the flagship of the CRM-lineage apps. Around it sit **Customer Service** (case management), **Field Service** (dispatch and on-site work), **Marketing** and **Customer Insights** (journeys and data unification), and **Project Operations** (services-firm sales-to-delivery). All of them run on the same **Dataverse** with the same core Account, Contact, and Activity tables. That shared model is the primary reason a Microsoft-shop CRO picks Sales over Salesforce or HubSpot: an account created in Sales is the same account that a Customer Service agent sees, that a Field Service technician's work order references, and that a Business Central or Finance ERP receives an order for.
That said, Sales is not automatically the best B2B CRM in every context. Salesforce still has the deeper ecosystem for pure sales orgs; HubSpot still wins at the SMB end. Sales earns its place when the buyer values the tight integration into Microsoft 365, Copilot, and Dynamics 365 ERP over category-leading CRM features in isolation.
## The data model
Sales runs on Dataverse with a small set of well-defined tables: **Lead**, **Opportunity**, **Account**, **Contact**, **Quote**, **Order**, **Invoice**, and the **Product** catalog with **price lists** and **discount lists**. Activities (phone calls, emails, appointments, tasks) hang off every record, giving a single timeline view per customer.
The lead-versus-opportunity distinction is deliberate. A lead is an un-qualified potential — a name from a form, a business card, a Sales Navigator export — that has not yet been vetted. Qualifying it creates the Account, Contact, and Opportunity records that carry the pipeline forward. Some organisations skip leads entirely and enter opportunities directly; that is a valid choice and Sales supports it.
Products, price lists, and discount lists let quotes and orders be built from a governed catalog rather than free text — important once the sales org is large enough that discount discipline matters, and mandatory if the CRM feeds an ERP downstream.
## Process
A lead is qualified into an opportunity; the opportunity moves through a configurable **business process flow** (typically Qualify → Develop → Propose → Close) with stage-gated fields and automated next-best-action prompts; from there it converts to a quote, order, or invoice. The whole lifecycle is configurable, including stages, branches, KPIs, and the tables the flow spans.
Business process flows are Microsoft's answer to the tension between "give sellers a guided experience" and "let the sales manager tune the process without a developer". They are declarative, versioned, and can differ per business unit — a global org can run one BPF for enterprise deals and another for velocity deals.
## Forecasting
Sales includes a **forecasting** module that rolls opportunities up the sales hierarchy with submitted, projected, committed, and best-case columns. Forecasts are versioned, manager-adjustable, and snapshotted for trend analysis. Multiple forecast types can coexist — territory-based, product-based, seller-based — and each has its own configuration.
For CROs coming from Salesforce Forecasting or Clari, the feature is capable but not category-leading. It covers the standard weekly pipeline call well; deeper AI-driven predictive forecasting benefits from feeding the Sales pipeline into a purpose-built analytics tool.
## Sales accelerator and sequences
A separate workspace called the **sales accelerator** sequences daily prospecting work: the seller's queue of leads and opportunities is prioritised by a scoring model, with **sequences** — configurable step-by-step cadences of emails, calls, tasks, and waits — driving the day. Sequences are the closest analogue to Outreach and Salesloft; Microsoft has been closing the gap steadily.
Combined with **conversation intelligence** (call and meeting transcription with tracked keyword and sentiment analysis), the accelerator turns Sales into a genuine SDR/BDR tool, not only an opportunity tracker.
## Copilot for Sales
Copilot for Sales is the AI layer that sits inside Outlook, Teams, and the Sales app itself. It summarises emails, drafts replies, prepares meeting briefings, extracts notes and next steps back to CRM records, and answers natural-language questions across the pipeline ("show me all deals over 100k that slipped from Q2"). It also integrates the reverse direction — a seller sitting in Outlook sees the CRM context for the person they are emailing, without switching apps.
Copilot for Sales is separately licensed as an add-on to Sales Enterprise, or bundled into Sales Premium. It is also sold as a standalone that connects to Salesforce CRM for organisations that want the Copilot experience without moving off Salesforce.
## Integration with the Microsoft cloud
Sales is tightly integrated with Outlook (email tracking, appointment sync), Teams (embedded records, meeting recordings auto-attached with Copilot summaries), LinkedIn Sales Navigator (insights, InMail from within CRM, contact import), and Power BI (out-of-the-box pipeline dashboards). Customer Service, Field Service, Marketing, and Customer Insights run on the same Dataverse, so the same Account record carries through.
Integration to the ERP side — Business Central or Finance and Supply Chain — is standard: quotes and orders can flow from Sales into ERP for fulfilment, invoicing, and settlement. **Dual-write** provides real-time bidirectional sync for F&O; connectors and Power Automate flows cover Business Central.
## Licensing
Sold per user, in **Professional**, **Enterprise**, **Premium**, and **Relationship Sales** tiers.
**Professional** is a light SKU without the deeper enterprise features (no forecasting, limited customisation) — rarely the right pick for a serious sales org. **Enterprise** is the most common tier and the working baseline. **Premium** bundles Copilot for Sales and the sales accelerator's advanced capabilities. **Relationship Sales** is Enterprise plus LinkedIn Sales Navigator, priced for account-based sellers.
Attach licensing lets users who already hold another Dynamics 365 app add Sales at a reduced base price, which matters for organisations rolling out multiple Dynamics 365 apps to the same seat.
## Where to go next
For the head-to-head most buyers run, see [Dynamics 365 Sales vs Salesforce](https://www.solvingdynamics365.com/guides/dynamics-365-sales-vs-salesforce). Going deeper on the modules: [forecasting](https://www.solvingdynamics365.com/guides/dynamics-365-sales-forecasting-deep-dive), [sequences in the sales accelerator](https://www.solvingdynamics365.com/guides/sequences-in-the-sales-accelerator), [Copilot for Sales features](https://www.solvingdynamics365.com/guides/copilot-for-sales-features), and what [Sales Premium](https://www.solvingdynamics365.com/guides/dynamics-365-sales-premium-features) adds. Current list prices are on the [Sales pricing page](https://www.solvingdynamics365.com/pricing/sales).
### Frequently asked questions
**What is the difference between a lead and an opportunity in Dynamics 365 Sales?**
A lead is an unqualified potential — a form fill, a business card, a Sales Navigator export. Qualifying it creates the Account, Contact, and Opportunity records that carry the pipeline forward. Organisations that skip leads and create opportunities directly are making a valid, supported choice.
**Which Dynamics 365 Sales licence should most organisations buy?**
Sales Enterprise. Professional is a light SKU without forecasting and with limited customisation; Premium adds Copilot for Sales and the advanced sales accelerator features; Relationship Sales bundles Enterprise with LinkedIn Sales Navigator for account-based sellers.
**Does Dynamics 365 Sales include forecasting?**
Yes, on Enterprise and above. Forecasts roll opportunities up the sales hierarchy with submitted, projected, committed, and best-case columns, are manager-adjustable, versioned, and snapshotted. It covers the weekly pipeline call well; deeper predictive forecasting benefits from a purpose-built analytics tool on top.
**Can Dynamics 365 Sales replace an SDR tool like Outreach or Salesloft?**
For many teams, yes. The sales accelerator prioritises the daily work queue, sequences run configurable cadences of emails, calls, tasks, and waits, and conversation intelligence adds call transcription with keyword and sentiment tracking. Microsoft has been closing the gap with the specialist tools steadily.
**How does Dynamics 365 Sales integrate with the ERP side?**
Quotes and orders flow from Sales into Business Central or Finance and Supply Chain Management for fulfilment, invoicing, and settlement. Dual-write provides real-time bidirectional sync with Finance and Operations; connectors and Power Automate flows cover Business Central.
---
# What is Dynamics 365 Supply Chain Management?
Microsoft's enterprise supply chain app — manufacturing, warehouse, transportation, planning, and asset management at scale.
Source: https://www.solvingdynamics365.com/guides/what-is-dynamics-365-supply-chain
Section: Finance & SCM / Overview & platform
Published: 2026-05-01
Updated: 2026-08-27
Dynamics 365 Supply Chain Management (SCM) is Microsoft's enterprise-grade application for procurement, manufacturing, inventory, warehousing, transportation, and master planning. Like Dynamics 365 Finance, it descends from Dynamics AX, and is built for organisations whose operational complexity has outgrown Business Central — multi-site manufacturers, large distributors, retailers, and process industries.
## Where it fits
SCM is the operations half of what Microsoft calls the **Finance and Operations apps** (F&O). Finance and SCM share a single application core, a single database, and a single object model — they are effectively one product sold as two. A deployment that runs both gets a unified back office with no integration between finance and operations; a deployment that runs only Finance is skipping the operational modules but sitting on the same platform, ready to add them later.
The target customer is a manufacturer, distributor, or asset-heavy operator with revenues from a few hundred million upwards. Below that scale, Business Central is usually the right fit, and its light-manufacturing capabilities cover simpler assembly workflows. Above it — global groups running across dozens of legal entities with heavy shop-floor operations — SCM competes directly with SAP S/4HANA and Oracle NetSuite / Fusion.
## Inventory and warehouse
Item master with sophisticated **product dimensions** (size, colour, style, configuration) and **tracking dimensions** (batch, serial, owner), multi-site warehousing, and full **Warehouse Management (WMS)** with handheld scanning, wave and load management, configurable **mobile device menus**, license plate tracking, cluster picking, and slotting. Directed put-away and picking are the norm, not the exception.
The WMS is deep enough that it replaces many standalone WMS products, and it can be **advanced-warehouse-enabled** on some warehouses while others operate in the simpler basic warehousing mode — useful for phased rollouts. Consignment inventory, vendor-owned stock, and split-ownership scenarios are all supported.
## Procurement
Vendor catalogues, sourcing, purchase requisitions with configurable approval workflows, RFQs with sealed-bid evaluation, purchase agreements (blanket orders), a **vendor collaboration portal** for suppliers who don't have EDI, and three-way matching between purchase order, receipt, and invoice.
For process-heavy industries, category management structures the spend hierarchy, and integration to **Microsoft Cloud for Sustainability** and to third-party spend-analytics tools brings emissions and category insight into the buying process.
## Manufacturing
SCM's manufacturing coverage is broad. **Discrete** manufacturing uses production BOMs and routings; **process** manufacturing uses formulas and co/by-products with catch-weight; **lean** manufacturing supports kanban and takt-based flow. All three modes can coexist on the same site.
Beyond the modes, the shop-floor toolkit is comprehensive: work centres and resources with capabilities and calendars, **finite scheduling**, subcontracting, engineering change management, batch attributes (viscosity, potency, purity) for regulated industries, and shop floor control with clock-in and job registration. **Product Configuration Model** (PCM) supports engineer-to-order and configure-to-order flows.
Manufacturing execution below that layer typically integrates through the **Manufacturing Execution System (MES) integration** hooks or through partner products; SCM is deliberately not an MES.
## Master planning
**Planning Optimization** is a high-performance, in-memory service that replaced the older MRP engine in the last few years. It runs net-change or full regenerative plans in minutes instead of hours, scales across hundreds of sites, and separates planning from the transactional database so long plans don't lock the system.
On top of Planning Optimization sit **demand forecasting** (statistical baseline forecasts) and the more recent **demand planning** module (collaborative planning workflows). Together they close the loop from statistical forecast to consensus plan to net requirement to purchase or production order.
## Transportation and asset management
Inbound and outbound transportation with rate shopping across carriers, route planning, load building, freight reconciliation, and shipping-carrier integration (parcel and LTL). Not a full TMS replacement for the largest 3PL operators, but adequate for most in-house transportation needs.
**Asset Management** covers work orders, preventive maintenance, condition-based monitoring, fault management, and IoT signal integration for industrial equipment — increasingly important for asset-heavy operators (utilities, mining, manufacturing plants) that want the maintenance system on the same platform as inventory and procurement.
## Adjacent products
Two products sit around SCM and are commonly deployed with it. **Intelligent Order Management** (sold separately) orchestrates orders across sales channels and fulfilment locations — useful for omnichannel retailers where the "where does this order ship from" decision is non-trivial. **Dynamics 365 Commerce** is the retail store solution (POS, e-commerce, clienteling); it uses SCM as its inventory and pricing back end.
For the CRM side of the business, SCM shares Dataverse via **Dual-write**, so a Sales opportunity in the Sales app or a case in Customer Service can flow through to a sales order or a return in SCM without custom integration.
## Licensing and implementation
SCM is licensed per user, typically alongside Finance under the F&O bundle. **Full users**, **Activity users**, and **Team Members** provide different price points depending on access needs. Device licenses cover shop-floor terminals and warehouse handhelds.
Implementations are large — six months at the very fast end, more commonly a year and up — and are almost always led by a global system integrator. The functional footprint is wide (finance, procurement, warehouse, manufacturing, transportation) and every area has depth, so consulting effort dominates the total cost of ownership in the first two years.
## Where to go next
The planning engine is covered in [master planning runs](https://www.solvingdynamics365.com/guides/master-planning-runs-in-f-and-o) and [Planning Optimization](https://www.solvingdynamics365.com/guides/dynamics-365-planning-optimization); the warehouse in [warehouse mobile workflows](https://www.solvingdynamics365.com/guides/warehouse-mobile-workflows-in-f-and-o); the three manufacturing modes in [discrete vs process vs lean](https://www.solvingdynamics365.com/guides/discrete-vs-process-vs-lean-manufacturing-in-f-and-o). The bridge to the CRM apps is [dual-write](https://www.solvingdynamics365.com/guides/dynamics-365-dual-write-integration). Current list prices are on the [Finance and Operations pricing page](https://www.solvingdynamics365.com/pricing/finance-and-operations).
### Frequently asked questions
**What does Dynamics 365 Supply Chain Management cover?**
Procurement, inventory, full warehouse management with handheld scanning, discrete, process, and lean manufacturing, master planning through Planning Optimization, transportation, and asset management — all on the same application core as Dynamics 365 Finance.
**When should I choose Supply Chain Management over Business Central?**
When operational complexity has outgrown Business Central: multi-site manufacturing, directed put-away and picking, process manufacturing with catch-weight, finite scheduling, or planning across hundreds of sites. Below a few hundred million in revenue, Business Central and its light manufacturing usually fit better.
**Is Dynamics 365 Supply Chain Management an MES?**
No. It covers shop-floor control, job registration, and finite scheduling but deliberately stops short of a manufacturing execution system. Machine-level execution integrates through Microsoft's MES integration hooks or partner products.
**What is Planning Optimization?**
The in-memory master planning service that replaced the older MRP engine. It runs net-change or regenerative plans in minutes rather than hours, scales across hundreds of sites, and runs outside the transactional database so long plans do not lock the system.
**How does Supply Chain Management connect to the CRM apps?**
Through dual-write, which syncs selected Supply Chain and Finance entities to Dataverse in near real time. A Sales opportunity or a Customer Service case can flow to a sales order or a return without custom integration.
---
# What is Dynamics 365?
A clear overview of Microsoft Dynamics 365 — what it is, who it's for, how the apps fit together, and what a real implementation looks like.
Source: https://www.solvingdynamics365.com/guides/what-is-dynamics-365
Section: Foundations / Platform overview
Published: 2026-05-01
Updated: 2026-08-25
Microsoft Dynamics 365 is a family of cloud-based business applications that combines enterprise resource planning (ERP) and customer relationship management (CRM) into a single, modular platform. Rather than buying one large monolithic system, organisations license the specific apps they need — Sales, Customer Service, Finance, Supply Chain Management, Business Central, Field Service, Project Operations, Human Resources, Commerce, and others — and run them on a shared data foundation called **Dataverse** (for the CRM-lineage apps) or on the F&O data model (for the AX-lineage apps).
## Where Dynamics 365 came from
Dynamics 365 launched in 2016 as the successor to Microsoft's earlier business-apps portfolio — Dynamics AX, NAV, GP, SL, and CRM. Several of those legacy lines still live on inside Dynamics 365 in evolved form. **Finance and Supply Chain Management** grew out of Dynamics AX. **Business Central** grew out of Dynamics NAV. The **CRM apps** (Sales, Customer Service, Field Service) grew out of Dynamics CRM. **GP and SL** are still supported but did not get modern cloud successors under the Dynamics 365 name.
The benefit of consolidating everything under one brand is not just cosmetic. All the apps now share identity (**Microsoft Entra ID**), reporting (**Power BI**), automation (**Power Automate**), extensibility (**Power Apps**, **Copilot Studio**, and Azure), and increasingly a single Copilot layer. That means a Sales record can trigger a Business Central invoice with a low-code flow, a Power BI dashboard can pull from both an F&O warehouse and Dataverse without ETL, and the same Entra ID user can be granted access to the whole stack from one place.
## The app families
Dynamics 365 splits into two lineages that share a brand but not a codebase.
The **customer engagement apps** — Sales, Customer Service, Field Service, Project Operations, Marketing (now Customer Insights – Journeys), and Contact Center — run on **Dataverse** and are the modern CRM stack. They share a data model, a security model, and the Power Platform build tools. Extensions are written in low-code Power Apps or in plugins and JavaScript.
The **finance and operations apps** — Finance, Supply Chain Management, Commerce, Human Resources, and Project Operations (F&O SKU) — evolved from Dynamics AX and run on a separate, X++-based platform. They are the enterprise ERP layer, aimed at organisations with complex financial consolidation, multi-legal-entity structures, or large warehouse and manufacturing operations. Development is in **X++**, deployed through **Lifecycle Services** (LCS).
**Business Central** is the third lineage — the SMB ERP evolved from NAV. It runs on its own platform, is extended in **AL**, and covers finance, sales, purchasing, inventory, and light manufacturing for mid-market companies.
The three lineages talk to each other via connectors, Dataverse virtual tables, and increasingly common Copilot surfaces — but under the hood they are still three products.
## Who it is for
Dynamics 365 is sold per user, per app, and is most commonly deployed by mid-market and enterprise organisations that have outgrown entry-level accounting or spreadsheets but want to avoid the cost and multi-year risk of a custom-built or SAP-scale ERP.
Typical buyers include:
- **SMB / mid-market ERP buyers** — usually landing on **Business Central**, sometimes coming from QuickBooks, Xero, Visma, Fortnox, or a home-grown NAV.
- **Enterprise ERP buyers** — landing on **Finance and Supply Chain Management**, often replacing on-premise AX, JD Edwards, IFS, or an ageing custom system.
- **Sales and service teams** — landing on **Sales**, **Customer Service**, **Field Service**, or **Project Operations**, often replacing Salesforce, HubSpot, ServiceNow, or Zendesk in a Microsoft-heavy organisation.
- **Marketing teams** — landing on **Customer Insights** to unify customer data across the CRM and ERP apps.
The single strongest reason to choose Dynamics 365 over a specialised competitor is almost always the **existing investment in Microsoft**: Entra ID, Microsoft 365, Teams, Power BI, and Azure are already there, and Dynamics 365 slots into them without any of the integration tax you would pay for a foreign stack.
## What it actually costs
Pricing is published on Microsoft's site — a per-user, per-month figure for each app, with base + attached-app discounts and volume discounts through enterprise agreements — but the sticker price is only ever a fraction of the real cost of Dynamics 365.
Real-world cost is dominated by:
- **Data migration** from the incumbent system, which is almost always more work than the customer expects.
- **Configuration** — chart of accounts, dimensions, security roles, workflows, price lists.
- **Customisations and integrations** — Power Automate flows, plugins, ISV apps, and connections to bank feeds, e-commerce platforms, warehouse hardware, or industry systems.
- **Training and change management** — Dynamics 365 replaces the tool people spend their day in, so adoption is a real project.
- **Partner fees** for all of the above.
A rough industry rule is that the first-year all-in cost is somewhere between **3× and 8× the annual licence cost**, depending on the apps in scope and how much customisation the customer takes on. In steady state, ongoing partner spend usually runs 15–30 % of licence spend per year.
## The partner ecosystem
Dynamics 365 is almost always implemented with help from a **Microsoft partner**. Microsoft itself does not deliver implementations except for the largest customers. Instead, a global network of certified partners — from boutique specialists to global systems integrators (**SIs**) — does the work.
The partner ecosystem breaks down roughly like this:
- **Business Central partners** — often specialise by country or by vertical (retail, manufacturing, distribution). Many have their own ISV extensions on top of BC.
- **F&O partners** — larger firms, often global SIs (Avanade, KPMG, EY, PwC, HSO, Cognizant, Wipro), because F&O programmes tend to be multi-year and multi-region.
- **Customer engagement partners** — a wider mix, from Power Platform-first specialists to CRM boutiques to the big SIs.
- **Independent software vendors (ISVs)** — publishing add-ons on AppSource for country-specific tax, industry verticals, or extra features Microsoft doesn't cover.
Choosing the right partner and apps is usually a bigger decision than choosing Dynamics 365 itself. A great platform with the wrong partner still fails; a mediocre platform with the right partner often quietly succeeds.
## Where to go next
If you're figuring out **which app to license**, the plain-English decision guide is [how to choose the right Dynamics 365 product](https://www.solvingdynamics365.com/guides/how-to-choose-the-right-dynamics-365-product). If you want the **whole product family on one page**, see the [Dynamics 365 product family](https://www.solvingdynamics365.com/guides/dynamics-365-product-family). For the **Power Platform connection**, read [Dynamics 365 and the Power Platform](https://www.solvingdynamics365.com/guides/dynamics-365-and-power-platform). And if you're weighing **Business Central vs Finance & Supply Chain**, start with [what is Business Central](https://www.solvingdynamics365.com/guides/what-is-business-central) and [what is Dynamics 365 Finance](https://www.solvingdynamics365.com/guides/what-is-dynamics-365-finance).
### Frequently asked questions
**Is Dynamics 365 one product or many?**
Many. Dynamics 365 is a family of modular apps — Sales, Customer Service, Finance, Supply Chain Management, Business Central, Field Service, Project Operations and more — licensed per app, per user. Under the brand there are three lineages with different codebases: the Dataverse-based CRM apps, the AX-descended Finance and Operations apps, and the NAV-descended Business Central.
**What does Dynamics 365 actually cost?**
License prices are published per user per month, but the sticker price is a fraction of the real cost. First-year all-in cost typically runs 3x to 8x the annual licence cost once data migration, configuration, integrations, training and partner fees are counted, and steady-state partner spend usually runs 15-30% of licence spend per year.
**Do I need a partner to implement Dynamics 365?**
Almost always. Microsoft itself does not deliver implementations except for the largest customers; a global network of certified partners does the work. Choosing the right partner is usually a bigger decision than choosing Dynamics 365 itself.
**Why choose Dynamics 365 over Salesforce or SAP?**
The single strongest reason is an existing Microsoft investment. If Entra ID, Microsoft 365, Teams, Power BI and Azure are already in place, Dynamics 365 slots into them without the integration tax of a foreign stack.
---
# What is Microsoft Dataverse?
Microsoft Dataverse is the relational data platform underneath Dynamics 365 CRM apps and Power Platform — what it is, why it's more than a database.
Source: https://www.solvingdynamics365.com/guides/what-is-microsoft-dataverse
Section: Customer Engagement / Dataverse platform
Published: 2026-08-27
Updated: 2026-08-27
**Microsoft Dataverse** is the relational data service underneath the Dynamics 365 CRM apps and the Power Platform. It provides tables, columns, relationships, security, and business logic through a managed cloud service that developers and makers interact with through a consistent metadata layer — never through raw database access.
Dataverse is not a database in the classical sense. It is a **relational data platform** with a rich security model, a workflow engine, integrated audit, first-class metadata, an event grid, and a native REST API. Underneath it uses Azure SQL, Azure Data Lake, and other Azure primitives, but you don't work with any of those directly. You work with Dataverse.
## Why it exists
Historically the CRM-lineage Dynamics 365 apps (Sales, Customer Service, Field Service) ran on a product called the **Common Data Service (CDS)**, itself the successor to the Dynamics CRM Xrm platform. In 2020 Microsoft rebranded CDS to Dataverse and repositioned it as the shared data foundation for the Power Platform, not just for the Dynamics 365 apps.
The strategic bet is that **one data model, one security model, one API surface** makes it dramatically cheaper to build the second, third, and tenth business application on the same tenant. Every Dynamics 365 CRM app runs on Dataverse. Every custom Power App can extend the same tables. Every Power Automate flow can trigger on events raised by that shared data.
## What Dataverse gives you
**Tables and columns.** Structured, typed data with all the standard column types (text, number, currency, date, choice, lookup) plus rich types (file, image, formula, calculated, rollup). Custom tables can be added with a maker experience or through metadata code.
**Relationships.** One-to-many, many-to-many, and hierarchical, with cascade rules on parent behaviour (share, assign, delete, merge). Related-table joins in queries are first-class.
**Security model.** Layered role-based, row-level, hierarchical, and field-level security. Business units carve the tenant into scopes; owner and access teams share records with subsets of users; roles define what each user can do inside their scope. Deep, well-thought-out, occasionally intricate — but sufficient for most enterprise security requirements without custom code.
**Business logic layers.** Business rules (declarative validation), workflows (classic, deprecated in favour of flows), plug-ins (server-side .NET code that fires on events), Power Automate flows, and Power Fx formulas for calculated columns and business logic. The right layer for a given piece of logic depends on performance, upgradeability, and complexity.
**Events.** Every row change raises an event that other tables, plug-ins, flows, and Azure services can subscribe to. This is what makes Dataverse a *reactive* platform rather than a static store.
**Audit.** Row-level and column-level change history, retained per environment configuration, accessible through the audit APIs. Regulatory requirements that demand "when did this field change and who changed it" have a native answer.
**Web API.** REST endpoints for every table, generated from the metadata layer, versioned per platform release. Native OData query semantics; batch operations; change-tracking; alternate keys. The primary integration surface.
## The extended Dataverse family
Beyond the core relational store, Dataverse ships a family of specialised storage patterns:
**Elastic tables.** NoSQL-style storage for high-volume, high-throughput scenarios — IoT telemetry, event logs, session data. Different consistency guarantees, different pricing, same API surface.
**Virtual tables.** Federated data that stays in its source system (a SQL Server, a REST API, a SharePoint list) and appears as a Dataverse table for read (and often write) purposes. Removes the need to synchronise data into Dataverse for scenarios where the source system is the truth.
**File and image columns.** Blob storage attached to records, with the same security model applied to the blobs as to the record. Suitable for document attachments, product images, work-order photos.
**Dataverse search.** Full-text and metadata search across all tables in the environment, with security trimming so users see only rows they can access.
**Dataverse for Teams.** A lightweight Dataverse that ships free inside Teams — a subset of the platform for lightweight scenarios where a team needs a shared data-driven app without a full Dataverse environment.
## Where Dataverse fits under Dynamics 365
Every CRM-lineage Dynamics 365 app is a pre-built collection of Dataverse tables plus the model-driven UI on top. **Account, Contact, Opportunity, Lead, Case, Work Order, Project** — these are Dataverse tables that the Dynamics 365 apps pre-configure. A custom table added to the same environment is *architecturally identical* — it participates in the same security, relationships, workflows, and API surface.
This is the reason extending Dynamics 365 uses exactly the same tools a maker would use for a fresh Power App. The developer / consultant / admin community can be the same community; the skills transfer bidirectionally.
The **Finance and Operations apps** (Finance, SCM, Commerce, Human Resources, Project Operations resource-mode) do not run on Dataverse natively — they have their own AX-lineage data model. Integration between F&O and Dataverse is through **Dual-write**, a real-time bidirectional sync that makes selected F&O entities available as Dataverse tables (and vice versa). The strategic direction is toward tighter Dataverse integration, but F&O is not "on Dataverse" in the way the CRM apps are.
## Environments
A Dataverse instance lives in an **environment** — a logical container with its own database, users, security roles, and app inventory. A tenant has a default environment (for personal productivity apps that shouldn't touch enterprise data) and however many additional environments the customer chooses to create for dev, test, production, and specific projects.
Environment strategy is one of the primary architecture decisions in a Dataverse deployment. Too few environments and dev / test / prod bleed into each other; too many and administration overhead multiplies. See the environment-strategy guide for the working patterns.
**Managed environments** is a paid tier that adds sharing controls, weekly usage reports, solution checker enforcement, and pipelines. Meant for organisations with a wider maker community that need centralised governance.
## Solutions and ALM
Every customisation of Dataverse — a new table, a modified column, a business rule, an app, a flow — is packaged into a **solution**. Solutions move between environments as unmanaged (editable in the destination, for dev use) or managed (locked, for test and production).
**Solution layers** show how multiple solutions interact when they touch the same object. **Solution checker** validates a solution before deployment. **Solution pipelines** deploy them from source to target through the Power Platform admin center or through Azure DevOps / GitHub Actions with the `pac` CLI. Deep solution-management skill is the primary technical craft in professional Dataverse work.
## The competitive picture
The most obvious comparison is to **Salesforce Platform** (the platform under Salesforce Sales Cloud and Service Cloud). Both are opinionated business-app platforms. Both have first-class metadata, security, business logic, and API surfaces. Salesforce Platform is more mature in some places (declarative development experience, deep ISV ecosystem); Dataverse wins on Microsoft 365 integration, on Copilot Studio integration, and increasingly on pricing for Microsoft-shop customers.
**Oracle APEX**, **ServiceNow platform**, and various low-code platforms (OutSystems, Mendix, Retool) share some concepts. None of them ship as the data foundation under a full Dynamics 365 CRM stack.
## Licensing
Dataverse is licensed by environment (database size, file storage, log storage) plus by user (Power Apps user licences, Dynamics 365 user licences that entitle users to specific tables). It is one of the more intricate pricing areas in Microsoft — worth reading the current licensing guide before committing.
Every Dynamics 365 licence includes rights to use the CRM-lineage app's Dataverse tables in custom apps and flows. Adding new custom tables that aren't part of the Dynamics 365 licence typically requires additional Power Apps licences.
## The short version
Dataverse is the relational data platform under the Dynamics 365 CRM apps and the Power Platform. Tables, columns, relationships, security, business logic, events, audit, REST API — all in one managed service. It is more than a database and less than a general-purpose PaaS; it is opinionated for building business apps quickly, governing them centrally, and integrating them with Microsoft 365 and Dynamics 365. If you build on Microsoft business apps, you spend time in Dataverse.
## Where to go next
Start with [data model fundamentals](https://www.solvingdynamics365.com/guides/dataverse-data-model-fundamentals) and [the security model](https://www.solvingdynamics365.com/guides/dataverse-security-model), then the logic layer in [plug-ins explained](https://www.solvingdynamics365.com/guides/dataverse-plug-ins-explained). The operational container is [Power Platform environments](https://www.solvingdynamics365.com/guides/power-platform-environments) and the deployment unit is [ALM with managed solutions](https://www.solvingdynamics365.com/guides/power-platform-alm-with-managed-solutions). When the API talks back, [Dataverse Web API errors](https://www.solvingdynamics365.com/guides/dataverse-web-api-errors-explained) decodes it.
### Frequently asked questions
**Is Dataverse just a database?**
No. It is a relational data platform with a layered security model, rich metadata, business rules, plug-ins, events, audit, full-text search, and a generated REST Web API. It runs on Azure SQL and other Azure primitives underneath, but you never touch those directly.
**What is the difference between Dataverse and the Common Data Service?**
Nothing beyond the name. Microsoft rebranded the Common Data Service to Dataverse in 2020 and repositioned it as the shared data foundation for the whole Power Platform, not just the Dynamics 365 CRM apps.
**Do the Finance and Operations apps run on Dataverse?**
No. Finance, Supply Chain Management, Commerce, and Human Resources have their own AX-lineage data model. Selected entities are exposed to Dataverse through dual-write, and Microsoft's direction is tighter integration, but F&O is not on Dataverse the way Sales or Customer Service is.
**Does a Dynamics 365 licence cover custom Power Apps on Dataverse?**
It covers custom apps and flows that use the licensed app's own tables. Adding new custom tables that are not part of the Dynamics 365 licence typically requires additional Power Apps licences — check the current licensing guide before assuming.
**What are elastic tables and virtual tables?**
Elastic tables are NoSQL-style storage for high-volume workloads such as telemetry and logs, with different consistency guarantees but the same API. Virtual tables surface data that stays in its source system — SQL, a REST API, SharePoint — as if it were a Dataverse table, so you do not have to replicate it.
---
# What is the Power Platform?
Microsoft's low-code platform — Power Apps, Power Automate, Power BI, Power Pages, Copilot Studio, and Dataverse.
Source: https://www.solvingdynamics365.com/guides/what-is-power-platform
Section: Power Platform
Published: 2026-08-27
Updated: 2026-08-27
The Microsoft Power Platform is a low-code application platform that pairs a suite of maker products with a shared data foundation. The maker products are **Power Apps** (business applications), **Power Automate** (workflow automation), **Power BI** (analytics), **Power Pages** (external-facing web experiences), and **Copilot Studio** (conversational AI agents). The shared foundation is **Microsoft Dataverse** — a relational, secure, enterprise-managed data service.
Dynamics 365's CRM-lineage apps (Sales, Customer Service, Field Service, Marketing, Customer Insights, Project Operations) are themselves built on the Power Platform. They ship as pre-configured Power Apps on top of Dataverse. This is not marketing framing — it is architecturally true — and it is why extending Dynamics 365 uses exactly the same tools a maker would use for a fresh Power Apps build.
## The five maker products
**Power Apps** builds business applications in two flavours. **Model-driven apps** generate a functional data-centric UI from Dataverse metadata — the pattern Dynamics 365 CRM apps use, right for record-heavy processes with security roles and complex forms. **Canvas apps** are drag-and-drop pixel-perfect designs backed by a spreadsheet-like formula language (Power Fx), right for task-specific workflows that need a bespoke UI.
**Power Automate** runs workflows. **Cloud flows** trigger from events (a record change in Dataverse, an email arriving, a form submitted, a schedule) and run steps against 500+ connectors. **Desktop flows** are RPA — a bot that drives a Windows UI when there is no API — increasingly overtaken by the API-first world but still important for legacy systems. **Business process flows** are the guided-process flavour used inside model-driven apps to shepherd a user through Qualify → Develop → Propose stages.
**Power BI** is the enterprise BI product — semantic models over Fabric, Dataverse, SQL, files, everything. It sits inside the Power Platform brand but is really its own product with its own licence economy and its own admin surface; the overlap is that Dataverse is a first-class data source and that Power BI reports embed into Power Apps and dashboards.
**Power Pages** builds external-facing websites — customer portals, partner portals, self-service forms — with Dataverse as the back end and its own authentication (Entra External ID, Azure B2C, local accounts). It is the descendant of the older **Power Apps Portals** product, rewritten in a modern design experience.
**Copilot Studio** builds conversational AI agents — chatbots and Teams-native agents that reason over instructions, tools, and knowledge. It is the successor to Power Virtual Agents; the redesign around Copilot happened in 2024 and continues.
## Dataverse
Dataverse sits under the maker products. It is a relational data service with an enterprise-grade security model (role-based, row-level, hierarchical, field-level), a rich metadata layer (tables, columns, relationships, choice sets, business rules), and a scalable transactional storage engine.
Every Power Platform environment ships with a Dataverse instance. A Dynamics 365 tenant's Dataverse is the same Dataverse that hosts custom Power Apps — with the pre-built Dynamics 365 tables layered on top. That means a custom Power App can add a table that relates to the Account table and it will show up on Account forms in Sales — no integration involved.
The extended Dataverse family includes **elastic tables** (NoSQL-style storage for high-volume append workloads), **virtual tables** (federated data staying in its source system), **file/image columns** (blob storage attached to records), and **Dataverse for Teams** (a lightweight Dataverse that ships free inside Teams). All share the same programming model.
## Environments and governance
A Power Platform tenant is organised into **environments** — logically separated containers, each with its own Dataverse, security roles, users, and app inventory. The typical setup is a development environment, one or more test environments, and production, mirroring the classic ALM structure. A **default environment** exists for personal productivity apps that shouldn't touch enterprise data.
**Managed environments** is a paid tier that adds sharing controls, weekly usage reports, solution checker enforcement, and pipelines. It's designed for organisations that want central IT visibility over a wide maker community, not for a small dev-only footprint.
**Data Loss Prevention (DLP) policies** categorise every connector as Business, Non-Business, or Blocked, and prevent a flow or app from combining connectors across categories. This is the primary governance lever — set it right and low-code makers can't accidentally exfiltrate Dataverse data to a personal Dropbox.
## ALM
Power Platform applications ship as **solutions** — packaged units of tables, apps, flows, security roles, and dependencies that move between environments. Solutions come in two flavours: **unmanaged** (editable in the destination environment, used in dev) and **managed** (locked in the destination, used in test and production).
**Power Platform Pipelines** is the newest and simplest deployment path — a checklist-driven promotion from dev to prod inside the Power Platform admin center. For heavier ALM there is **Power Platform Build Tools** for Azure DevOps and **GitHub Actions for Power Platform**, both wrapping the same `pac` CLI. Larger tenants that want a full ALM discipline use the CLI + Actions or DevOps combination.
## The AI layer
Every product in the platform has a Copilot inside it. **Copilot in Power Apps** turns natural-language descriptions into apps, tables, and formulas. **Copilot in Power Automate** does the same for flows. **Copilot in Power BI** authors DAX and describes visuals. **Copilot Studio** is itself the AI-agent building product.
Underneath, **AI Builder** provides pre-built AI models (form processing, sentiment, text translation, custom prediction) that flows and apps can call as steps — a lower-code alternative to calling Azure Cognitive Services directly.
## Licensing shape
Licensing is intricate and changes frequently. In broad strokes: Power Apps is licensed per app or per user, Power Automate per user or per flow, Power BI per user (Pro, Premium Per User) or per capacity, Power Pages per site with anonymous/authenticated user metering, Copilot Studio per message pack. Dataverse consumption (storage and API calls) is metered against the tenant.
Every Dynamics 365 licence includes rights to use the CRM-lineage app's own Dataverse tables inside custom apps and flows. Extending Dynamics 365 with a custom app that uses only Dynamics tables typically does not need an additional Power Platform licence; a custom app that adds new Dataverse tables usually does. Always check the licensing guide before assuming.
## Where the platform starts and ends
Power Platform is a low-code platform. It optimises for time-to-first-app, integration breadth, and delegation to Dataverse's transactional engine. It is not a pro-code IDE, not a raw ML platform, and not a general-purpose Kubernetes runtime — for those, Azure sits alongside it (Azure Functions, Azure ML, AKS).
The right mental model: Power Platform is the delivery layer for business applications and automations that need to be built quickly, governed centrally, and integrated with Microsoft 365 and Dynamics 365. Azure is the platform for everything more ambitious than that.
## Where to go next
Next reads: [Power Platform environments](https://www.solvingdynamics365.com/guides/power-platform-environments) for the operating model, [canvas apps vs model-driven apps](https://www.solvingdynamics365.com/guides/canvas-apps-vs-model-driven-apps) for the first build decision, [flow design patterns](https://www.solvingdynamics365.com/guides/power-automate-flow-design-patterns) for automation, [DLP policies](https://www.solvingdynamics365.com/guides/dlp-policies-in-power-platform) for governance, and [Copilot Studio for Dynamics 365](https://www.solvingdynamics365.com/guides/copilot-studio-for-dynamics-365) for agents. Licence costs are on the [Power Apps](https://www.solvingdynamics365.com/pricing/power-apps) and [Power Automate](https://www.solvingdynamics365.com/pricing/power-automate) pricing pages.
### Frequently asked questions
**What are the five Power Platform products?**
Power Apps (business applications), Power Automate (workflow and RPA), Power BI (analytics), Power Pages (external-facing websites), and Copilot Studio (conversational AI agents), all sharing Microsoft Dataverse as their data foundation.
**Is Dynamics 365 built on the Power Platform?**
The CRM-lineage apps — Sales, Customer Service, Field Service, Customer Insights, Project Operations — genuinely are: they ship as pre-configured model-driven apps on Dataverse. That is why extending them uses the same tools a maker would use for a brand-new Power App.
**What is a DLP policy in Power Platform?**
A Data Loss Prevention policy classifies every connector as Business, Non-Business, or Blocked and prevents a flow or app from combining connectors across groups. It is the primary governance lever against makers accidentally moving Dataverse data into personal services.
**What are managed environments?**
A paid tier that adds sharing controls, weekly usage reports, solution checker enforcement, and pipelines. It is meant for organisations governing a wide maker community, not for a small dev-only footprint.
**When should I use Azure instead of the Power Platform?**
For anything that is not a business application or automation: pro-code services, raw machine learning, or container runtimes. Power Platform optimises for time-to-first-app, connector breadth, and central governance; Azure Functions, Azure ML, and AKS sit alongside it for everything more ambitious.
---
# WhatsApp and SMS channels in Customer Service
How to set up and operate WhatsApp Business and SMS in Dynamics 365 Customer Service — provisioning, agent experience, and compliance.
Source: https://www.solvingdynamics365.com/guides/whatsapp-and-sms-channels-in-customer-service
Section: Customer Engagement / Customer Service
Published: 2026-05-01
For growing slices of the customer base, WhatsApp and SMS aren't *secondary* channels — they're the primary ones. Many customers prefer messaging over calls or emails, and customer service organisations that don't meet them on these channels lose the relationship. Dynamics 365 Customer Service supports both natively as part of the omnichannel stack.
## WhatsApp Business
Microsoft offers WhatsApp Business integration through:
- **WhatsApp Cloud API** (Microsoft's direct integration, recommended for new tenants).
- **WhatsApp via Infobip, Twilio, or other BSPs (Business Solution Providers)** — partner connectors.
**Provisioning WhatsApp.**
1. Acquire a WhatsApp Business phone number (separate from any personal WhatsApp number) through Meta Business Manager.
2. Verify the business through Meta's verification process (required for WhatsApp Business API access).
3. Configure the WhatsApp number in Dynamics 365's omnichannel admin.
4. Define operating hours, routing rules, agent capacity for the channel.
5. Set up message templates — Meta requires pre-approved templates for outbound messages (proactive outreach to customers).
## WhatsApp message templates
WhatsApp Business has strict rules about *who initiates* contact. Customers can message the business freely; the business can only respond within a 24-hour window after the customer's last message. Outside that window, the business can only send pre-approved **message templates** (greeting, appointment reminder, order update, etc.). Templates go through Meta approval and can take days. Plan for this.
## SMS
SMS is more straightforward — most countries have local SMS regulations, but the operational mechanics are similar:
- **SMS provider** — Azure Communication Services, Twilio, Infobip, or country-specific carriers.
- **Sender number** — short code (high-volume marketing) or long code (transactional, conversational).
- **Two-way capable number** — required if customers can reply.
## The agent experience
Once configured, WhatsApp and SMS conversations route through Unified Routing like other channels. The agent sees them in their Customer Service workspace alongside chats, voice calls, and emails, with the same productivity pane, conversation history, and Copilot assistance. Conversation summarisation, suggested replies, and knowledge articles work the same way.
## Identity binding
Inbound WhatsApp / SMS messages identify the customer by phone number. The platform matches the phone number to a Dataverse contact; unmatched numbers prompt the agent to create or link the contact. Persistent conversation history binds future messages from the same number to the same contact automatically.
## Rich media
WhatsApp supports images, videos, audio messages, documents, locations, and structured cards. SMS supports text only (and MMS where carriers allow). Build conversation patterns around what each channel can carry.
**Compliance.**
- **Customer opt-in** — both WhatsApp Business and most SMS regulations (GDPR, TCPA in the US, equivalent rules elsewhere) require explicit customer consent before outbound messaging. Capture and audit consent.
- **Opt-out** — every outbound message includes an opt-out instruction; the platform must honour opt-out immediately.
- **Record retention** — messages are stored as Dataverse records; retention policy applies per regulatory requirements.
**Common pitfalls.**
- **WhatsApp template approval lag** — partner templates often need editing before Meta approval. Plan launch with buffer.
- **Conflating personal numbers** — agents using personal WhatsApp for business breaks audit, doesn't route, doesn't track. Always use the official business channel.
- **SMS cost surprise** — high-volume SMS bills can be substantial. Monitor consumption.
## Operational reality
WhatsApp and SMS adoption improves customer satisfaction measurably in many demographics — but requires the same discipline as any service channel. Train agents, monitor response time, capture consent, comply with regulations.
---
# Withholding tax in Dynamics 365 Finance
How F&O handles withholding tax — vendor and customer-side configurations, country variations, and the integration with payments and reporting.
Source: https://www.solvingdynamics365.com/guides/withholding-tax-in-f-and-o
Section: Finance & SCM / Finance
Published: 2026-05-01
**Withholding tax** is the practice of deducting tax from a payment at source and remitting it directly to the tax authority on behalf of the recipient — common for cross-border payments, professional services, dividends, royalties, and certain domestic transactions. Dynamics 365 Finance supports withholding tax in detail because the requirements vary substantially by country and transaction type.
## The concept
When Company A pays a foreign service provider (or a domestic supplier in jurisdictions that require it), instead of paying the full invoice amount and the provider declaring tax in their own jurisdiction, Company A *withholds* a tax amount and remits it directly to its own tax authority. The provider receives the net amount; the tax authority gets the withheld portion; documentation flows so the provider can claim the withheld amount as tax paid in their own jurisdiction.
**Use cases.**
- **Cross-border services** — payments to foreign consultants, technology licences, royalties.
- **Domestic professional services** — many countries (India, Brazil, Argentina, Mexico, Philippines, Indonesia, others) require withholding on domestic invoices to professionals or specific industries.
- **Dividends and interest** — typically withholding applies to outbound payments to foreign shareholders / lenders.
- **Subcontractor payments** — UK's CIS (Construction Industry Scheme) withholds tax from subcontractors.
**Setup in F&O.**
- **Withholding tax codes** — define the rate, calculation, and tax-authority destination for each type of withholding.
- **Withholding tax groups** — combinations of codes for cascaded or layered withholding (some countries layer multiple withholdings on the same transaction).
- **Item / service classification** — which goods or services are withholding-eligible.
- **Vendor configuration** — flag vendors as subject to withholding, with the applicable group.
- **Customer configuration** — for customer-side withholding (where the *customer* is required to withhold from the seller's invoice).
- **Country-specific localisations** — the country localisation typically pre-configures the standard withholding regimes.
**The transaction flow.**
1. **Invoice received** — the full invoice amount is recorded as vendor liability.
2. **Payment proposed** — the payment routine identifies the withholding requirement, calculates the withheld amount, splits the payment:
- Vendor receives invoice amount minus withholding.
- Withholding amount books to a tax-payable account.
3. **Payment posted** — both legs post: payment to vendor, withholding liability to tax authority.
4. **Periodic remittance** — accumulated withholding is paid to the tax authority on the schedule the regulator requires (monthly, quarterly).
5. **Withholding certificate** — the vendor receives a certificate documenting the withheld amount for their tax claim.
**Country-specific complications.**
- **India TDS** (Tax Deducted at Source) — multiple withholding categories with thresholds, exemptions, certificates (Form 16A), and quarterly returns (Form 26Q, 27Q).
- **Brazil IRRF, PIS, COFINS, INSS, ISS** — multiple cascaded withholdings on the same invoice with different rates, bases, and recipients.
- **UK CIS** — subcontractor classification (Gross, Net 20%, Net 30% with no verification) and monthly returns.
- **Argentina** — multiple federal and provincial withholdings; complex.
- **US 1099 reporting** — not withholding per se, but annual reporting of payments to certain vendors; similar configuration model.
The country-specific complications are why country localisations matter — getting the engine right requires deep regulatory knowledge.
**Documentation.**
- **Withholding certificates** — issued to vendors documenting the amount withheld. Templates per country.
- **Periodic returns** — generated through Electronic Reporting (Globalization Studio) per country format.
- **Annual summaries** — for tax authorities and for vendors' year-end tax claims.
**Common pitfalls.**
- **Vendor not flagged for withholding** — invoice paid in full, withholding missed, penalty risk.
- **Wrong withholding rate applied** — under-withholding causes liability; over-withholding causes vendor disputes.
- **Threshold rules not respected** — some withholdings only apply above thresholds; below, no withholding required.
- **Exemption certificates not honoured** — vendors with exemption certificates shouldn't have withholding applied.
- **Certificate generation skipped** — vendors require certificates for their own tax claims.
## Operational reality
Withholding tax is one of the most country-specific areas of F&O. Engage local tax expertise during setup; partner with a localisation specialist for the country; review setup annually as regulations change.
---
# Work in progress (WIP) and recognition for projects in Business Central
How Business Central recognises revenue and cost on projects — the four WIP methods, completion percentages, and how WIP entries hit the general ledger.
Source: https://www.solvingdynamics365.com/guides/wip-and-recognition-for-jobs-in-bc
Section: Business Central / Service & projects
Published: 2026-05-01
Projects in Business Central (formerly Jobs) capture revenue and cost across a span of time. Until completion, accounting standards usually require some form of **work in progress (WIP)** recognition — moving incurred costs out of P&L into a balance sheet account and recognising revenue based on percentage of completion. BC handles this through the **WIP** calculation engine on the Project Card.
## The four WIP methods
On each project, the `WIP Method` field selects how WIP is computed:
- **Cost Value** — recognises cost based on percentage of completion; revenue follows separately.
- **Sales Value** — recognises revenue and cost in proportion to billable progress.
- **Cost of Sales** — recognises cost matched to invoiced amounts.
- **Percentage of Completion** — recognises both revenue and cost at the calculated completion %.
- **Completed Contract** — defers everything to completion.
The choice depends on the contract type (fixed price, time and material, milestone) and the accounting policy. Service firms usually use Percentage of Completion or Sales Value; construction firms often use Completed Contract for shorter projects and Percentage of Completion for longer ones.
## WIP postings
WIP doesn't change Project Ledger Entries directly; it creates G/L entries against:
- **WIP Cost Account** — balance sheet inventory-like account holding incurred-but-unrecognised cost.
- **Recognised Costs Account** — P&L cost as recognised by the WIP method.
- **WIP Sales Account** — balance sheet account holding billed-but-unearned revenue (when invoicing exceeds recognised revenue), or earned-but-unbilled (the reverse).
- **Recognised Sales Account** — P&L revenue as recognised.
The journal pattern is symmetric: at every WIP run, BC reverses prior WIP entries and posts current values; the net movement reflects the period's earned revenue and cost.
## Running WIP
The `Project Calculate WIP` action computes WIP per project, optionally per task. The `Project Post WIP to G/L` action posts the calculated values to the general ledger. Most teams run these as monthly close steps. Important: WIP entries reverse and re-post each period — the WIP G/L balance is always "the current cumulative WIP value", not an accumulation of period entries.
## Completion %
For methods that depend on completion %:
- **Cost-based completion** — actual cost to date / estimated total cost. The `Cost Completion %` field on the project card.
- **Schedule-based** — manually entered or driven by milestone task statuses.
- **Quantity-based** — actual quantities posted / planned quantities, summed across tasks.
The estimated total cost must be maintained continuously; a project where the estimate hasn't been updated for six months will show wrong WIP regardless of method.
## Project tasks and WIP totals
WIP can be calculated at the **task** level — each task carries its own `WIP Method` and accounts. This matters for projects with mixed-type tasks (a fixed-price phase followed by a time-and-material phase). The project header's WIP is the sum across tasks.
## Recognising milestones
For milestone billing, the typical setup is:
- Task `WIP Method` = `Completed Contract`.
- A task `WIP Total` field equal to the milestone amount.
- The milestone task is marked complete only when the milestone is achieved.
- WIP recognises 100% of that task's revenue at completion.
## WIP and invoicing decoupled
A project might be invoiced ahead of work (deposit, milestone billed early) or behind work (T&M billed in arrears). WIP accounts capture the timing difference:
- Invoiced more than recognised → liability balance (deferred revenue) on `WIP Sales`.
- Recognised more than invoiced → asset balance (accrued revenue) on `WIP Sales`.
The WIP sales account thus carries both directions depending on the project. Some teams split into two accounts (`Deferred Project Revenue`, `Accrued Project Revenue`) for cleaner balance sheet presentation, but BC's standard logic uses one.
**Common pitfalls.**
- **Stale estimates.** Estimated total costs not updated → completion % wrong → WIP wrong.
- **WIP not posted.** Calculation runs but post step forgotten; P&L shows incurred cost, no recognised revenue.
- **Mixed WIP methods on one project.** Result is hard to audit; standardise by project type.
- **Closing a project before final WIP.** Final WIP needs to reverse all balance sheet WIP and recognise everything to P&L. If the project is set to status `Completed` before WIP is run one last time, balance sheet WIP stranded.
## Audit and disclosure
WIP balances are scrutinised in audits — overstating WIP overstates assets and revenue. Auditors look for:
- Aged WIP balances (project hasn't moved for 12 months — write off?).
- Negative WIP that doesn't match a billing-ahead pattern.
- Inconsistency between estimated costs and actuals trending.
A clean monthly WIP close, with reviewed estimates and a documented method per project, makes the audit fast.
---
# Work order lifecycle in Dynamics 365 Field Service
How a work order flows from creation through scheduling, dispatch, technician execution, and invoicing in Dynamics 365 Field Service — the statuses.
Source: https://www.solvingdynamics365.com/guides/work-order-lifecycle-in-field-service
Section: Customer Engagement / Field Service
Published: 2026-05-01
The **work order** is the core operational record in Dynamics 365 Field Service. Everything — schedules, technician dispatch, parts consumption, customer billing — revolves around the work order's lifecycle. A clean lifecycle is the difference between a smooth field operation and constant firefighting.
**Where work orders originate.**
- **Manually created** by a dispatcher or customer service agent.
- **From a case** — service escalation creates a related work order.
- **From an asset** — preventive maintenance schedules generate work orders automatically.
- **From IoT alerts** — connected device anomalies create work orders.
- **From a service agreement** — recurring scheduled visits.
- **Self-service portal** — customer requests via Power Pages.
The work order's source informs its priority, routing, and SLA expectations.
**Work order anatomy.**
- **Work Order Number** — unique identifier.
- **Service Account / Billing Account** — who's served, who's billed.
- **Customer Asset** — the equipment being serviced.
- **Work Order Type** — installation, maintenance, repair, inspection.
- **Status** — system status (Open – Unscheduled, Open – Scheduled, In Progress, Completed, Closed).
- **Sub-status** — granular reasons.
- **Priority** — High/Medium/Low.
- **Service Territory** — geographic assignment.
- **Date Window From/To** — when work must happen.
- **Incident Types** — what specifically needs doing.
- **Service Tasks** — checklist items.
- **Products** — parts consumed or to be used.
- **Services** — labour line items.
**The lifecycle.**
1. **Created** — work order exists; not yet scheduled.
2. **Scheduled** — a resource and time slot assigned (manual or auto via Resource Scheduling Optimization).
3. **In Progress** — technician en route or on site, time tracked.
4. **Completed** — technician finished; service report generated.
5. **Closed - Posted** — final review by office; products and services posted to inventory and billing.
6. **Invoiced** — billing generated.
Some lifecycles compress (no formal "posted" stage); others extend (intermediate "Customer Approval" before posting).
## Bookings and scheduling
The link between a work order and a resource is a **booking**. Bookings have their own status:
- **Scheduled** — assigned, not started.
- **Travelling** — technician en route.
- **On Site** — arrived.
- **In Progress** — working.
- **Completed** — finished.
Bookings can be split (technician on site for 4 hours but lunch break in middle) and rescheduled.
## Scheduling assistant
Dispatcher uses the Schedule Board to:
- See open work orders requiring scheduling.
- Drag onto resources / time slots.
- Apply constraints (skills, territory, certifications).
- Optimise routes manually or with Resource Scheduling Optimization (RSO).
RSO automates this with ML-based optimisation considering travel, skills, urgency.
## Technician execution
Field technicians use the **Field Service mobile app**:
- See assigned bookings.
- Tap to start travelling; arrive; start work.
- Complete service tasks.
- Capture photos.
- Record parts used and labour.
- Customer signature.
- Submit service report.
The mobile app works offline — bookings sync down, completed data syncs up when connectivity returns.
## Service reports
A summary of the work performed, parts used, time spent, customer signature. Emailed to the customer; saved on the work order. Some industries require structured reports (regulated compliance, warranty); the report template generates accordingly.
## Inventory and parts
Parts consumed:
- Pulled from technician's truck stock (a sub-warehouse).
- Posted as inventory consumption.
- May trigger replenishment (truck restock).
- Costed to the work order.
Truck inventory is mini warehouse management — without discipline, parts walk away.
## Billing
Most work orders bill the customer:
- **Time and materials** — invoice for actual hours + parts.
- **Fixed price** — pre-quoted amount regardless.
- **Warranty** — covered by warranty, no customer charge.
- **Service contract** — covered by contract, no charge.
Billing rules on the work order determine which model applies; invoice generation follows posted work orders.
## Service agreements and preventive maintenance
Recurring work orders generated automatically:
- **Service agreement** — annual or quarterly contract.
- **Maintenance plan** — defines schedules per asset.
- **Auto-generation** — system creates work orders ahead of due date.
- **Routing** — auto-scheduled to appropriate territories.
This generates the maintenance volume that fills the dispatcher's schedule.
**Common pitfalls.**
- **Unscheduled work order backlog.** Created but not scheduled; aging fast.
- **No closure discipline.** Completed work orders never posted; reporting wrong; revenue not recognised.
- **Parts not captured.** Technician forgot to log; inventory wrong; billing low.
- **Service report not sent.** Customer doesn't see what was done; disputes follow.
- **Wrong work order type.** "Repair" used when it should be "Warranty Repair"; billing wrong.
- **Schedule board overcrowded.** Too many open work orders without filtering; dispatcher overwhelmed.
## Quality and feedback
Post-completion:
- Customer survey (Customer Voice integration).
- Net Promoter Score (NPS) per technician, per work order type.
- Coaching feedback flows back to technicians.
## Strategic positioning
Field Service work orders bridge several domains — service operations, inventory, billing, scheduling, customer experience. Discipline at every transition makes the chain efficient; gaps anywhere cascade. The most mature field service operations have clear status definitions, clean handoff procedures, and dashboards that surface stuck or aging work orders before they become customer issues.
---
# Workflow in Dynamics 365 Finance
The workflow engine in Dynamics 365 Finance and SCM — designers, conditions, assignment, escalations, and Power Automate alternatives.
Source: https://www.solvingdynamics365.com/guides/dynamics-365-finance-workflow
Section: Finance & SCM / Finance
Published: 2026-05-01
The Finance and Operations workflow engine is the routing and approval framework for almost every transactional document — purchase requisitions, purchase orders, vendor invoices, journals, project quotations, expense reports, time sheets. Every Finance/SCM implementation configures dozens of workflows; knowing the engine's shape saves a lot of rebuilds.
## Workflow types
Each business document has a *workflow type* — a definition Microsoft ships per area (Vendor Invoice Workflow, Purchase Requisition Workflow, etc.). A workflow type defines which tasks, approvals, and conditional decisions are valid for that document. Customers create one or many workflow *instances* of each type, with different conditions to route to different approver chains.
## Designer
The graphical workflow designer runs inside Finance/SCM, drag-and-drop, with elements:
- **Manual decisions** — branch based on a condition (e.g. amount > 50,000).
- **Approvals** — one or more approval steps, each with a defined approver (a named user, a hierarchy lookup, a workflow user, a position-based lookup).
- **Tasks** — actions assigned to a user that aren't approvals (e.g. "verify supporting documents").
- **Automated tasks** — server-side actions (e.g. "apply default dimensions") that run without human interaction.
- **Parallel branches** — multiple paths running concurrently with a join.
## Approver resolution
Approvers can be resolved by:
- **Hierarchical**: walk up the position hierarchy until an approver with sufficient authority is found.
- **Named approver**: a specific user.
- **Workflow user**: a user selected from a configured list.
- **Limits**: signing limits per position drive how far up the hierarchy a document escalates.
## Conditions
Workflow steps can be gated by **conditions** expressed in a simple query against document fields and dimensions. Conditions are why a 5,000-EUR invoice routes one way and a 500,000-EUR invoice routes another.
## Escalation
Each step has an escalation policy — if the approver doesn't act in N days, the step reassigns or notifies. This is the saving grace of workflows that get stuck on leave.
## Delegation
Users delegate their workflow inbox to a substitute during absences.
## Power Automate alternatives
For workflows that need to reach outside Finance/SCM, customers increasingly use **Power Automate** approvals flows triggered by Dataverse changes (via virtual entities or Dual-write). The pattern: lightweight transactional approvals stay in F&O; cross-system or external-stakeholder approvals move to Power Automate.
## Operational reality
Heavy workflow proliferation slows performance and clouds audit. Aim for ten well-designed workflows, not fifty quick ones.
---
# Writing your first AL extension
A first-walkthrough of building, publishing, and running a basic AL extension for Business Central — toolchain, project structure, and deployment.
Source: https://www.solvingdynamics365.com/guides/writing-your-first-al-extension
Section: Business Central / AL & development
Published: 2026-05-01
Updated: 2026-08-31
This is the developer first-walkthrough. Setting up the environment is the most fiddly part; the AL itself is straightforward.
## Toolchain
Install **Visual Studio Code** and add Microsoft's **AL Language** extension from the marketplace. That installs the AL compiler, language services, and debugger. You'll also want **Git** (for version control) and either a **Docker** environment for on-premise development or — far more common — a **Business Central sandbox** in your Microsoft 365 tenant for cloud development.
## Sandbox
From the Business Central admin centre, create a new sandbox environment. Note its name, tenant ID, and the sandbox URL. The sandbox is free, fresh out of the box, and has demo data you can throw away.
## Project
In VS Code, run `AL: Go!` from the command palette. Pick *Microsoft cloud sandbox*. Sign in with your tenant admin. The command scaffolds a new AL project folder with `app.json` (manifest), `launch.json` (debug configuration), and a sample `HelloWorld.al` page extension that adds a button to the Customer List.
## Compile and run
Press F5. VS Code downloads symbols (Microsoft's compiled metadata for the platform and base app), compiles your extension, publishes it to the sandbox, and opens the sandbox URL on the Customer List. Your new action appears in the ribbon; clicking it runs your AL.
## Make it your own
Replace the boilerplate with something useful. A common first step: a **page extension** that adds a custom field to the customer card, plus a **table extension** that adds the underlying column. Save, F5 again, see it live.
## Codeunit and event subscriber
Next, add a codeunit with an event subscriber. Subscribe to `OnAfterInsertEvent` of the Customer table and write a debug log entry. Press F5; create a customer; see the log fire. You've now written extension behaviour that hooks into Microsoft's code without modifying it — the upgrade-safe pattern.
## The app.json fields that actually matter
The manifest looks like boilerplate but three fields deserve attention on day one. **`idRanges`** declares which object IDs your extension may use — 50000–99999 is the customer range for per-tenant work; pick a slice and document it, because two extensions claiming the same IDs cannot coexist in one environment. **`id`, `publisher`, `name`, `version`** together identify the app; change the `id` GUID and BC treats it as a different app entirely, orphaning the old one's data. And **`dependencies`** lists other apps whose objects you reference — the compiler enforces it, and getting the dependency graph right early saves grief when you later split functionality across apps. While you're in there, set `"features": ["NoImplicitWith"]` behaviour aside — modern scaffolds handle it — but do turn on the **CodeCop / UICop / PerTenantExtensionCop** analyzers in settings; they teach you the platform's rules as warnings instead of AppSource rejections.
## When F5 doesn't work
The first-session failures are predictable. *Symbols won't download*: usually a sign-in against the wrong tenant or environment name in `launch.json` — check `environmentName` matches the sandbox exactly. *"Object ID already in use"*: another extension (often an abandoned earlier attempt) claims the range — uninstall it from Extension Management or change your range. *Publish succeeds but nothing visible*: you're in a different company, or the page extension targets a page the role centre doesn't surface — navigate to the page directly by search. None of these mean anything is broken; they're the toll for the first afternoon.
## Source control
Initialise a Git repo. Commit early. The `app.json` and source files are everything you need — there is no binary state worth keeping outside Git, and the `.alpackages` symbol cache belongs in `.gitignore`.
## From Hello World to something deployable
The sandbox F5 loop publishes a **development-scope** extension, which is for exactly this: iterating. Getting code into a real environment is a different act — a **per-tenant extension** uploaded through Extension Management (or better, deployed by a pipeline), with a version number that increments and a schema BC will hold you to. Two habits to build before your first real deployment: never delete a field or object that has shipped (mark it obsolete instead — schema removal breaks upgrade), and add a **permission set object** to the app so admins can grant access without hand-crafting permissions. The wider structure — dependencies, affixes, when to split apps — is covered in [AL extensions architecture](https://www.solvingdynamics365.com/guides/al-extensions-architecture).
## Next steps
Read Microsoft Learn's AL language reference; experiment with permission sets, translations, and dependencies; write a first test codeunit against the [AL test framework](https://www.solvingdynamics365.com/guides/al-test-framework); and look at the **AL-Go for GitHub** template, which turns the project into a build-and-deploy pipeline — the path described in [BC CI/CD with AL-Go](https://www.solvingdynamics365.com/guides/business-central-cicd-with-al-go). Event subscribers, the pattern from this walkthrough, scale into the platform's whole integration model; [AL events and integration patterns](https://www.solvingdynamics365.com/guides/al-events-and-integration-patterns) is the natural second read.
### Frequently asked questions
**What do I need to start AL development?**
Visual Studio Code with Microsoft's AL Language extension, Git, and a Business Central sandbox created from the admin centre. Run AL: Go! from the command palette to scaffold the project, then F5 downloads symbols, compiles, publishes, and opens the sandbox.
**Which app.json fields matter on day one?**
idRanges (50000–99999 is the per-tenant customer range; document your slice), the id GUID with publisher, name, and version (changing the id makes BC treat it as a different app), and dependencies. Turn on the CodeCop, UICop, and PerTenantExtensionCop analyzers in settings.
**Why does F5 fail on the first afternoon?**
Symbols will not download when the environmentName in launch.json does not match the sandbox; an Object ID already in use error means another extension claims the range; a successful publish with nothing visible usually means the wrong company or a page the role centre does not surface.
**What habits should be in place before the first real deployment?**
Never delete a shipped field or object — mark it obsolete, because schema removal breaks upgrade — and add a permission set object so admins can grant access. Keep .alpackages out of Git and move to a per-tenant extension deployed by a pipeline rather than the F5 development-scope loop.
---
# X++ — the language behind Dynamics 365 Finance and Operations
What X++ is, where it came from, and how it's used in F&O — language features, the application object tree.
Source: https://www.solvingdynamics365.com/guides/f-and-o-x-plus-plus-language
Section: Finance & SCM / AL & X++ development
Published: 2026-05-01
Dynamics 365 Finance and Operations runs on **X++** — a proprietary object-oriented language that's been the foundation of the AX / F&O product family since the 1990s. Modern X++ feels like a hybrid of Java, C#, and SQL; for developers extending F&O, learning X++ is the prerequisite for serious work.
## Origin
Born in the 1990s with Axapta (later acquired by Microsoft, becoming Dynamics AX, then Dynamics 365 F&O). Inspired by Object Pascal and Java; designed for business applications with native data access.
## Modern X++
As of F&O wave 2 2026:
- **Compiled to IL** — runs on .NET CIL after compilation.
- **Visual Studio development** — primary IDE; AOT (Application Object Tree) navigated visually.
- **Modern syntax** — closures, attributes, generics (limited).
- **Native SQL** — `select * from custTable where ...` works inline.
The language has evolved significantly; modern X++ is more Java/C#-like than its Pascal heritage.
**Core constructs.**
- **Classes** with inheritance.
- **Tables** as first-class objects (extending DataObject).
- **Views, queries, maps.**
- **Forms** with event-driven controllers.
- **Reports** (mostly legacy; SSRS for newer).
- **Workflows.**
- **Services.**
The Application Object Tree (AOT) is the namespace; all artefacts live in it organised by type.
**Native SQL.**
```x++
CustTable custTable;
select firstonly custTable
where custTable.AccountNum == '4000';
```
The `select` statement is integrated with the language; the compiler generates SQL.
## Table buffers
A table variable represents a row buffer:
```x++
CustTable custTable;
custTable.AccountNum = 'NEW001';
custTable.Name = 'New Customer';
custTable.insert();
```
`custTable` is a buffer; methods like `.insert()`, `.update()`, `.delete()` operate on the buffer's data.
**Extension model.**
- **Chain of Command (CoC)** — extension method wrappers around base methods.
- **Event handlers** — subscribe to pre/post events on base methods.
- **Table extensions** — add fields, methods, events to existing tables.
- **Form extensions** — add controls to existing forms.
No direct base code modification; extensions only. This enables Microsoft to update base code without breaking customisations.
**Visual Studio integration.**
- Visual Studio with F&O developer tools installed.
- Browse AOT, edit X++, compile, deploy.
- Debugger built in.
- Source control via Azure DevOps git.
The development experience has improved dramatically vs the old MorphX environment.
## Classes vs tables
Two distinct concepts:
- **Class** — code logic, business rules.
- **Table** — data storage.
A class operates on table buffers; a table can have methods too but typically lightweight.
## The macro system
X++ has a C-like preprocessor:
```x++
#define.MaxLength 100
```
Used heavily in older code; less in modern. Macros pollute namespaces and are deprecated for most uses.
## Currency and value handling
Built-in types for financial data:
- **Real** — decimal numbers.
- **Currency** — currency-aware decimals.
- **Amount** — financial amounts with currency.
Plus rounding helpers, conversion functions; financial math is first-class.
**Common patterns.**
**Iterate records:**
```x++
while select custTable
where custTable.CustGroup == 'PREMIUM'
{
info(strFmt("Customer: %1", custTable.Name));
}
```
**Insert with transaction:**
```x++
ttsbegin;
CustTable.insert();
ttscommit;
```
**Method call with exception:**
```x++
try {
someMethod();
}
catch {
error("Something failed");
}
```
**Performance considerations.**
- **Set-based vs record-based operations** — set-based much faster.
- **Index utilisation** — define indexes for common queries.
- **Cache hints** — `forupdate`, `notexistsjoin` for performance.
- **Batch processing** — for long operations.
**Modern X++ features.**
- **Closures** (anonymous methods).
- **Attributes** for metadata.
- **Reflection** via SysDictType, SysDictClass.
## Comparison with C#
X++ is similar to C# in many ways but:
- Less generic (limited generics).
- Native SQL integration.
- Domain-specific for ERP.
- Smaller community.
C# developers picking up X++ usually feel productive within weeks.
**Extension considerations.**
- **Sandboxed dev environments** — Tier 1 VMs.
- **Build server** — compiles and packages.
- **Deployment via LCS or Azure DevOps** — to upper environments.
The deployment story is more complex than BC's AL; F&O development is heavier infrastructure.
**Common pitfalls.**
- **Modifying base code.** Cardinal sin; updates break.
- **Heavy in-loop DB calls** — performance dies.
- **No transaction control.** Inconsistent state on errors.
- **Skipping CoC pattern** — using events when CoC is cleaner.
- **Macro overuse** — modern code prefers methods and constants.
## Strategic positioning
X++ is here to stay — F&O is built on it; replacing it would mean a rewrite of millions of lines of base application code. Microsoft continues to invest: modernisation each wave, better tooling, Copilot-assisted X++ development emerging. Developers committing to F&O development should treat X++ as a long-term investment; the language isn't going anywhere. Mastery requires the language plus the AOT plus the patterns; investment time is meaningful but the resulting capability is in demand.
---
# XRMToolBox and the Dataverse tooling ecosystem
The community-built tools that supplement Microsoft's Dataverse admin and developer experience — XRMToolBox, FetchXML Builder, and the indispensable plug-ins.
Source: https://www.solvingdynamics365.com/guides/xrmtoolbox-and-the-dataverse-tooling-ecosystem
Section: Customer Engagement / Dataverse platform
Published: 2026-07-18
Microsoft's official Dataverse tools — the maker portal, the Power Platform admin centre, the `pac` CLI, the Solution Checker — cover the basics well. But for serious Dataverse work, professionals universally reach for community-built tools, with **XRMToolBox** at the centre. This open-source ecosystem makes Dataverse genuinely productive for admins, developers, and consultants.
## XRMToolBox
A free Windows desktop application — open-source, maintained by the Dynamics community — that hosts hundreds of plug-in tools. Install once; connect to any Dataverse environment; load whichever tool you need for the task at hand.
The plug-in model is the strength: anyone can build a tool and contribute it; the community has produced an enormous catalogue covering every aspect of Dataverse work.
**Essential XRMToolBox tools.**
- **FetchXML Builder** — visually construct FetchXML queries with field pickers, condition builders, joins, aggregations. Generates the XML for use in views, reports, and plug-ins. Indispensable for anyone working with FetchXML.
- **Plugin Trace Viewer** — read the plug-in trace log with rich filtering and search. Far better than the built-in trace log viewer for debugging.
- **Plugin Registration Tool** — register, update, and configure plug-in assemblies. Microsoft's own tool; ships separately but is essential for plug-in developers.
- **Audit History Viewer** — read audit logs with filters and export. The platform's built-in audit views are basic; this tool is much more usable.
- **Bulk Data Updater** — perform bulk updates on Dataverse records via XML-defined operations. Avoids exporting to Excel, modifying, and re-importing.
- **Solution Compare** — diff two solutions to see what changed. Essential during merge / upgrade scenarios.
- **Easy Translator** — translate Dataverse field labels, view names, web resources for multi-language environments. Replaces the manual XML editing.
- **Ribbon Workbench** — visual designer for command bar / ribbon customisation. Pre-modern-designer but still useful for some scenarios.
- **Metadata Document Generator** — produce documentation of all tables, columns, relationships, security roles in an environment. Useful for handover and compliance.
- **Security Permissions Reporter** — analyse who can do what across security roles, teams, hierarchies.
- **CRM REST Builder** — construct Web API calls visually; copy the URL and headers for use in client code. Eliminates trial-and-error.
- **View Designer** — richer view-building UX than the standard Power Apps portal.
- **Real-time Workflow Tester** — trigger workflows on test records with controlled inputs; observe execution.
- **Solution History** — track who installed what solution when in an environment.
- **Field Usage Inspector** — analyse which custom fields are actually being used vs orphaned cruft.
- **Record Counter** — count records by table; useful for capacity planning and pre-go-live validation.
Dozens of others — for almost every Dataverse workflow, there's an XRMToolBox tool that makes it faster.
**Installing and connecting.**
1. Download XRMToolBox from the official site.
2. Install. The host app launches.
3. Add an environment connection — credentials, OAuth flow.
4. From the plug-in marketplace, install the tools you need.
5. Click a tool to open; tools share the host's connection.
The marketplace integrates with the GitHub-hosted source for each tool.
**Other community tooling.**
- **Power CAT tools** — Microsoft's customer-advisory-team has open-sourced several tools for governance, ALM, and inventory (the CoE Starter Kit is part of this lineage).
- **Power Platform Build Tools for Azure DevOps** — covered in the ALM guides; essential for CI/CD.
- **`pac` CLI** — Microsoft's command-line tool for Power Platform automation; not community but related.
- **Spkl Task Runner** — automated tasks for plug-in deployment, solution operations.
**Microsoft FastTrack tools.**
For FastTrack-eligible customers, Microsoft provides additional tools — performance analysers, telemetry workbooks, design review templates. Often deployed alongside community tools.
## The community
The Dataverse / Dynamics 365 community has been remarkably productive for over a decade. Conferences (Microsoft Business Applications Summit, Dynamics 365 user groups), forums (community.dynamics.com, Stack Overflow tags, Microsoft Learn), and the open-source tool ecosystem make Dataverse work feasible at scale.
## Why community tooling thrives
Microsoft's product tooling necessarily lags real-world needs — making everything in the official products would be expensive and slow. The community fills the gap: a developer writing a tool for one customer publishes it as XRMToolBox plug-in; it becomes the answer for thousands of similar customers.
**Common pitfalls.**
- **Tool sprawl** — installing dozens of plug-ins; navigation becomes overwhelming. Curate.
- **Plug-in version mismatches** — different plug-ins built against different Dataverse SDK versions can conflict. Update when needed.
- **Outdated plug-ins** — abandoned plug-ins for retired Dataverse features still install but don't work; check active maintenance.
## Operational reality
Anyone working seriously with Dataverse uses XRMToolBox daily. The investment in learning the ecosystem returns substantially across years of work. Treat it as part of the professional toolkit.
---
# Year-end close in Dynamics 365 Finance
How year-end close works in F&O — fiscal year closure, opening transactions, depreciation reset, ledger settlements, and the year-end ritual.
Source: https://www.solvingdynamics365.com/guides/year-end-close-in-f-and-o
Section: Finance & SCM / Finance
Published: 2026-05-01
Year-end close in Dynamics 365 Finance is the culmination of the financial cycle — the formal closing of one fiscal year, the rolling of profit-and-loss balances into retained earnings, and the opening of the new year. Done well, it's a structured ritual with predictable steps; done badly, it's a frantic month of corrections that delays everyone.
## Pre-close preparation
Before any year-end-specific steps, the year's final period must be fully closed:
- All accruals posted.
- All depreciation calculated and posted (final period plus catch-up).
- All FX revaluations run with year-end rates.
- All inventory closing completed (with year-end as the closing date).
- All project recognitions and WIP postings finalised.
- All AP / AR sub-ledgers reconciled to GL.
- All bank accounts reconciled.
- All intercompany reconciliations completed.
These are part of normal monthly close; year-end just demands they all happen for the final period without gaps.
## Opening transactions
A **closing transaction** posts on the last day of the fiscal year to capture the closing balances. Year-end specifically generates **opening transactions** on the first day of the new year — same balances but in the new year's books, ready to receive new postings.
F&O's **Year-end close** routine performs:
- **Closing of P&L accounts** — revenue and expense accounts close to zero by posting their balance to a **retained earnings** account (or multiple, per the chart-of-accounts configuration).
- **Opening of balance-sheet accounts** — asset, liability, and equity accounts roll forward at their closing values as opening values.
- **Closing transactions on dimensions** — if dimensions are tracked at year-end, closing transactions can carry them forward.
- **Fiscal year status update** — the closing year moves to *Closed* status; the new year is opened for posting.
**Closing methods.**
- **Detailed close** — closes all P&L accounts to retained earnings line by line, preserving the audit trail.
- **Summary close** — aggregates P&L into a single retained-earnings posting.
- **Reverse close** — for reopening a year if needed (rare; should require strong governance).
Most organisations use **Detailed close** for audit traceability.
## Fixed asset year-end
Fixed assets have their own year-end handling:
- **Depreciation books** roll forward — the current year's depreciation accumulates into the asset's accumulated depreciation; the new year's depreciation starts fresh.
- **Asset transactions** before year-end-closure date are locked; transactions after open in the new year.
- **Depreciation forecasts** for the new year can be generated for budgeting purposes.
## Project year-end
Projects don't have separate year-end ceremony, but year-end is when:
- Multi-year project budgets roll forward.
- WIP balances at year-end reflect the project's true financial state for statutory purposes.
- Outstanding project commitments carry into the new year.
## Inventory year-end
Inventory closing for the final fiscal period locks inventory transactions as of year-end. **Physical inventory counts** that happen near year-end produce the audit-ready inventory valuation. Some organisations do mid-year cycle counts to spread the workload.
## Intercompany at year-end
Multi-entity tenants reconcile intercompany balances rigorously at year-end. Each pair of entities must agree on:
- Open intercompany invoices and payments.
- IC sales and IC purchases.
- IC asset transfers.
- IC ledger settlements.
The reconciliation typically takes weeks before year-end and surfaces discrepancies that require correction journals before close.
## Statutory and audit
Year-end produces:
- **Financial statements** — balance sheet, P&L, cash flow, equity statement.
- **Notes and disclosures** — for statutory reporting.
- **Audit packages** — for external auditors.
- **Tax provision** — year-end tax accruals and corporate tax calculations.
- **Country-specific year-end filings** — VAT annual returns, corporate income tax, etc.
For multi-entity groups, **consolidation** at year-end produces group financial statements with eliminations and currency translation.
## Period and year permissions
After closure, posting in the closed year is restricted to specific user roles. Re-opening a closed year is possible but should require governance approval and trigger audit-trail events.
**Common pitfalls.**
- **Trying to close before reconciliations complete** — produces wrong opening balances; expensive to fix.
- **Forgetting subsidiary year-end alignment** — different fiscal years across entities create consolidation complexity.
- **Insufficient retained-earnings configuration** — wrong account picks, single retained-earnings for multi-dimension structures that need separate ones.
## Operational reality
Year-end is mostly a monthly close at scale. Disciplined monthly close means year-end isn't a special panic — it's just December's month-end plus the closing routine. Build the discipline year-round.
## Where to go next
The routines that recur every period are in [periodic processes in F&O](https://www.solvingdynamics365.com/guides/periodic-processes-in-f-and-o); the calendar they run against is [fiscal calendar setup](https://www.solvingdynamics365.com/guides/fiscal-calendar-setup-in-f-and-o). Sub-ledger year-ends are covered in [fixed assets in F&O](https://www.solvingdynamics365.com/guides/fixed-assets-in-f-and-o) and [consolidations in F&O](https://www.solvingdynamics365.com/guides/consolidations-in-f-and-o), and the reporting pack in [finance reporting tools](https://www.solvingdynamics365.com/guides/dynamics-365-finance-reporting-tools).
---
# Glossary
Source: https://www.solvingdynamics365.com/glossary
## Access team
Source: https://www.solvingdynamics365.com/glossary/access-team
An **access team** in Dataverse is a lightweight, dynamic team used for **ad-hoc record-level access**. Unlike **owner teams**, access teams can't own records and don't have security roles assigned. Instead, access teams grant specific privileges (Read, Write, Append, Share) on a *specific record* through **access team templates**. The classic pattern: auto-created access teams per record, populated via a subgrid on the form — adding a user to the opportunity's "Sales Team" subgrid auto-creates the access team and grants the user record-level access to that specific opportunity. Lightweight; ideal for deal teams, case escalations, project consultants getting per-engagement access. Membership changes per record as collaboration evolves.
## Accounts payable
Source: https://www.solvingdynamics365.com/glossary/accounts-payable
**Accounts payable** (AP) is the function and the ledger that tracks what a business owes to its suppliers. In Business Central and Dynamics 365 Finance, AP transactions are created by posted vendor invoices and credit memos — generated either from purchase orders (matched to receipts) or entered standalone — and settled by payment journals that produce bank files. Standard AP features include payment terms, payment discounts, partial payments, ageing reports, payment proposals, three-way matching, and vendor statements. AP entries post simultaneously to the **vendor ledger** and the **general ledger**, with currency revaluation handled by period-end routines.
## Accounts receivable
Source: https://www.solvingdynamics365.com/glossary/accounts-receivable
**Accounts receivable** (AR) is the function and the ledger that tracks what a business is owed by its customers. In Business Central and Dynamics 365 Finance, AR transactions are created by posted sales invoices and credit memos and settled by customer payments applied through cash receipt journals or bank reconciliations. Standard AR features include payment terms, customer credit limits, finance charges, reminder letters, customer statements, payment discounts, and ageing reports. AR entries post simultaneously to the **customer ledger** and the **general ledger**. The AR function is often paired with credit and collections workflows for chasing overdue balances.
## Activity
Source: https://www.solvingdynamics365.com/glossary/activity
An **activity** in Dataverse and Dynamics 365 is a record representing an interaction — phone call, email, appointment, task, letter, fax, social activity, custom activity types. Activities share a common base table (the **Activity Party** model) and are designed to attach to other records' **timeline** — every interaction with a customer appears chronologically on the customer's record. Activities have status (Open, Completed, Cancelled), due date, regarding object, participants (sender / receiver / required attendee / optional attendee), and content (subject, description, attachments). Activities are the source of most CRM-side analytics — call volumes, response times, meeting frequency — and the basis for tracking sales effort, service interactions, and customer engagement over time.
## Agent (Copilot)
Source: https://www.solvingdynamics365.com/glossary/agent
An **agent** in the modern Microsoft AI vocabulary is a configured AI assistant — typically built in **Copilot Studio** — that combines an LLM (Azure OpenAI under the hood) with **knowledge sources** (Dataverse, SharePoint, websites, documents), **actions** (operations it can perform via connectors), and **channels** where it publishes (Teams, web, Power Pages, Omnichannel, WhatsApp). Agents converse with users, retrieve grounded answers from knowledge, take actions on systems including Dynamics 365, and hand off to humans gracefully when stuck. Microsoft uses **agent** as the umbrella term for this class of AI; older terminology included "bot" (Power Virtual Agents) and "Copilot extension". For Dynamics 365, custom agents extend the embedded copilots with customer-specific knowledge and actions.
## AI Builder
Source: https://www.solvingdynamics365.com/glossary/ai-builder
**AI Builder** is the no-code machine-learning capability inside the Power Platform. It ships **pre-built models** for common tasks — invoice processing, receipt reading, ID extraction, sentiment analysis, OCR, business card capture — and supports **custom-trained models** for prediction, classification, entity extraction, and document processing trained on the customer's own data. Models are called from Power Apps, Power Automate, Dataverse plug-ins, and Copilot Studio agents. AI Builder runs on a **credit** consumption model bundled with some Power Platform plans; tracking credit usage is the most common operational discipline.
## AL Language
Source: https://www.solvingdynamics365.com/glossary/al-language
**AL** is the programming language used to build extensions for Business Central. It replaced the older **C/AL** that was used in Dynamics NAV when Business Central moved to an extension-based customisation model. AL is a strongly-typed, Pascal-flavoured language with first-class objects for tables, pages, codeunits, reports, queries, and XMLports. Developers write AL inside Visual Studio Code with Microsoft's AL Language extension, debug against sandbox environments, and ship extensions as `.app` files distributed through AppSource, partner installation, or per-tenant deployment. AL is the only supported way to customise Business Central code.
## Alternate key
Source: https://www.solvingdynamics365.com/glossary/alternate-key
An **alternate key** in Dataverse is a defined uniqueness constraint on one or more columns of a table, enabling records to be identified by business-meaningful values (Tax ID, Email, Product Number, External System ID) instead of GUIDs. Once configured, inserts violating the uniqueness fail, and the Web API supports retrieval by the alternate key value rather than by GUID. Critical for integration scenarios — external systems can `Upsert` records by natural key without first looking up the Dataverse GUID. Common examples: Account by Tax ID, Contact by Email, Product by Product Number, Lead by external system ID. Activation requires existing data to be free of duplicates on the key columns.
## API Management (APIM)
Source: https://www.solvingdynamics365.com/glossary/api-management
**Azure API Management (APIM)** is Microsoft's managed API gateway. Sitting in front of Dataverse, Business Central, F&O, and other APIs, APIM adds **rate limiting** (per-consumer quotas), **authentication** (subscription keys, OAuth, JWT validation), **transformation** (request / response shape), **caching** (reduce backend load), **versioning** (manage API evolution), **observability** (every request logged), and a **developer portal** (auto-generated documentation for consumers). Behaviour is configured through declarative **policies** in XML. Products group APIs; subscriptions issued to consumers. For enterprise Dynamics 365 integrations with many consumers — partners, internal apps, mobile clients — APIM is the standard governance layer. Tiered pricing (Developer, Basic, Standard, Premium) based on capacity needs.
## App registration
Source: https://www.solvingdynamics365.com/glossary/app-registration
An **app registration** in Microsoft Entra ID is the registration that represents an application (or service, or integration) in the directory. From an app registration:
- A **client ID** uniquely identifies the application.
- A **client secret** or **certificate** authenticates the application.
- **OAuth permissions** declare what the application can access — Dataverse user-or-application permissions, Microsoft Graph permissions, etc.
- A **service principal** is created in the tenant; the app registration's permissions and credentials become the service principal's.
- **Redirect URIs** for OAuth flows are configured.
For Dynamics 365 integrations, an app registration is the prerequisite for any service-to-service automation — Power Automate flows authenticating to Dataverse, Azure Functions writing to Dataverse, CI/CD pipelines deploying solutions, custom apps consuming Dataverse APIs. Maintain credentials in Azure Key Vault; rotate secrets periodically; audit permissions.
## Approval workflow
Source: https://www.solvingdynamics365.com/glossary/approval-workflow
An **approval workflow** is a structured routing of a transactional document — purchase order, sales quote, vendor invoice, journal, expense report — through one or more approvers before it can post or progress. Dynamics 365 implements approval workflows three ways: **Business Central's built-in workflow engine** (template-driven, with approval limits and hierarchical routing); **Finance & SCM's workflow engine** (graphical designer with parallel branches, escalations, automated tasks); and **Power Automate approvals** (cross-system orchestration, the modern choice for workflows that reach outside one system). Common patterns: purchase orders over a threshold require manager approval; customer credit overrides need sales-leader sign-off; vendor invoices over a limit need controller approval. Built-in workflows enforce posting controls; Power Automate excels at cross-system orchestration.
## AppSource
Source: https://www.solvingdynamics365.com/glossary/appsource
**Microsoft AppSource** is the marketplace for business applications, extensions, and add-ons that run on Microsoft cloud products including Dynamics 365, the Power Platform, Microsoft 365, and Azure. For Dynamics 365 customers it is the canonical place to discover and install **ISV-built** functionality — country-specific localizations for Business Central, industry verticals on top of CRM, connectors, and AI agents. Apps are published by Microsoft partners under transactable or contact-me models, and Business Central extensions in particular must be available on AppSource to be installed into a SaaS tenant.
## Azure
Source: https://www.solvingdynamics365.com/glossary/azure
**Azure** is Microsoft's public cloud platform and the underlying infrastructure that hosts every Dynamics 365 app and the Power Platform. From a customer's perspective Azure shows up in several ways: as the region where the Dynamics 365 environment is provisioned, as the identity provider (Microsoft Entra ID, formerly Azure AD) that signs users in, and as the place where companies build complementary services — APIs, integrations, data warehouses, and AI models — that talk to Dynamics 365. Azure is also where partners host Logic Apps, Service Bus queues, and Functions used to integrate Business Central or Finance with third-party systems.
## Azure Function
Source: https://www.solvingdynamics365.com/glossary/azure-function
An **Azure Function** is a unit of serverless compute — code (C#, JavaScript, Python, PowerShell, Java) that runs on demand triggered by events. Triggers include **HTTP** (callable via REST URL), **Timer** (scheduled execution), **Service Bus / Queue** (consume queue messages), **Event Grid** (consume events), **Blob Storage**, **Cosmos DB**, and more. For Dynamics 365 integrations, Azure Functions are the standard answer when Power Automate doesn't fit — complex transformations, high-throughput processing, webhook receivers, scheduled batch jobs, API façades. Hosting tiers: **Consumption** (pay-per-execution, scales to zero), **Premium** (pre-warmed, no cold starts), **Dedicated** (App Service plan). Authentication to Dataverse via service principal or **Managed Identity**. Telemetry through Application Insights integrates automatically.
## BOM (Bill of Materials)
Source: https://www.solvingdynamics365.com/glossary/bom
A **bill of materials (BOM)** is the list of components, sub-assemblies, and raw materials needed to make a manufactured item. In Dynamics 365 it appears in three flavours: **production BOMs** (in Business Central Premium and Supply Chain Management — used for discrete manufacturing, with versioning and certification), **assembly BOMs** (in Business Central Essentials — simpler, single-level, for kitting and light assembly), and **formulas** (in Dynamics 365 Supply Chain Management — for process manufacturing with proportional ingredients, scaling, yields, and co-products / by-products). BOMs are paired with **routings** that describe the operations needed; together they drive **MRP** (planning) and production order execution.
## Business Central
Source: https://www.solvingdynamics365.com/glossary/business-central
**Business Central** (full name: Microsoft Dynamics 365 Business Central) is Microsoft's SaaS ERP aimed at small and mid-sized businesses. It is the direct successor to Dynamics NAV and ships with financials, inventory, sales, purchasing, basic manufacturing, and project accounting in a single integrated application. It is extended through AL extensions distributed via AppSource and licensed per user in Essentials or Premium tiers. Business Central runs on Microsoft's Azure cloud and integrates natively with Microsoft 365, Power BI, and the wider Power Platform. It is typically implemented by a certified partner.
## Business process flow (BPF)
Source: https://www.solvingdynamics365.com/glossary/business-process-flow
A **business process flow (BPF)** is the staged top-of-form progress bar in Dynamics 365 model-driven apps that guides users through a multi-step process — qualifying a lead through stages from Qualify → Develop → Propose → Close, for example. A BPF defines an ordered list of **stages**, each with **steps** (fields the user must complete). Required steps block stage transitions; optional steps prompt without blocking. BPFs can span **multiple tables** (lead → opportunity → quote), **branch** based on field values, and **trigger automations** on stage transitions through Power Automate. Best practice: three to seven stages, three to six steps each, with branching only where the process genuinely diverges.
## Business Process Modeller (BPM)
Source: https://www.solvingdynamics365.com/glossary/business-process-modeller
The **Business Process Modeller (BPM)** is a feature of **Lifecycle Services (LCS)** that provides a library of standard business processes for Dynamics 365 Finance and Supply Chain Management implementations — procure-to-pay, order-to-cash, record-to-report, hire-to-retire, and many others — documented as flow diagrams with embedded task descriptions. Implementation teams use BPM for **fit-gap analysis** (walking through standard processes and identifying customer-specific deviations), **process documentation** (the final BPM tree becomes a documented operational reference), and **task linking** (BPM tasks link to **Task Recorder** scripts that demonstrate the actual application steps). Customers customise BPM trees per their specific organisation; the result is a living process-documentation artefact maintained throughout the system's life.
## Business rule
Source: https://www.solvingdynamics365.com/glossary/business-rule
A **business rule** in Dataverse is a no-code mechanism for adding field-level logic to forms. The graphical designer lets makers configure conditions on field values and actions to take when the conditions are met — set a default value, lock a field, change its required status, show an error message, hide a section, suggest a value (recommendation). Business rules can scope to a single form or to the entire table; entity-scoped rules run both client-side and server-side, enforcing logic even on API writes. Limits: single-table only (no cross-table references), no external calls, no complex iteration. For richer logic, use **Power Automate flows**, **JavaScript via the Client API**, or **plug-ins**. Business rules are the right tool for the common "if X then require Y" pattern.
## Business units
Source: https://www.solvingdynamics365.com/glossary/business-units
A **business unit (BU)** in Dataverse is a hierarchical organisational scope that every user and every record belongs to. Each environment has a single root BU and a tree of child BUs beneath. **Security roles** combine table-level privileges with **scopes** that reference business units — *user-owned*, *business unit*, *parent: child business unit*, or *organisation* — determining whose records a user can act on. Business units typically map to organisational structure (divisions, regions, subsidiaries) but should be kept simple; overly deep trees complicate administration. **Teams**, **field-level security profiles**, and **row sharing** layer on top of the BU foundation for finer control.
## Calculated column
Source: https://www.solvingdynamics365.com/glossary/calculated-column
A **calculated column** in Dataverse is a column whose value is computed at *read time* from a formula referencing fields on the same record (or one level of related records). Every time the row is queried, the calculation runs. Formulas support arithmetic, simple conditional logic, some date/text functions. Trade-offs: always shows current values (no stale data); no storage cost (not persisted); but can't be queried or sorted efficiently because the value isn't indexed. For *aggregations* across related records, use **rollup columns** (which persist) instead. For more expressive formulas using Power Fx, use **formula columns**. For complex logic, use **plug-ins** or **Power Automate flows** that compute and store the value in a regular column.
## Canvas app
Source: https://www.solvingdynamics365.com/glossary/canvas-app
A **canvas app** is one of two Power Apps application types (the other being model-driven). Canvas apps start from a blank screen; the maker drags controls (galleries, text inputs, dropdowns, charts) and wires them up with **Power Fx** expressions. Layout is pixel-perfect; data sources can be Dataverse, SharePoint, SQL, Excel, hundreds of third-party connectors, and any combination. Canvas apps suit mobile-first scenarios, field-worker apps, kiosk-style apps, and bespoke UX patterns where standard Dynamics 365 chrome would be overkill. Trade-off vs **model-driven apps**: canvas apps don't auto-generate security-aware UI, advanced find, dashboards, or reports — those have to be built. Canvas apps support **offline mode** for mobile work without connectivity.
## Cascading delete
Source: https://www.solvingdynamics365.com/glossary/cascading-delete
**Cascading delete** in Dataverse is the relationship-level setting that controls what happens to child records when their parent is deleted. The options: **Cascade** (child records deleted too — useful when children have no meaning without parent, e.g. Sales Order Line on Sales Order), **Restrict** (block the parent's deletion if children exist — safer when children have independent value), **Remove Link** (delete parent but break the relationship to children, leaving them orphaned — rarely the right choice), **Cascade Active** (cascade only to active children), or **Cascade User-Owned** (cascade only to children owned by the same user). Configure cascade behaviour at relationship design time; reversing surprising data loss is rarely possible.
## Case
Source: https://www.solvingdynamics365.com/glossary/case
A **case** in Dynamics 365 Customer Service is the core record representing one unit of customer trouble — a question, complaint, service request, or incident. Each case carries a customer, subject, description, priority, status, owner, queue, attached entitlement and SLA, and a resolution. Cases are created from email, chat, voice, web form, social, SMS, WhatsApp, or by an agent manually. They route through **Unified Routing** to agents based on skills, capacity, queues, and SLAs. The lifecycle moves Active → Resolved → Cancelled, with optional parent/child relationships for complex investigations. Case timeline accumulates every interaction; knowledge articles attach inline; **Copilot** summarises and drafts responses. Cases are the unit of customer-service work and the source of most customer-service analytics.
## Chart of accounts
Source: https://www.solvingdynamics365.com/glossary/chart-of-accounts
A **chart of accounts** (CoA) is the structured list of accounts a business uses in its general ledger to categorise every financial transaction. Each account has a number, a name, a category (asset, liability, equity, income, or expense), and posting attributes. In Business Central and Dynamics 365 Finance, the CoA is paired with **dimensions** so transactions can be analysed by department, project, region, or any other lens without needing thousands of sub-accounts. Designing the CoA is one of the first tasks of any ERP implementation; once live, restructuring it is invasive, so the upfront design matters.
## Child flow
Source: https://www.solvingdynamics365.com/glossary/child-flow
A **child flow** in Power Automate is a flow invoked by another flow, enabling decomposition of complex workflows into reusable, maintainable units. Child flows are triggered by Power Apps or HTTP request triggers; parents call them via HTTP action with JSON payload matching the child's input schema. Common patterns: shared authentication helpers, document-generation services, audit-logging services, notification orchestrators that handle multi-channel delivery. Benefits include reusability (one child flow used by many parents), maintainability (smaller flows are easier to understand and modify), and independent versioning. Each invocation has HTTP overhead, so child flows suit substantial logic rather than trivial helper code.
## Classic workflow
Source: https://www.solvingdynamics365.com/glossary/classic-workflow
A **classic workflow** in Dataverse is the legacy workflow engine that predates Power Automate. Configured through the **process designer** in the maker portal, classic workflows run on Dataverse events (create, update, delete, status change) and execute sequences of steps — create records, update records, send emails, change status, conditional branches. Two modes: **real-time / synchronous** (runs in the same transaction; can roll back the originating operation on failure) and **background / asynchronous** (queued for later execution; supports wait conditions for delays / polling). Power Automate has substantially superseded classic workflows for new builds — better designer, broader connector library, better ALM. Classic workflow remains relevant for in-transaction synchronous logic and existing customisations.
## CoE Starter Kit
Source: https://www.solvingdynamics365.com/glossary/coe-starter-kit
The **Center of Excellence (CoE) Starter Kit** is Microsoft's free, open-source toolkit for governing the Power Platform at scale. It installs into a dedicated CoE environment and provides: tenant-wide **inventory** of every Power App, flow, custom connector, Power BI workspace, Power Pages site; **usage telemetry** showing which assets are heavily used vs abandoned; **owner attribution** including orphan-asset detection; **compliance workflows** for reviewing new apps before broad sharing; **admin tooling** for bulk operations; **nurture components** for engaging the maker community. Open-source means community-maintained and self-supported — not the same support model as licensed products. Customers customise the kit for their specific governance needs; commercial alternatives exist for larger or more complex tenants.
## Common Data Model
Source: https://www.solvingdynamics365.com/glossary/common-data-model
The **Common Data Model (CDM)** is Microsoft's open, standardised schema for business entities such as Account, Contact, Product, Order, Invoice, and Employee. It defines tables, relationships, and semantic types that apps can share so data flows between them without bespoke mapping. Dataverse uses the CDM as its starter schema, which is why Dynamics 365 Sales, Customer Service, Field Service, and Power Apps can interoperate out of the box. CDM definitions are open and published on GitHub, and are also used in Microsoft Fabric, Azure Data Lake, and a number of third-party data tools.
## Connection reference
Source: https://www.solvingdynamics365.com/glossary/connection-reference
A **connection reference** in the Power Platform is a solution component that abstracts the *kind* of connection a flow or app needs (e.g. "a SharePoint connection") from any specific connection instance (e.g. "the dev SharePoint site"). At solution import time, each connection reference is bound to an environment-specific connection — the same managed solution package deploys to dev, UAT, and production with different bindings per environment. Without connection references, deploying a flow across environments requires manually re-pointing every connection each time. Combined with **environment variables** for configuration values, connection references are essential to portable solution ALM. Modern Power Automate flows should use connection references for every external connector.
## Copilot
Source: https://www.solvingdynamics365.com/glossary/copilot
**Copilot** is Microsoft's umbrella brand for AI-assisted experiences across its product portfolio. In the Dynamics 365 context, "Copilot" appears in several distinct products: **Microsoft 365 Copilot** (embedded in Word, Excel, Outlook, Teams, etc.), **Copilot for Sales** (a per-user add-on for sellers), and various **embedded Copilots** inside specific Dynamics 365 apps — Copilot in Business Central, Copilot in Customer Service, Copilot in Finance. Each is a distinct product with separate licensing. **Copilot Studio** is the platform for building custom AI agents on top of all of these. The licensing landscape is non-trivial; verify per use case which Copilot a user is being offered.
## Copilot Studio
Source: https://www.solvingdynamics365.com/glossary/copilot-studio
**Microsoft Copilot Studio** is the low-code platform for building AI agents — conversational and increasingly autonomous — that integrate deeply with Dynamics 365 and the rest of the Microsoft cloud. Successor to Power Virtual Agents, with a much heavier generative AI core. An agent is configured with a role, knowledge sources (Dataverse tables, SharePoint, websites, documents), actions (the operations it can take via connectors), and channels where it publishes (Teams, web, Power Pages, Omnichannel, WhatsApp, others). It combines deterministic **topics** with **generative answers** for the long tail. The standard way to extend Dynamics 365 with custom AI.
## CRM
Source: https://www.solvingdynamics365.com/glossary/crm
**CRM** stands for *Customer Relationship Management*. It refers to software that manages a company's interactions with current and prospective customers across sales, customer service, marketing, and field operations. A CRM is typically organised around Accounts and Contacts, with activities, opportunities, cases, and campaigns hanging off them. Microsoft's CRM offerings inside Dynamics 365 include Sales, Customer Service, Field Service, Project Operations, and Customer Insights, all built on Microsoft Dataverse. Modern CRM systems are deeply integrated with email, calendar, telephony, and AI assistants, and are licensed per user per month.
## Custom action
Source: https://www.solvingdynamics365.com/glossary/custom-action
A **custom action** in Dataverse is a named operation that wraps business logic with typed input and output parameters, callable from many surfaces — Web API, plug-ins, JavaScript on forms, Power Automate flows, and other integrations. Custom actions are the canonical pattern for **encapsulating business operations**: a single "ApproveExpense" action can perform multiple steps atomically (verify limits, deduct budget, update status, notify) without exposing the internal logic to callers. Implemented either as configured workflows or as plug-ins. Can be **bound** to a specific table or **unbound** (global). Treat custom actions as API contracts — input / output signatures should evolve carefully because external callers depend on them.
## Cutover
Source: https://www.solvingdynamics365.com/glossary/cutover
**Cutover** is the structured sequence of activities that transitions a customer from legacy systems to Dynamics 365 at go-live. A typical cutover plan covers: final data extract from the legacy system, transformation, load into Dynamics 365, reconciliation to the penny against expected balances, integration endpoint switchover from test to live, user account activation, and the formal cut moment where the legacy system goes read-only and the new system accepts production transactions. Mature implementations run a **mock cutover** (a complete dry-run, often a month before go-live) and a real cutover (the actual event, usually over a weekend or holiday). A detailed minute-by-minute cutover runbook is one of the most important pre-go-live deliverables.
## Data entity
Source: https://www.solvingdynamics365.com/glossary/data-entity
A **data entity** in Dynamics 365 Finance and Supply Chain Management is a denormalised, stable view of one or more underlying tables, presented as a single shape with consistent field names. Microsoft ships hundreds — Customer, Vendor, Item, Sales Order Header, Sales Order Line, GL Journal Voucher, Project Transaction. Data entities are the unit consumed by the **Data Management Framework (DMF)** for bulk import / export and by the **Recurring Integrations API** for scheduled HTTP-based integration. **Composite entities** group related entities for transactional import (e.g. sales order header + lines as one atomic unit). Data entities are versioned so consuming integrations don't break when underlying tables evolve.
## Data gateway
Source: https://www.solvingdynamics365.com/glossary/data-gateway
The **on-premises data gateway** is a Windows service running inside a customer's network that bridges cloud services (Power BI, Power Automate, Logic Apps, Power Apps) to on-prem data sources (SQL Server, file shares, custom APIs, legacy applications). Outbound-only connection through Azure Service Bus relay — no inbound firewall openings needed. Two modes: **standard** (multi-user production, with clustering for high availability) and **personal** (individual maker, less robust). Configured data sources include credentials; cloud services use the gateway as a routed access point. Essential infrastructure for hybrid cloud / on-prem analytics during transitions and for permanently on-premise data sources. Update monthly; cluster for production resilience.
## Data Management Framework (DMF)
Source: https://www.solvingdynamics365.com/glossary/dmf
The **Data Management Framework (DMF)** is the Dynamics 365 Finance and Supply Chain Management tool for bulk data movement. It centres on **data entities** — denormalised, versioned views of one or more underlying tables — that are imported or exported through **data projects**. DMF handles initial customer migrations, ongoing batch ETL, and **recurring integrations** through scheduled file drops or HTTP endpoints. Composite entities import related tables in a single transactional unit. DMF is the heavy-batch counterpart to **Dual-write** (synchronous near-real-time sync) and is used heavily during data migration cycles and for high-volume scheduled integrations.
## Dataflow
Source: https://www.solvingdynamics365.com/glossary/dataflow
A **dataflow** in the Power Platform is a Power Query-based ETL pipeline that ingests data from a source (SQL, SharePoint, Excel, CSV, API, another database), transforms it through Power Query M expressions, and lands it in Dataverse on a scheduled refresh. Dataflows are how citizen developers build data integration without coding — drag-and-drop transformations, declarative joins, type coercion, merging multiple sources into a unified shape. Output can be **standard dataflows** (writing into Dataverse tables) or **analytical dataflows** (writing into Power BI semantic models or Azure Data Lake). For Dynamics 365 integrations involving moderate data volumes and configurable transformations, dataflows are often a simpler answer than custom code or full ADF pipelines.
## Dataverse search
Source: https://www.solvingdynamics365.com/glossary/dataverse-search
**Dataverse search** (formerly Relevance Search) is the modern global search experience in Dynamics 365 and Power Apps. Built on **Azure Cognitive Search** under the hood, it indexes content asynchronously and serves queries through a dedicated search service. Characteristics: fast (milliseconds even on millions of records), global (across all configured tables), relevance-ranked, fuzzy matching (handles typos, partial matches, word stems), faceted filtering. Configured per environment — admins enable specific tables and columns for indexing. Distinct from **Quick Find**, which searches the live database per-table without relevance ranking. Dataverse search is the right tool for global discovery; Quick Find for per-view live-current filtering. Both must be configured deliberately for users to find them useful.
## Dimensions
Source: https://www.solvingdynamics365.com/glossary/dimensions
**Dimensions** are configurable analytical tags attached to every ledger transaction, replacing the proliferation of GL sub-accounts you find in older accounting systems. Common dimensions include Department, Cost Centre, Project, Region, Customer Group, Salesperson, and Brand. In **Business Central**, eight global dimensions are available with up to two shortcut dimensions reportable directly from the chart of accounts. In **Dynamics 365 Finance** the limit is higher (up to ten financial dimensions). Dimensions can be required, restricted to combinations, or defaulted from master records, and they make slice-and-dice reporting in Power BI or built-in account schedules straightforward.
## DLP policy
Source: https://www.solvingdynamics365.com/glossary/dlp-policy
A **Data Loss Prevention (DLP) policy** in the Power Platform classifies connectors into groups — typically **Business**, **Non-Business**, **Blocked** — and prevents Power Automate flows and Power Apps from combining connectors across groups in ways that could leak sensitive data. The canonical example: a flow that reads Dataverse (Business) and writes to a personal Dropbox (Non-Business) would be blocked by a DLP policy that puts Dataverse in Business and Dropbox in Non-Business. DLP policies apply per environment or tenant-wide; multiple policies can layer with priority. Configured in the **Power Platform admin centre**. Essential governance — without DLP, the Power Platform's hundreds of connectors create unconstrained data-flow paths. Start with a tenant-baseline policy; refine per environment.
## Dual-write
Source: https://www.solvingdynamics365.com/glossary/dual-write
**Dual-write** is the synchronous integration framework that connects **Dynamics 365 Finance and Supply Chain Management** (which run on their own database) with **Microsoft Dataverse** (which underlies the CRM-side D365 apps and the Power Platform). It defines **maps** — pairs of tables, one in F&O and one in Dataverse, with field-level mappings — and synchronises records near-real-time on save. Microsoft ships dozens of standard maps for customer, vendor, product, sales order, and other key entities; custom maps extend them. Direction can be one-way or bi-directional. Dual-write is the standard pattern for customers running F&O alongside CRM-side D365 apps, and a configuration discipline rather than custom code.
## Duplicate detection
Source: https://www.solvingdynamics365.com/glossary/duplicate-detection
**Duplicate detection** in Dataverse is the mechanism that identifies potential duplicate records to keep CRM data clean. **Duplicate detection rules** define what counts as a duplicate per table — combinations of fields with matching operators (exact, fuzzy, phonetic, prefix). When records are created or updated, active rules evaluate against existing records; matches trigger warnings on the UI form or block API writes (configurable). Bulk **duplicate detection jobs** scan tables retrospectively to find existing duplicates. Once identified, the **merge** function combines two records, preserving one as the master and transferring related records (activities, opportunities, cases) from the duplicate before deletion. For enterprise-scale deduplication across multiple systems, **Customer Insights – Data** does ML-assisted identity resolution.
## Dynamics 365
Source: https://www.solvingdynamics365.com/glossary/dynamics-365
**Dynamics 365** is Microsoft's portfolio of cloud-based business applications launched in 2016, combining ERP and CRM into a modular suite. It includes apps for Sales, Customer Service, Field Service, Finance, Supply Chain Management, Business Central, Project Operations, Human Resources, Commerce, and Customer Insights, all sold per user per app. The apps share a foundation of Microsoft Dataverse, Microsoft Entra ID, and the Power Platform, and integrate natively with Microsoft 365. Dynamics 365 is the successor to Dynamics AX, NAV, GP, SL, and CRM, and is implemented primarily by Microsoft's partner network.
## Dynamics NAV
Source: https://www.solvingdynamics365.com/glossary/dynamics-nav
**Dynamics NAV** (originally Navision) was Microsoft's on-premise ERP product for small and mid-sized businesses. It was acquired by Microsoft in 2002 and went through annual releases up to NAV 2018 before being rebranded and re-engineered as Dynamics 365 Business Central. NAV introduced the C/AL programming language and the role-tailored client, and it built a large global partner ecosystem around vertical add-ons. Mainstream support for NAV ended for older versions but many organisations still run NAV 2016, 2017, or 2018 and migrate to Business Central as upgrade projects.
## Electronic Reporting (GER)
Source: https://www.solvingdynamics365.com/glossary/electronic-reporting
**Electronic Reporting (ER)**, also known as **Globalization Studio** in newer terminology, is Dynamics 365 Finance and Supply Chain Management's configurable, no-code framework for generating structured outputs (XML, JSON, fixed-width, CSV) and parsing inbound structured inputs. ER configurations are versioned, exported through a global repository (so customers and partners share country-specific implementations), and applied at runtime to produce outputs like **statutory e-invoicing** (Italy SDI, Spain SII, Mexico CFDI, Brazil NFe), **VAT returns** (UK MTD, OSS, country-specific), **payment files** (SEPA, BACS, ACH, country-specific bank formats), **SAF-T exports**, **intrastat declarations**. ER replaces what historically required hard-coded country-specific outputs with a maintainable configuration layer.
## Environment variable
Source: https://www.solvingdynamics365.com/glossary/environment-variable
An **environment variable** in the Power Platform is a solution component that abstracts a *configuration value* — a URL, a feature flag, a threshold number, a JSON document — so it can differ per environment without changing the solution itself. Variable types include String, Number, Boolean, JSON, Data Source (for table references), and Secret (Azure Key Vault-backed for sensitive values). The solution defines the variable with a default value (typically the dev value); on import to other environments, the import flow accepts environment-specific values. Combined with **connection references** for connector bindings, environment variables enable truly portable solution packages that deploy across dev / UAT / production cleanly without modification.
## Environments
Source: https://www.solvingdynamics365.com/glossary/environments
An **environment** is an isolated instance of a Dynamics 365 tenant, with its own database, users, configurations, and code. A typical setup has one **production** environment plus one or more **sandbox** environments for development, testing, training, and data refreshes. Business Central includes one production environment per tenant by default, with additional production and sandbox environments licensed as add-ons. Dynamics 365 CRM-side apps and Finance/SCM follow a similar model with their own environment SKUs. Best practice is to develop in a sandbox, test in a separate UAT sandbox, and promote releases to production through a controlled lifecycle.
## ERP
Source: https://www.solvingdynamics365.com/glossary/erp
**ERP** stands for *Enterprise Resource Planning*. It refers to a category of business software that unifies the back-office processes a company needs to operate — general ledger, accounts payable and receivable, inventory, procurement, order management, manufacturing, and reporting — on a shared data model. ERP systems replace siloed departmental tools with a single source of truth, so a sale recorded in one module automatically updates inventory, revenue, and tax in the others. Microsoft's ERP offerings in the Dynamics 365 family include Finance, Supply Chain Management, and Business Central. ERPs are typically deployed as SaaS today.
## Event Grid
Source: https://www.solvingdynamics365.com/glossary/event-grid
**Azure Event Grid** is Microsoft's lightweight pub/sub eventing service designed for cloud-scale fan-out. Dataverse can publish change events to Event Grid topics; multiple **subscribers** can independently subscribe with their own filters. Each subscriber receives the events it filtered for, processed independently — if one subscriber is down, the others are unaffected. Subscribers include Azure Functions, Logic Apps, webhook endpoints, Service Bus queues (for chained durable processing), Event Hubs, and Storage queues. Event Grid scales to millions of events per second and is generally cheaper than Service Bus at high volume, but offers shorter retention (24h default) and less durable processing guarantees. The right pattern when many subscribers need to be notified of Dataverse changes; for transactional integration, prefer Service Bus.
## Eventual consistency
Source: https://www.solvingdynamics365.com/glossary/eventual-consistency
**Eventual consistency** is the property of distributed systems where related data across multiple stores reaches a consistent state *over time* rather than *immediately*. Common in Dynamics 365 integrations: a sales order placed in Sales eventually appears in Business Central; a customer update in Dataverse eventually propagates to downstream subscribers; a Dual-write sync between F&O and Dataverse has small delays. The trade-off: strong consistency requires synchronous coordination (slower, fragile under failure); eventual consistency tolerates delays in exchange for availability and scale. Design integrations recognising eventual consistency — users see "your order is being processed" while async flows complete; downstream systems may be seconds-to-minutes behind the source; reports clarify "as of" timestamps for stale data.
## Extensions
Source: https://www.solvingdynamics365.com/glossary/extensions
**Extensions** are the modern, supported way to customise Microsoft business apps. In Business Central, an extension is an AL package that adds new tables, pages, code, and integrations alongside the base application without modifying Microsoft's own objects — which is why upgrades stay non-breaking. Extensions are installed per tenant, published through AppSource, or pushed by a partner. Dynamics 365 CRM-side apps use a similar concept through **solutions** in Dataverse, which package tables, forms, security roles, flows, and Power Apps. Both models replace the older practice of editing the base product directly.
## FastTrack
Source: https://www.solvingdynamics365.com/glossary/fasttrack
**FastTrack for Dynamics 365** is Microsoft's free advisory and engineering program for qualifying customer implementations. FastTrack engineers — Microsoft staff, not consultants — sit alongside the customer and their implementation partner, providing architecture design reviews, Solution Blueprint Reviews (SBRs), Go-Live Readiness Reviews, and escalation to product engineering for blockers. FastTrack does not deliver implementations or write code; it advises, reviews, and documents findings against the **Success by Design** rubric. Eligibility is licence-volume-based and typically applies to enterprise customers; engagement is by Microsoft account team referral.
## FetchXML
Source: https://www.solvingdynamics365.com/glossary/fetchxml
**FetchXML** is Dataverse's XML-based query language. It powers **Advanced Find** in the Dynamics 365 UI, **stored views** in Dataverse (which are FetchXML under the hood), **plug-ins** doing complex queries via the SDK, and **Power Automate flows** that use FetchXML in the "List rows" action. FetchXML is more expressive than OData for complex queries with group-by, aggregations, and nested link-entity joins; it's verbose but powerful. For modern integration work — external systems calling Dataverse over HTTP — **OData** is the standard choice. Both compile to the same underlying SQL, so performance is comparable. Tools like XrmToolBox's FetchXML Builder make hand-writing the XML less tedious.
## Field-level security (FLS)
Source: https://www.solvingdynamics365.com/glossary/field-level-security
**Field-level security (FLS)** in Dataverse restricts access to specific columns within a row, beyond row-level security from security roles. A column is marked **Secured**; users see it only if they belong to a **field security profile** that grants Read / Update / Create access. Common uses: HR data (Salary, Performance Rating), sensitive financial data (Credit Score, Internal Risk Assessment), PII (SSN, Date of Birth), internal-only notes. The platform enforces FLS at form rendering, API responses, reports, and views — secured fields are stripped from responses to unauthorised users. Mobile offline caches also respect FLS — sensitive data isn't cached on devices users without access. Use FLS selectively for genuinely sensitive columns; don't apply universally.
## Fiscal period
Source: https://www.solvingdynamics365.com/glossary/fiscal-period
A **fiscal period** is an accounting period defined in Business Central's *Accounting Periods* or Dynamics 365 Finance's *Fiscal calendars* — typically a calendar month, with quarters and years aggregating. Each period has a start date, end date, and a status that governs posting behaviour: **Open** (transactions can post), **On Hold** (only privileged users can post), **Closed** (no further posting). Period close is the controlled sequence that moves a period from Open to Closed after all accruals, revaluations, reconciliations, and adjustments are complete. Multiple **fiscal calendars** can coexist (statutory, group, tax) with parallel periods. The fiscal year is typically the regulatory accounting year (matching tax / statutory reporting); some companies use non-calendar years (e.g. April – March, July – June).
## Fit-gap analysis
Source: https://www.solvingdynamics365.com/glossary/fit-gap
**Fit-gap analysis** is the structured comparison of a customer's requirements against an ERP or CRM's out-of-the-box capabilities, classifying each requirement as **fit** (standard does it), **fit with configuration** (standard handles it with setup), **gap** (no standard support — needs customisation, third-party add-on, or process change). Most implementations begin with fit-gap workshops by area (finance, sales, operations, etc.), and the resulting gap list drives the customisation budget and scope. **Success by Design** methodology emphasises **fit to standard** — every gap is evaluated against business value before being committed to as customisation. Honest fit-gap analysis is one of the most consequential early-project activities.
## Formula column
Source: https://www.solvingdynamics365.com/glossary/formula-column
A **formula column** in Dataverse is a more recent column type that uses **Power Fx** (the same language as canvas Power Apps) for richer formula syntax than the older **calculated columns**. Formula columns evaluate at read time, so they're real-time like calculated columns but with substantially more available functions and constructs. Trade-offs: cannot reference related-table aggregations (use **rollup columns** for that), limited indexing for query performance, still subject to read-time computation cost. For most cases where calculated columns fall short of formula expressiveness, formula columns are the right upgrade. Verify target environment platform version supports them before deploying solutions that depend on them.
## General ledger
Source: https://www.solvingdynamics365.com/glossary/general-ledger
The **general ledger** (GL) is the central accounting record of an organisation, holding every posted financial transaction grouped by account in the **chart of accounts**. Every other module in an ERP — sales, purchasing, inventory, fixed assets, payroll, projects — ultimately writes to the GL through posting groups, so the GL is the single source of truth for the financial statements. In Business Central and Dynamics 365 Finance, GL entries are immutable once posted and are paired with **dimensions** for analysis. Period close, reconciliations, and statutory reporting all run against the GL.
## Go-live
Source: https://www.solvingdynamics365.com/glossary/go-live
**Go-live** is the moment a Dynamics 365 implementation stops being a project and becomes a production system. It is when migrated master data and opening balances are loaded, integrations are switched to live endpoints, the previous system is frozen or decommissioned, and users start posting real transactions. Go-live is preceded by user acceptance testing, a final data migration rehearsal, and a cutover plan that maps every step over a defined window. Most go-lives run with extra partner support for two to four weeks afterwards — known as **hypercare** — to handle questions and fixes before transitioning to steady-state support.
## Graph connector
Source: https://www.solvingdynamics365.com/glossary/graph-connector
A **Graph connector** is a mechanism that indexes content from external systems — including Dataverse and Dynamics 365 — into the **Microsoft Graph** index, making it discoverable through **Microsoft Search** across the Microsoft 365 experience and groundable by **Microsoft 365 Copilot**. Microsoft ships connectors for Dynamics 365 tables (Accounts, Opportunities, Cases, etc.), Business Central, ServiceNow, Salesforce, Jira, Confluence, file shares, and many other systems. Once configured per environment, the connector pulls content on a schedule, transforms it for Graph indexing, and pushes it into the tenant's search index. Indexed content respects source-system security at search time. Critical for surfacing Dynamics 365 data in M365 Copilot grounding and Microsoft Search across Outlook / Teams / Word / etc.
## Idempotency
Source: https://www.solvingdynamics365.com/glossary/idempotency
**Idempotency** is the property of an operation where running it multiple times produces the same result as running it once. Essential for Dynamics 365 integrations because distributed systems retry — network timeouts, webhook redeliveries, Service Bus retries all produce duplicate message arrivals. A non-idempotent integration receiving the same event twice creates duplicate records, double-charges customers, sends repeated notifications. Patterns for idempotency: **Upsert with alternate key** (Dataverse's natural idempotency for record creation), **check-before-create** (query for existence first; acceptable at low volume), **correlation IDs** (track processed event IDs and skip duplicates), **natural keys** (business identifiers that detect duplicates inherently). Design every integration for idempotency; the cost is small, the protection is substantial.
## Implementation
Source: https://www.solvingdynamics365.com/glossary/implementation
An **implementation** is the project that takes Dynamics 365 from a licensed but empty tenant to a working production system. A typical implementation covers requirements analysis, fit-gap analysis against the standard product, configuration, custom development (AL extensions for Business Central, plugins or Power Platform for CRM), data migration from legacy systems, integration to other applications, user training, testing, and cutover to go-live. Implementations are almost always delivered by a Microsoft partner using a structured methodology — Microsoft's official guidance is **Success by Design** — and run anywhere from a few weeks for a small Business Central project to multi-year programmes for large Finance/SCM rollouts.
## Intercompany
Source: https://www.solvingdynamics365.com/glossary/intercompany
**Intercompany** transactions are sales, purchases, payments, or transfers that happen between two legal entities within the same corporate group. Each entity records its side independently — a sale in one company is a purchase in the other — and the matched balances are eliminated on group consolidation so they don't double-count revenue or inventory. Business Central supports intercompany posting between linked companies in the same database. Dynamics 365 Finance scales it across hundreds of legal entities with shared chart-of-accounts policies, intercompany payments, and intercompany inventory transfers. Both products produce the intercompany ledger entries needed for group consolidations.
## Inventory
Source: https://www.solvingdynamics365.com/glossary/inventory
**Inventory** is the stock of physical goods a business holds for sale, production, or consumption. In Business Central and Dynamics 365 Supply Chain Management, every inventory transaction is recorded in the **item ledger** (quantity) and the **value entry** table (cost), tied to a costing method — FIFO, LIFO, Average, Standard, or Specific. Inventory is held at one or more **locations**, optionally subdivided into **bins**, and tagged with serial numbers, lot numbers, expiry dates, or item variants. Inventory valuation flows to the GL through inventory posting groups and is reconciled against the balance sheet at period close.
## Inventory dimension
Source: https://www.solvingdynamics365.com/glossary/inventory-dimension
An **inventory dimension** in Dynamics 365 Supply Chain Management is the structural concept that gives each physical unit of inventory its distinct identity. Three dimension groups: **product dimensions** (Size, Colour, Configuration, Style — make one item different from another within a product master), **storage dimensions** (Site, Warehouse, Location, Inventory Status — *where* the inventory is held), and **tracking dimensions** (Batch, Serial, Owner, Licence Plate — make individual units distinguishable within a storage location). Each dimension is configured per item as active or inactive; activation determines the operational granularity. More dimensions = more precision but more overhead; design per item category, not uniformly. Inventory dimensions drive picking, costing, planning, reservation, and traceability behaviour throughout SCM.
## ISVs
Source: https://www.solvingdynamics365.com/glossary/isvs
**ISV** stands for *Independent Software Vendor*. In the Microsoft business apps ecosystem, ISVs are partners who build and sell **packaged products** — extensions, add-ons, vertical solutions, country localizations, connectors — that run on top of Dynamics 365 or the Power Platform. ISVs are distinct from implementation partners (sometimes called SIs or VARs), although many partners do both. ISV products are typically distributed through Microsoft AppSource, are licensed separately from the core Dynamics 365 subscription, and may add country compliance, industry-specific functionality (e.g. construction, wholesale, food, manufacturing), or generic utilities like document automation.
## Job costing
Source: https://www.solvingdynamics365.com/glossary/job-costing
**Job costing** is the practice of tracking costs and revenue against individual jobs, projects, or work orders so that profitability can be measured and customers billed accurately. In Business Central's project module (still called **Jobs** in older versions), every resource hour, item issue, and GL expense can be posted against a job and a job task, with separate budget and billable plans. Work-in-progress (WIP) journals defer cost to the balance sheet until revenue is recognised on completion or percentage-of-completion. Job costing is essential for professional services, construction, engineering, installation, and any business where work is delivered as discrete engagements.
## Job queue
Source: https://www.solvingdynamics365.com/glossary/job-queue
The **job queue** in Business Central is the platform's scheduler for background and recurring tasks — nightly batch routines (Adjust Cost — Item Entries, Post Inventory Cost to G/L), scheduled report generation, asynchronous integrations, exchange-rate updates. Each job queue entry has an object to run, a schedule, retry policy, and a user context. Entries can be grouped into **job queue categories** for concurrency control — serialised categories prevent long-running jobs from overlapping. Failures move to Error status with the captured exception. Telemetry through Application Insights records job runs; healthy operations monitor failed jobs daily.
## Lead
Source: https://www.solvingdynamics365.com/glossary/lead
A **lead** in Dynamics 365 Sales (and the wider CRM-side Dynamics 365 stack) represents a prospect who has shown interest but hasn't yet been qualified as a real sales opportunity. Leads come from inbound channels — website forms, marketing campaigns, events, purchased lists, business cards, partner referrals — and live in a separate table from Contacts and Accounts deliberately, so unqualified noise doesn't pollute the CRM's relationship records. A lead has minimal mandatory fields (name, contact info, company, source); through **qualification**, the lead converts to a Contact (and optionally an Account) plus an Opportunity. Disqualified leads are retained for audit and pattern analysis. Some organisations skip leads entirely and qualify directly on Contacts; the choice is per business process.
## Lifecycle Services
Source: https://www.solvingdynamics365.com/glossary/lifecycle-services
**Microsoft Dynamics Lifecycle Services (LCS)** is the central portal for managing Dynamics 365 Finance and Supply Chain Management implementations. Every Finance/SCM project has an LCS workspace where customers and partners manage environments (request, provision, copy, refresh), deploy code as **deployable packages**, apply platform and application updates, run the **Business Process Modeller (BPM)**, file support tickets, and store assets in the **asset library**. The **Task Recorder** integrates with LCS for capturing user actions as reusable scripts. Microsoft is gradually migrating LCS functions to the **Power Platform admin centre**; today both consoles are in use side by side.
## Liquid
Source: https://www.solvingdynamics365.com/glossary/liquid
**Liquid** is the templating language originally created by Shopify, now used by **Power Pages** for rendering portal content. Liquid mixes HTML with **outputs** (`{{ variable }}` for printing values), **tags** (`{% if %}`, `{% for %}`, `{% capture %}` for control flow), and **filters** (`| upcase`, `| date`, `| escape` for transformations). Power Pages exposes specific objects — `user`, `page`, `entities`, `weblinks`, `request` — for accessing live data. Templates query Dataverse through `{% fetchxml %}` and `{% entityview %}` tags. Logic is intentionally limited — sandboxed, no arbitrary code execution — for safe content rendering of customer-facing pages. Auto-escapes user-supplied content to prevent XSS; bypassing escaping is rarely the right choice.
## Managed solution
Source: https://www.solvingdynamics365.com/glossary/managed-solution
A **managed solution** is a Power Platform solution exported and installed in a read-only deployment state. Components inside a managed solution cannot be edited in the target environment — users see them but cannot modify them, ensuring the customisations as delivered remain as delivered. Managed is the state of every UAT and production environment in a healthy ALM model; **unmanaged** solutions exist only in development environments where edits happen. Managed solutions support layering — multiple managed solutions install on top of each other (e.g. ISV base plus customer customisations) — and can be cleanly uninstalled in reverse order. The standard way to deploy Power Platform applications across environments.
## Manufacturing orders
Source: https://www.solvingdynamics365.com/glossary/manufacturing-orders
**Manufacturing orders** — called **production orders** in Business Central and Dynamics 365 Supply Chain Management — authorise and track the production of finished goods from raw materials. A typical production order references a **production BOM** (the components needed), a **routing** (the operations performed and on which work centres), and a quantity. As work progresses, **consumption journals** record material usage and **output journals** record finished quantities, scrap, and operation time. Cost flows into work-in-process and lands on the finished item when the order is fully finished. Production orders transition through statuses: planned → firm planned → released → finished.
## Many-to-many (N:N) relationship
Source: https://www.solvingdynamics365.com/glossary/many-to-many
A **many-to-many (N:N) relationship** in Dataverse models situations where records on both sides can relate to many records on the other — Students enrolled in Courses, Products tagged with Categories, Contacts on Marketing Lists. Two implementation patterns: **native N:N** (a system intersect table created automatically; simple binary "associated or not" relationships with no extra fields) and **manual intersection entity** (a custom table representing the relationship with its own fields, lifecycle, security, business logic). Native N:N is quick and easy but limited; manual intersection is more work but supports rich relationship data — role, dates, status, custom attributes. Choose based on whether the relationship needs its own attributes and lifecycle.
## Microsoft 365 Copilot
Source: https://www.solvingdynamics365.com/glossary/m365-copilot
**Microsoft 365 Copilot** is the AI experience embedded across the Microsoft 365 productivity suite: Word, Excel, PowerPoint, Outlook, Teams, OneNote, and the standalone Copilot app. It is **distinct** from the embedded Copilots inside Dynamics 365 (Copilot in Business Central, Copilot in Customer Service, etc.) and from Copilot for Sales. M365 Copilot is grounded in the user's M365 data through **Microsoft Graph**; **Graph connectors** can index external systems including Dynamics 365 for retrieval. **Copilot Studio agents** can extend M365 Copilot's behaviour with custom plugins. Licensed as a paid per-user add-on requiring an M365 base SKU.
## Microsoft Dataverse
Source: https://www.solvingdynamics365.com/glossary/microsoft-dataverse
**Microsoft Dataverse** is the data platform that sits under Dynamics 365's CRM-side apps (Sales, Customer Service, Field Service, Project Operations, Customer Insights) and the Power Platform. It provides a managed relational database with tables, relationships, role-based security, business rules, calculated and rollup columns, server-side workflows, and a standardised Open Data (OData) Web API. Dataverse comes with a starter schema known as the **Common Data Model** that defines tables like Account, Contact, and User. Storage and API capacity are licensed through Dataverse capacity, included in most Dynamics 365 and Power Apps subscriptions.
## Microsoft Entra External ID
Source: https://www.solvingdynamics365.com/glossary/entra-external-id
**Microsoft Entra External ID** is Microsoft's customer identity platform — successor to **Azure AD B2C** — providing customer-grade authentication for external users accessing Power Pages portals, customer-facing Dynamics 365 apps, and any scenario where non-employee users need to sign in. External ID is hosted in a separate tenant from the workforce Entra ID directory, keeping customer accounts isolated from internal accounts. Supports **email / password**, **social identity providers** (Google, Facebook, Apple, LinkedIn), and **federated identity** from partner organisations. Features include branded sign-up / sign-in flows, MFA, custom attributes, password reset self-service, custom policies for complex scenarios. Billed per **monthly active user (MAU)**. The right answer for any customer-facing portal in 2026+.
## Microsoft Entra ID
Source: https://www.solvingdynamics365.com/glossary/entra-id
**Microsoft Entra ID** is Microsoft's cloud identity service — the rebrand of **Azure Active Directory (Azure AD)** announced in 2023. Every Dynamics 365 user signs in through Entra ID, regardless of which Dynamics 365 product they use. Entra also authenticates service-to-service API calls between integrations and Dynamics 365 via **app registrations** with delegated or application permissions. Tenant-level identity policies — **MFA**, **Conditional Access** (block risky sign-ins, restrict by location, require compliant devices), and **named locations** — apply automatically to Dynamics 365 access. Modern Dynamics 365 security relies on Entra; protecting Entra is protecting the platform.
## Microsoft Fabric
Source: https://www.solvingdynamics365.com/glossary/microsoft-fabric
**Microsoft Fabric** is Microsoft's unified analytics platform, combining lakehouse, data warehouse, real-time analytics, data engineering, data science, and **Power BI** on a shared SaaS storage layer called **OneLake**. For Dynamics 365 customers, Fabric is the increasingly default destination for cross-system analytics. **Synapse Link** streams Dataverse and F&O data into OneLake; Power BI in **DirectLake mode** queries the parquet directly with near-import performance and no refresh schedules. Fabric is sold in F-SKU capacity tiers; capacity sizing — peak Power BI users, lakehouse compute, model size — is the main cost lever. **Microsoft Purview** integrates for governance.
## Model-driven app
Source: https://www.solvingdynamics365.com/glossary/model-driven-app
A **model-driven app** is one of two Power Apps application types (the other being canvas). Model-driven apps are *generated* from a Dataverse schema — the maker configures which tables, forms, views, charts, dashboards, and business process flows are included, and the platform renders a responsive, security-aware UI automatically. Every Dynamics 365 CRM-side app (Sales, Customer Service, Field Service, Project Operations) *is* a model-driven Power App. Model-driven apps suit data-centric line-of-business scenarios with rich Dataverse schemas and complex security. Trade-off vs **canvas apps**: less layout flexibility but no UX code to write; advanced find, audit, dashboards, and security come for free. **Custom pages** (canvas-style screens embedded in model-driven apps) bridge the two.
## MRP (Material Requirements Planning)
Source: https://www.solvingdynamics365.com/glossary/mrp
**Material Requirements Planning (MRP)** is the algorithm that compares **demand** (sales orders, forecasts, production component needs, transfer requirements) against **supply** (on-hand inventory, open purchase orders, planned production orders, transfer orders) and suggests the new purchase, production, and transfer orders needed to keep stock balanced through the planning horizon. In Business Central it runs through the **planning worksheet**; in Dynamics 365 Supply Chain Management it runs through **Planning Optimization**, the modern in-memory engine that replaced the legacy MRP. Output is a set of **action messages** — *New*, *Increase*, *Decrease*, *Reschedule earlier*, *Reschedule later*, *Cancel* — that planners review and accept.
## OData
Source: https://www.solvingdynamics365.com/glossary/odata
**OData** (Open Data Protocol) is a standardised REST-style query syntax for querying and modifying data over HTTP. Dataverse's **Web API** (the `/api/data/v9.x/` endpoint) exposes OData v4. Standard OData operators — `$filter`, `$select`, `$expand`, `$orderby`, `$top`, `$skip`, `$count` — work across implementations. Used by external integrations, Power Automate's Dataverse connector, JavaScript on model-driven forms (`Xrm.WebApi`), Power BI direct query, and most modern HTTP clients. OData is the canonical choice for modern Dataverse integration; **FetchXML** remains relevant for views and complex analytical queries. Both compile to the same underlying SQL.
## One Version
Source: https://www.solvingdynamics365.com/glossary/one-version
**One Version** is Microsoft's policy for Dynamics 365 Finance and Supply Chain Management: every production environment, in every region, on every tenant, runs the same current platform version, updated continuously via **Service Updates** roughly every six weeks. Customers cannot remain indefinitely on older versions. Limited **pause windows** allow deferring updates for a small number of cycles per year (typically around year-end), but mandatory upgrades apply after the pause expires. Microsoft maintains this policy because supporting hundreds of AX-era versions in SaaS would be economically infeasible. The discipline is real; the benefits — continuous improvements, security patches, no big-bang upgrade projects — accrue over time.
## Opportunity
Source: https://www.solvingdynamics365.com/glossary/opportunity
An **opportunity** in Dynamics 365 Sales is a qualified, in-progress sales pursuit — a real deal with a customer, an estimated value, a likely close date, and a probability of winning. Opportunities are the pipeline. Each opportunity moves through configurable **business process flow** stages — typically Qualify → Develop → Propose → Close — with stage-gated fields capturing the deal's evolution. Opportunities can include products with quantities and prices, generating revenue forecasts. They link to Accounts and Contacts, accumulate activities (calls, meetings, emails), and ultimately close as **Won** (often converting to a Quote, Order, or Invoice) or **Lost** (with a reason coded for analysis). Sales forecasting rolls opportunities up by hierarchy; AI-predicted insights flag at-risk and high-momentum deals.
## Owner team
Source: https://www.solvingdynamics365.com/glossary/owner-team
An **owner team** in Dataverse is a group of users that can own records and have **security roles** assigned. Owner teams behave like users — records can be **owned by an owner team** (the Owner field references the team), and all team members inherit the team's security-role access when they work with team-owned records. Use cases include regional sales teams collectively owning regional accounts, service queues, project teams. Owner team membership is stable; admins manage members. Distinct from **access teams**, which can't own records but grant ad-hoc record-level access through templates. Owner teams can be linked to **Microsoft 365 groups** for synced membership from M365 to Dataverse.
## Permission set
Source: https://www.solvingdynamics365.com/glossary/permission-set
A **permission set** in Business Central is the unit of security — a named bundle of RIMDX rights (Read, Insert, Modify, Delete, eXecute) on tables, pages, codeunits, reports, and other database objects. Users get effective permissions by being assigned one or more permission sets, optionally bundled into **user groups** for easier administration. Microsoft ships built-in permission sets — SUPER, BASIC, SETUP, area-specific (SALES, PURCH, FA, etc.); customers copy and edit, or write new permission sets in AL. **Security filters** within a permission set add row-level restrictions. Modern practice grants table writes through *indirect* permission (via codeunit execution rights) rather than direct write rights, matching how Microsoft's standard code is designed.
## Plug-in
Source: https://www.solvingdynamics365.com/glossary/plug-in
A **plug-in** in Dataverse is a .NET assembly registered to run on specific Dataverse events (Create, Update, Delete, custom messages). Plug-ins execute server-side in a sandboxed environment, with full transactional context — they can read related records, throw exceptions to cancel the operation, and modify the target before write. The plug-in pipeline has four stages: **pre-validation** (outside the transaction), **pre-operation** and **post-operation** (inside), and an asynchronous queued path. Synchronous plug-ins block the user request; asynchronous ones queue for later. Plug-ins are the most powerful and most demanding customisation mechanism in Dataverse; modern practice favours **Power Automate flows** for orchestration and reserves plug-ins for transactional, performance-sensitive, server-only logic.
## Plug-in trace log
Source: https://www.solvingdynamics365.com/glossary/plug-in-trace-log
The **plug-in trace log** is Dataverse's diagnostic mechanism for **plug-ins** — server-side .NET code that runs on Dataverse events. When trace logging is enabled, every plug-in execution writes a record containing the runtime context, configuration, exception details (if any), execution time, and any messages the plug-in logged via `ITracingService.Trace()`. The traces are queryable through the **Plug-in Trace Log** table in the maker portal, supporting filtering by plug-in, by user, by time, by error status. Plug-in trace logging is invaluable for debugging — far better than guessing at server-side behaviour. But it generates substantial data; enable for debugging windows and disable or aggressively prune the table afterward to manage Dataverse storage.
## Posting group
Source: https://www.solvingdynamics365.com/glossary/posting-group
A **posting group** in Business Central is a tag attached to a customer, vendor, item, bank, fixed asset, or G/L account that drives the GL accounts hit when a transaction posts. The system uses intersections of posting groups to find the right account: **General Business Posting Group** (who you trade with) × **General Product Posting Group** (what's traded) drives revenue / expense accounts; **Customer Posting Group** drives AR control accounts; **Vendor Posting Group** drives AP control accounts; **Inventory Posting Group** + Location drives inventory balance-sheet accounts; **VAT posting groups** drive tax accounts; **FA Posting Group** drives fixed-asset GL flow. Designing posting groups carefully — five to ten per area is healthy — is one of the most consequential implementation tasks.
## Power Apps
Source: https://www.solvingdynamics365.com/glossary/power-apps
**Power Apps** is Microsoft's low-code application platform, part of the Power Platform. It supports two types of apps: **canvas apps**, which are free-form drag-and-drop apps built for tablet and mobile front ends; and **model-driven apps**, which generate forms, views, and dashboards from a Dataverse data model. Dynamics 365 CRM-side apps (Sales, Customer Service, Field Service) are themselves built on the model-driven framework. Power Apps connects to hundreds of data sources through standard and premium connectors, and is licensed per user, per app, or bundled with Dynamics 365 licenses.
## Power Automate
Source: https://www.solvingdynamics365.com/glossary/power-automate
**Power Automate** is Microsoft's workflow automation and robotic process automation (RPA) service, part of the Power Platform. It supports **cloud flows** triggered by events or schedules using hundreds of connectors (Business Central, Dataverse, SharePoint, Outlook, Teams, third-party APIs), **desktop flows** that automate legacy applications by driving the UI, and **business process flows** that guide users through stages of a Dataverse process. Power Automate is how most Dynamics 365 customers extend, automate, and integrate without writing traditional code, and is licensed per user, per flow, or bundled with Dynamics 365.
## Power BI
Source: https://www.solvingdynamics365.com/glossary/power-bi
**Power BI** is Microsoft's business intelligence platform, part of the Power Platform. It combines a desktop authoring tool (Power BI Desktop), a SaaS service for sharing and refreshing reports, and embedded analytics inside other apps. Power BI connects to hundreds of data sources, models data with the DAX language, and renders interactive dashboards and paginated reports. Dynamics 365 ships pre-built Power BI apps for finance, sales, service, and supply chain, and deeper analytics is enabled through Microsoft Fabric and direct Dataverse/F&O data lake links. It is licensed per user (Pro, Premium per user) or per capacity.
## Power Platform
Source: https://www.solvingdynamics365.com/glossary/power-platform
The **Power Platform** is Microsoft's low-code suite for extending and automating business applications, including Dynamics 365. It has four headline products: **Power Apps** for building custom canvas and model-driven applications, **Power Automate** for workflow and RPA, **Power BI** for self-service analytics, and **Copilot Studio** for building AI agents and chatbots. They share Dataverse as a common data platform and Microsoft Entra for identity. The Power Platform is how customers most commonly customise Dynamics 365 without writing traditional code, and it is licensed separately from but tightly integrated with the Dynamics 365 apps.
## Preview build
Source: https://www.solvingdynamics365.com/glossary/preview-build
A **preview build** is an early version of a Dynamics 365 release wave (or platform update) made available roughly six weeks before general availability. Customers spin up a **preview sandbox** from their admin centre, install their extensions and integrations against it, run their regression suite, and certify their AppSource apps against the upcoming version. The preview window is the canonical opportunity to catch breaking changes before they affect production. AppSource ISVs are expected to validate compatibility during preview; per-tenant extension owners must recompile and republish before the production update window. Skipping preview testing routinely causes preventable issues at wave updates; investing the few hours of preview validation prevents days of production firefighting.
## Queue
Source: https://www.solvingdynamics365.com/glossary/queue
A **queue** in Dynamics 365 is a holding container for records awaiting attention — most commonly cases in Customer Service, conversations in omnichannel, leads in Sales, work orders in Field Service, or generic work items. Queues are scoped by team or function: First-line Support queue, EMEA Sales queue, VIP Customer queue, Spanish-language queue. Routing rules direct incoming items to queues based on attributes; agents work from their assigned queues either by taking the next item (first-in-first-out) or by selecting specifically. **Unified Routing** in Customer Service uses queues alongside agent capacity profiles and skill matching to assign work optimally. Queue performance — depth, wait time, oldest item — is the primary real-time operational signal for supervisors.
## Quota
Source: https://www.solvingdynamics365.com/glossary/quota
A **quota** in Dynamics 365 Sales is the revenue or unit target assigned to a seller, team, or territory for a defined period — typically quarterly or annually. Quotas are modelled through the **Goals** mechanism: a Goal record with a Goal Metric (what's measured — revenue from won opportunities, count of new logos, units sold) and a hierarchical parent-child structure so individual seller quotas roll up to manager-level aggregates. Quotas integrate with **forecasting** for pipeline-coverage analysis (do we have enough pipeline to hit the number?) and feed commission calculations either natively or through specialist commission engines (Spiff, Performio, CaptivateIQ). Setting realistic quotas — calibrated against historical conversion — is one of the most consequential sales-management decisions.
## Release wave
Source: https://www.solvingdynamics365.com/glossary/release-wave
A **release wave** is Microsoft's twice-yearly major update for Dynamics 365 and the Power Platform — **Wave 1** in April, **Wave 2** in October. Each wave delivers new application features, new platform capabilities, performance improvements, and deprecations. The wave lifecycle includes a **preview** build available roughly six weeks before general availability, allowing customers to test in sandbox; **general availability** rolls out across the tenant base; **mandatory upgrade** completes the rollout by a published cut-off date. Customers configure an **update window** (a permitted offline span) for the upgrade to apply. Extensions on AppSource are pre-tested for compatibility; per-tenant extensions need customer / partner recompilation. Monthly hotfixes ship between waves.
## Retry policy
Source: https://www.solvingdynamics365.com/glossary/retry-policy
A **retry policy** is the configurable behaviour of an integration step when it encounters a transient failure — network timeout, brief service outage, HTTP 429 throttling, brief connector unavailability. Standard policies include **exponential backoff** (retry with increasing delays — 1s, 2s, 4s, 8s — to give the dependent service time to recover), **fixed-interval retry** (retry at constant intervals), and **immediate retry** (retry without delay; suitable only for very transient issues). Power Automate actions, Logic Apps actions, and Dataverse plug-in registrations all support configurable retry policies. Apply retry only to **idempotent operations** — non-idempotent ones produce duplicates on retry. After retries exhausted, route to dead-letter handling or alert operations.
## Ribbon (command bar)
Source: https://www.solvingdynamics365.com/glossary/ribbon
The **ribbon** — now more commonly called the **command bar** — is the row of action buttons at the top of every model-driven Power Apps page (Save, New, Delete, Email, plus custom actions). Each table has separate command bars per context: main form, list view, subgrid, associated view. Customisation today happens in the modern **command designer** in the maker portal, replacing the older XML-based ribbon configuration. Commands can run JavaScript functions, Power Fx formulas, Power Automate flows, or open Power Apps. Visibility and enabled rules expressed in Power Fx control when commands appear and when they're active. Commands can be **app-scoped** — visible in one model-driven app but not another, even on the same table.
## Role center
Source: https://www.solvingdynamics365.com/glossary/role-center
A **role center** in Business Central is the home-screen workspace a user opens to, curated for what their role does. Cues (numeric tiles), charts, action shortcuts, and notifications are tuned to the user's daily work — Accountant, Sales Order Processor, Production Planner, Warehouse Worker, IT Manager, Business Manager. Microsoft ships role centers for common roles; customers extend or build their own. Users **personalize** within their role center (hide cues, reorder shortcuts) without affecting other users; administrators **save as tenant default** to apply changes across all users of the role. Profiles assign role centers to user groups, and the **Designer** tool customises layouts without code.
## Rollup column
Source: https://www.solvingdynamics365.com/glossary/rollup-column
A **rollup column** in Dataverse is a column that aggregates values across related records — count of opportunities on an account, sum of revenue from won deals, latest activity date across contacts. Rollups persist the result, making them queryable and indexable (unlike **calculated columns** which compute at read time). The value refreshes on a schedule (default hourly) or on-demand via the *Refresh* action; between refreshes the value is stale. Aggregations supported: count, sum, average, min, max. One rollup column = one aggregation across one related-table relationship. For real-time aggregation, use plug-ins or Power Automate flows that maintain the value on every change. For sum-of-revenue-by-customer style analytics, **rollup columns** are the no-code answer.
## SaaS
Source: https://www.solvingdynamics365.com/glossary/saas
**SaaS** stands for *Software-as-a-Service*. It refers to software delivered as a managed cloud subscription, where the vendor owns the infrastructure, patching, backups, and upgrades, and the customer accesses the service over the internet. All Dynamics 365 apps — Business Central, Finance, Supply Chain Management, Sales, Customer Service, Field Service, and the rest — are sold primarily as SaaS, hosted on Microsoft Azure. SaaS shifts ERP and CRM from a capital project with multi-year on-premise infrastructure to an operational subscription with continuous updates, but in return constrains customisation to supported extensibility patterns rather than direct database access.
## Saga
Source: https://www.solvingdynamics365.com/glossary/saga
A **saga** is a pattern for multi-step business operations spanning multiple systems where each step is a local transaction in one system; if a later step fails, **compensating transactions** undo the earlier steps' effects. Used when a global ACID transaction across systems isn't possible — for example, placing an order updates Dynamics 365 CRM, debits F&O inventory, charges the payment processor, and dispatches the WMS. The saga pattern guarantees the operation either fully succeeds or fully rolls back across systems. Two implementation styles: **orchestration** (central orchestrator drives the sequence, typically Azure Durable Functions) and **choreography** (no orchestrator; systems react to events, with rollback events triggering compensation). Orchestration is cleaner for most Dynamics 365 cross-system scenarios.
## Sandbox
Source: https://www.solvingdynamics365.com/glossary/sandbox
A **sandbox** environment in the Power Platform and Dynamics 365 is a non-production environment intended for development, testing, training, demos, and risk-free experimentation. Sandboxes are isolated from production — separate database, separate users where appropriate, separate integrations. They can be **copied from production** (most common pattern, for testing with realistic data) or reset to clean state. Sandboxes typically have lower infrastructure priority than production — they may pause, throttle, or update sooner. Most Dynamics 365 SKUs include some number of sandboxes; additional sandboxes are paid add-ons. The healthy environment topology has at least one dev, one UAT, and one training sandbox per major Dynamics 365 deployment, alongside one or more production environments.
## Security roles
Source: https://www.solvingdynamics365.com/glossary/security-roles
A **security role** in Dataverse and the Dynamics 365 CRM-side apps is a named bundle of **privileges** on tables (create, read, write, delete, append, append-to, assign, share), each with a **scope** (user, business unit, parent:child BU, organisation). Users are assigned one or more security roles; their effective access is the union of all assigned roles. Microsoft ships built-in roles — *Salesperson*, *Customer Service Representative*, *System Administrator*, etc. — that customers copy and adjust. **Field-level security profiles**, **teams**, and **row sharing** complement security roles for finer-grained control. Designing a clean role hierarchy is one of the most important Power Platform implementation tasks; running an audit annually keeps it tidy.
## Service Bus
Source: https://www.solvingdynamics365.com/glossary/service-bus
**Azure Service Bus** is Microsoft's durable, queued messaging service. For Dynamics 365 integrations, Dataverse can publish change events to Service Bus queues or topics; downstream consumers — Azure Functions, Logic Apps, custom services — read at their own pace with built-in retry and a **dead-letter queue (DLQ)** for failures. Queues handle point-to-point delivery (one consumer per message); **topics** support pub/sub with multiple subscribers each receiving their own copy. Service Bus is the canonical pattern for **decoupled, durable, asynchronous** Dataverse integration at moderate-to-high scale — more reliable than webhooks (which lack retention), more durable than Event Grid (which is lighter-weight pub/sub). Standard tier handles hundreds of messages per second; Premium handles thousands.
## Service principal
Source: https://www.solvingdynamics365.com/glossary/service-principal
A **service principal** in Microsoft Entra ID (formerly Azure AD) is an identity for non-human callers — applications, services, scripts, pipelines, integrations — that need to authenticate without a user. The service principal is created from an **app registration** with a client ID, client secret (or certificate), and configured permissions. Integrations between systems (Power Automate calling Dataverse, Azure Functions writing to Dataverse, CI/CD pipelines deploying solutions) authenticate as service principals. Service principals are granted appropriate Dataverse security roles or specific table permissions. **Managed Identity** is the recommended Azure-hosted variant — eliminates credential management because Azure handles the rotation. Always prefer service principals over user accounts for automation; they're auditable, manageable, and don't break when employees leave.
## Site map
Source: https://www.solvingdynamics365.com/glossary/site-map
The **site map** of a model-driven Power App is its navigation structure — the left-side menu users see. The hierarchy: **areas** (top-level groupings, switchable from a button), **groups** (labelled subdivisions within an area), **subareas** (the actual navigation items that link to a table's page, a view, a dashboard, a URL, a custom page, or a web resource). Site maps can be **role-scoped** — different subareas visible to different security roles. The modern **site map designer** in the maker portal replaced the older XML-based configuration. The site map shapes the daily user experience of the app; deliberate design — group by what users *do*, not by underlying tables — is one of the most consequential UX investments in a model-driven app.
## SLA (Service Level Agreement)
Source: https://www.solvingdynamics365.com/glossary/sla
A **Service Level Agreement (SLA)** in Dynamics 365 Customer Service is a time-based commitment to customers — "we'll respond within 1 hour, resolve within 4 hours" — modelled as records that track and enforce response and resolution targets per case. SLAs have **KPIs** (First Response By, Resolve By, custom) with **warning** and **failure** thresholds, **business calendars** (so the clock respects working hours), and **pause** rules (the clock stops when the customer's the bottleneck). SLAs apply to cases either by default or through **entitlements** linking specific contractual terms to customers. Real-time timer widgets on the case form show countdown to breach; Power Automate flows fire escalation actions on warning or breach. The visible discipline drives operational behaviour.
## Solution Checker
Source: https://www.solvingdynamics365.com/glossary/solution-checker
**Solution Checker** is Microsoft's static-analysis tool for Power Platform solutions. Run on a solution (packaged or in-environment), it scans every component — Power Automate flows, canvas apps, model-driven apps, Power Pages, Dataverse plug-ins, custom JavaScript — against a published rule set covering performance issues, security concerns, accessibility problems, deprecation warnings, and platform-misuse patterns. Results are categorised as Critical / High / Medium / Low; teams gate PR builds on no Critical or High issues remaining. The checker runs from the Power Platform admin centre, from the maker portal, from the `pac` CLI, and as a step in Azure DevOps or GitHub Actions pipelines. The rule set updates with each platform release; running periodically catches issues introduced by new lint rules.
## Solution patch
Source: https://www.solvingdynamics365.com/glossary/solution-patch
A **solution patch** in the Power Platform is a delta solution containing only the changes made since a base solution version. When a patch is imported, it layers on top of the existing base solution in the target environment — the base remains unchanged; the patch adds its modifications. Patches are faster to build and deploy than full upgrades and are the right tool for incremental fixes, hotfixes, and additive features. They cannot *remove* components from the base, only add or modify. Over time, multiple patches stack; periodic **solution upgrades** consolidate them into a new base, keeping the patch stack manageable. The healthy lifecycle pattern combines patches for speed with upgrades for cleanliness.
## Solutions
Source: https://www.solvingdynamics365.com/glossary/solutions
A **solution** in the Power Platform and Dynamics 365 CRM-side apps is a versioned, deployable container of customisations: tables, columns, forms, views, business rules, Power Automate flows, canvas apps, model-driven apps, security roles, Copilot Studio agents, and many other component types. Solutions are the unit of **application lifecycle management** — develop in one environment in an **unmanaged** solution, export as a **managed** package, import to UAT and production. Solutions can be unpacked into XML/YAML files for source control with the **`pac` CLI**, enabling Git-based development, code review, and CI/CD pipelines. The right ALM discipline in Power Platform begins with solutions.
## Success by Design
Source: https://www.solvingdynamics365.com/glossary/success-by-design
**Success by Design (SBD)** is Microsoft's published implementation methodology for Dynamics 365. Replacing the older waterfall-flavoured Sure Step, SBD is iterative, fit-to-standard-first, and built around regular checkpoints rather than gated phases. It has five overlapping phases — Initiate, Implement, Prepare, Operate, Optimize — each with documented practices, deliverables, and review rituals. The headline ritual is the **Solution Blueprint Review (SBR)**, a mid-implementation architecture review against a published rubric. FastTrack engineers use SBD; mature partners adopt it. Templates, checklists, and reference architectures are freely available on Microsoft's SBD website.
## Synapse Link
Source: https://www.solvingdynamics365.com/glossary/synapse-link
**Synapse Link** is Microsoft's managed near-real-time pipeline that streams **Dataverse** (and, in a separate variant, **Finance and Supply Chain Management**) change data into a customer-accessible lakehouse — historically Azure Data Lake Storage Gen2, now increasingly **Microsoft Fabric's OneLake**. Once configured per environment, Dataverse continuously writes Delta-Parquet snapshots of selected tables to the lake without replicating into a customer-managed integration tier. Downstream consumers — Power BI, Fabric notebooks, SQL endpoints, custom analytics — read from the lake without touching the operational system. Synapse Link replaces the older **Export to Data Lake** and **Bring Your Own Database (BYOD)** patterns and is the recommended analytics path for Dynamics 365.
## Task Recorder
Source: https://www.solvingdynamics365.com/glossary/task-recorder
**Task Recorder** is a built-in Dynamics 365 Finance and Supply Chain Management tool that captures the user's actions in the application as a structured, replayable script — clicks, field entries, page navigation, validation. The output is a recording that can be:
- **Played back** to train new users on a process.
- **Embedded in the in-app Help pane** so users see step-by-step guidance in context.
- **Integrated with the Business Process Modeller** in Lifecycle Services to link processes to actual application steps.
- **Used in test automation** to drive scripted regression tests.
- **Exported as documentation** with screenshots for offline training.
The result is genuine, accurate documentation that doesn't drift from reality — because it *is* reality, recorded. Task Recorder is one of the underused gems of F&O implementations.
## TDS endpoint
Source: https://www.solvingdynamics365.com/glossary/tds-endpoint
The **TDS endpoint** is Dataverse's SQL Server-compatible **read-only** query endpoint. TDS (Tabular Data Stream) is the protocol SQL Server uses; tools that speak TDS — SQL Server Management Studio (SSMS), Power BI's SQL Server connector, ODBC / JDBC drivers, Tableau, Qlik — can connect to the TDS endpoint as if it were a SQL database. Connections authenticate via **Microsoft Entra ID** at port 5558. Supports full T-SQL syntax for SELECT queries — joins, aggregations, window functions, subqueries, CTEs. **No writes** — INSERT / UPDATE / DELETE not supported. Security (security roles, business units, field-level security) is honoured. For analytics at scale, **Synapse Link for Dataverse** is preferred; TDS suits SQL-aware ad-hoc analysis and moderate-volume Power BI direct queries.
## Tenant
Source: https://www.solvingdynamics365.com/glossary/tenant
A **tenant** in the Microsoft cloud is the top-level container for a customer organisation: one Entra ID directory, one set of users and licences, and a collection of environments (Microsoft 365, Power Platform, Dynamics 365, Azure subscriptions linked to the tenant). All Dynamics 365 access flows through the tenant's Entra ID; all Power Platform environments belong to the tenant; all licence assignments happen at the tenant level. Tenants are pinned to a region at creation. **Tenant administration** is split across several admin centres — Microsoft 365 admin centre, Power Platform admin centre, Business Central admin centre, Lifecycle Services — each owning a slice. One tenant per customer is the standard pattern; multi-tenant configurations exist for specific scenarios but add complexity.
## Throttling
Source: https://www.solvingdynamics365.com/glossary/throttling
**Throttling** is the rate-limiting mechanism Microsoft services apply to API calls — protecting platform capacity from runaway consumers. Dataverse, Business Central, Finance and SCM, Power Automate connectors, and Microsoft Graph all enforce throttling. When a consumer exceeds the configured rate, the service responds with **HTTP 429 (Too Many Requests)** plus a `Retry-After` header indicating how long to wait. Well-behaved integrations honour the `Retry-After` value with exponential backoff; chatty integrations that ignore throttling degrade everyone's experience and risk being further rate-limited. Throttling limits include per-user-per-minute, per-tenant aggregate, and per-connector-specific limits. Batch operations, filtering at the source, and caching reduce API call volume; capacity add-ons can raise the ceiling at scale.
## Timeline
Source: https://www.solvingdynamics365.com/glossary/timeline
The **timeline** is a control on Dynamics 365 model-driven app forms that shows all activities, notes, and posts related to the current record in chronological order. It's the central history view on a Customer, Contact, Opportunity, Case, or Lead — every email, phone call, meeting, task, and note in one scroll. Users can filter by activity type, date range, owner, or status. New activities created from the timeline auto-link to the parent record. Timeline configuration (which activity types appear, default filters, sort order) is per-form. The timeline replaced the older "Activities" subgrid pattern as the recommended way to display interaction history; it's user-loved when configured cleanly and scrolling endlessly through unfiltered noise when it isn't.
## Trade agreement
Source: https://www.solvingdynamics365.com/glossary/trade-agreement
A **trade agreement** in Dynamics 365 Finance and Supply Chain Management is the pricing and discount rule model — defining what price applies to which customer for which items under which conditions. Trade agreement lines specify rules at varying levels of specificity: customer-and-item, customer-and-item-group, customer-group-and-item, all-customers-and-item, etc. Each line has effective dates, a price or discount type (fixed, percentage), and optional qualifiers (quantity tiers, currency, site, warehouse). The engine resolves the most specific applicable rule at transaction time. Trade agreements supplement the standard sales / purchase price on items; they're the canonical pattern for customer-specific contracted pricing, volume discounts, promotional pricing, and per-currency pricing in international operations.
## UAT (User Acceptance Testing)
Source: https://www.solvingdynamics365.com/glossary/uat
**User Acceptance Testing (UAT)** is the customer-led testing cycle that validates a Dynamics 365 implementation against real business scenarios before go-live. Unlike unit, integration, and performance testing — which are partner-and-developer responsibilities — UAT is run by the *people who'll use the system* against *end-to-end business processes*, not isolated screens. A well-run UAT covers all core operational flows, all workflow paths, all integrations, and edge cases specific to the customer's industry and region. The exit criteria typically require all severity-1 and severity-2 defects resolved, business sign-off, training material aligned, and performance acceptable at expected user load. UAT is the customer's confidence check; skipping it ships uncertainty.
## Virtual table
Source: https://www.solvingdynamics365.com/glossary/virtual-table
A **virtual table** in Microsoft Dataverse is a table whose data is not stored in Dataverse but is fetched from an external system on demand. To Power Apps, Power Automate, Copilot Studio, and Dynamics 365 CRM apps, the virtual table looks like any other table — same query semantics, same forms and views, same relationships — but reads (and sometimes writes) go to the configured external source. Common use cases: surfacing **Dynamics 365 Finance / Supply Chain** data inside CRM-side apps without replicating; pulling **SQL Server** or **SharePoint** data into Power Apps; exposing custom APIs through OData adapters. Virtual tables avoid replication and stay current, but performance is bounded by the source system's responsiveness and API throughput.
## Warehouse management
Source: https://www.solvingdynamics365.com/glossary/warehouse-management
**Warehouse management** (WMS) is the set of processes and software that controls the physical movement of inventory inside a warehouse. In Business Central, warehouse complexity is configured per location, from basic posting through receive/ship documents up to fully **directed put-away and pick** with bin policies. **Dynamics 365 Supply Chain Management** includes a full enterprise WMS with handheld scanning, configurable mobile workflows, wave management, license plates, and slotting. WMS objects include **warehouse receipts**, **put-aways**, **movements**, **picks**, **shipments**, **counting journals**, and bin replenishment between bulk and pick zones.
## Web API
Source: https://www.solvingdynamics365.com/glossary/web-api
The **Dataverse Web API** is the HTTP REST endpoint at `/api/data/v9.x/` that exposes Dataverse for programmatic access. It supports **OData v4** query syntax (`$filter`, `$select`, `$expand`, etc.), full CRUD operations (GET, POST, PATCH, DELETE) on every entity, bound actions, custom actions, and batch operations through the `$batch` endpoint for multi-operation HTTP round-trips. Authentication uses **Microsoft Entra ID** OAuth 2.0 — service-principal or user-context tokens. The Web API is the primary integration surface for Dataverse from external systems, JavaScript on forms (via `Xrm.WebApi`), Power Automate flows, custom code, and SDK clients. It superseded the older SOAP-based **Organization Service** for most modern use cases.
## Webhook
Source: https://www.solvingdynamics365.com/glossary/webhook
A **webhook** is an HTTP POST sent by a source system (Dataverse, Business Central, Power Automate, third-party SaaS) to a subscriber-defined URL when an event occurs. For Dynamics 365, webhooks deliver near-real-time change notifications without polling. Dataverse webhooks fire on record events with a configurable payload; Business Central webhooks fire on table changes with the resource URL (subscribers fetch the full record on receipt). Webhooks are simpler than Service Bus or Event Grid — no Azure resource — but offer limited retry (a few immediate attempts) and no durability. They suit low-volume, tolerant integrations where the subscriber is highly available. For higher reliability or larger volume, layer webhooks → Service Bus → durable consumer.
## WIP (Work in Process)
Source: https://www.solvingdynamics365.com/glossary/wip
**Work in Process (WIP)** is the cost of partially-completed work that has been incurred but not yet matched to revenue. In **production**, it's the materials consumed and labour applied to a production order that's been started but not yet finished — held in a WIP balance-sheet account until the production order completes and the finished item is received into inventory. In **projects** (Business Central Jobs, Project Operations, F&O Projects), WIP defers project cost to the balance sheet until revenue is recognised — on completion, on milestone, or through percentage-of-completion calculations. WIP is what keeps the P&L honest while work is in progress: cost doesn't hit expense until the matching revenue is recognised.
## Work order
Source: https://www.solvingdynamics365.com/glossary/work-order
A **work order** in Dynamics 365 Field Service is the central record representing on-site work to be performed at a customer location — a service visit, an installation, a repair, an inspection, a maintenance task. Work orders carry: the customer, the location and asset being serviced, the products and services required, estimated duration, skills needed, priority, status. They're created from cases (a customer-reported problem), incidents, **preventive maintenance** schedules, **IoT alerts** (from Connected Field Service), or manually. The lifecycle: Created → Scheduled (to a resource via the schedule board or RSO) → Travelling → On Site → Completed → Posted. The technician executes on mobile; time, parts, photos, signatures, and inspection results capture on the work order; cost and revenue post on completion.
## XRMToolBox
Source: https://www.solvingdynamics365.com/glossary/xrmtoolbox
**XRMToolBox** is a free, open-source Windows desktop application that hosts hundreds of community-built plug-in tools for Dataverse (and Dynamics 365) administration and development. Essential tools include **FetchXML Builder** (visual query construction), **Plugin Trace Viewer** (debugging server-side code), **Bulk Data Updater** (mass record changes), **Solution Compare** (diff between solutions), **Ribbon Workbench** (command-bar customisation), and dozens more. Each tool is community-maintained and installable from the in-app marketplace. Together they fill the gaps in Microsoft's official tooling — almost every serious Dataverse practitioner uses XRMToolBox daily. Free, MIT-licensed, with active community support.