Field Service pricing vs ERP pricing: How to turn off the Clash

In Dynamics 365 Field Service, pricing and cost can be calculated by Field Service itself (using features like price lists, products, services, agreement pricing, etc. within Field Service). However if you'd like, you can always disable it.

This happened in one of our environments that a solution dependency was created. When I looked, there was a solution installed with the name: msdyn_FieldServiceDisablePricingComponents

I tried looking at sources from where I can download and install this solution. However, this simple setting in Field Service solves it.

When people say “install the Field Service Disable Pricing Components solution”, they’re usually referring to a built-in capability controlled by Field Service Settings, not a separate managed solution you import into Dataverse.

The practical outcome:

• Field Service stops calculating price and/or cost
• Another system becomes the source of truth (e.g., Project Operations, Finance & Operations, or an ERP)

Prerequisites

Before you change settings, make sure you have:

• Administrator rights to the Power Platform environment (System Administrator / Field Service Admin equivalent).
• Dynamics 365 Field Service installed in the environment.
• Access to the Field Service app and the Settings area.

Step-by-step: Disable pricing components

Step 1: Sign in

• Open the browser.
• Sign in to your Dynamics 365 Field Service instance.
  

Step 2: Open Field Service Settings

• Go to the Field Service app.
• In the sitemap (left navigation), switch to Settings (typically near the bottom).
• Under General, select Field Service Settings.

Step 3: Change Work Order / Booking pricing options

• Open the Work Order / Booking tab.
• Update these settings:
• Calculate Price = No
• Calculate Cost = No
• Select Save & Close.

That’s it—Field Service will stop calculating those values internally.

Find what’s hiding a field in Dynamics 365: Step-by-Step with PowerApps Live Monitor

A Little Background

A field (msdyn_customergroupid / Customer Group) exists in Dataverse for the Account table, but it is not showing on the Account form in a Dynamics 365 model-driven app. Our requirement was to show this on the form and I know that we had made it visible on the Account form.

However, after a deployment we noticed that it wasn't the case. Now it could be because on various reasons:

• The field is hidden on the form level.
• Column security profile was implemented.
• There is a business rule, due to which it was hidden.
• There is a script, due to which the field was hidden.

Our Approach

The easiest way to rule out the problem is to start with the simplest reason and work your way up.

Step 1 - To check if field was hidden on the form

We checked if the field was hidden on the form? It wasn't. That was easy.

Now, to check Business Rules and Script was a hard road for us because we had 20+ rules and many functions written on form load.

Step 2 - Run quick form-runtime checks (console logic)

We used simple client checks to classify the problem.

This is the fastest way to know whether you’re dealing with design-time vs runtime.

Click F12 > Console and run these commands:

Xrm.Page.getControl("msdyn_customergroupid")

If the call returns null, the field is not on the form. For us, tt returned the Control means something must be hiding it.

Xrm.Page.getControl("msdyn_customergroupid").getVisible()

If it returns a control, something must be hiding it. We ran the below command to confirm:

It returned FALSE.

Step 3 - Use PowerApps Live monitor to capture the visibility change

When I opened the PowerApps Live Monitor and performed the steps within the App, I captured a Live monitor event:

• dataSource: Forms.FormChecker.ControlStateChange
• controlName: msdyn_customergroupid
• visible before: true
• visible after: false

And the call stack included:

• M.setVisible(...)
• pbl_c3f86e4e73b7ed1183ff6045bd8c93df(...)
• Mscrm.BusinessRulesScript.Initialize(...)

Key Finding:

The field was initially visible, then explicitly hidden at runtime by a business rule script.

This pattern indicates the visibility change came from a Business Rule (Power Apps compiles business rules into runtime scripts, commonly visible as pbl_<guid> style functions).

So we could say with confidence:

✅ A Business Rule running on the Account form hid Customer Group by calling setVisible(false).

✅ Not JavaScript web resources. Not security. Not form XML missing. Not personalization.

✅ Focused our attention to look at all the business rules and we could find the culprit.

Hope this helps!