27

If there are Customer Assets that change their location from time to time (cars, ships, lorries, trains, construction machines, ...) it is painful to appropriately plan Work Orders ahead of time for the same Asset but changing locations. When trying to decouple a Customer Asset from the Service Account you're most likely to get an error "The customer asset must be related to the service account of the current work order." when you try to add Work Order Incidents / Service Tasks / Products / Services to the Work Order and want to utilize the OOB Customer Asset field in those Sub-Records. Otherwise, if you're not able to rely on the address provided by the Asset's Account, you would need a custom plugin/async process to overwrite the address on the Work Order. So it would be great if this restriction would be lifted.

Category: Work order
STATUS DETAILS
Completed
Ideas Administrator

Thanks for sharing your feedback. We believe we grasp what you are trying to do; however, to ensure our understanding, please answer the following questions:

  • In this scenario, it sounds like the mobile asset could be treated as a Service Account with an address and geolocation that changes. In what ways are these mobile assets distinct from a Service Account?
  • Does it often cross territories?
  • Can you help us understand why it is treated as a Customer Asset?
  • How far in advance is work scheduled?
  • Can you share any other relevant use-case details that makes enabling associating a customer asset to any service account the best way to manage work on these items?

Jason Cohen

PM, Microsoft

Comments

M

Great news! Based on your feedback, we were able to include this capability as part of update 2 for EA wave 2. Admins can opt to disable the asset validation, and there is even an option to suggest to change the asset's account if it is used on a work order with a different account. Thank you for your votes! We will publish to the release plan and update docs shortly

Category: Work order

M

We have come across this issue when during our move from a custom field service solution in DynCRM2016 to D365CE Field Service.

We perform services on fixed assets - water pumps in fixed installations, usually in buildings, where one building can house multiple installations. We manage these using the Customer Asset functionality, and need a way to store the address or geolocation of these assets. Since the locations may be relevant before we know of any actual assets (for example in a sales opportunity context), and because one location may contain multiple assets, we must normalise this address data from the asset, using a separate entity[1].

These locations are physical locations, and as such we are averse to the idea of using the Account entity to store the location: the Account is, per Microsoft Docs, a "Business that represents a customer or potential customer. The company that is billed in business transactions."

The customers that request service often have no permanent association with the asset. Much of our business is requested by third parties such as installers that may change from incident to incident for a given asset, so the relation between asset and service requestor is case specific, not asset specific.

Furthermore, while the account address may be identical to the service address if a business needs service at their own location, this is coincidental rather than a generic property of the asset's location, and may change for any location whenever a building's owner changes, for example.

For these reasons, we would like to keep the Account/Contact structure separate from the Location/Asset structure, but as it stands, the Field Service module forces us to mix these logically disparate records and artificially separate them by flagging them as either business or physical location.

[1] Instead of a separate location entity, we could use a Master Asset categorised as a 'location', but that would not change the issue at hand.

Category: Work order

M

A couple of scenarios I have run into several times which is impacted by this is with companies that share large assets such as heavy equipment across multiple branch locations. Think of a company that has bulldozers, dump trucks, front end-loaders, etc. which are shared across their various sites. The equipment moves frequently and transferring them to the different locations is not realistic. The requirement is to have the equipment owned by the parent company (Billing Account) but serviced at their branch locations (Service Accounts). We cannot set it up this way, however, because of the restrictions related to functionality referenced in this Idea.

Another example is a company that provides rentals of assets. Think of a rental car company, lets say Hertz. The cars are tracked as Assets that need to be serviced, but the Assets cannot realistically be owned Hertz's branch at the Atlanta Airport since that same car could likely be at the Miami Airport a week later. Again, the car Asset needs to be owned by the Hertz Corporation (Billing Account) but serviced at the Hertz Atlanta Airport or Hertz Miami Airport locations (Service Account).

Category: Work order

M

This restriction caused significant issues for us as well and required us to develop costly workarounds since this restriction impacts functionality at multiple levels (work order, work order products, work order incidents, work order service tasks). This restriction may have made sense for some customers in the past but it is not viable for customers such as those described.

Category: Work order