Personalized Community is here!
Quickly customize your community to find the content you seek.
Check out the latest Field Service updates!Learn about the key capabilities and features of Dynamics 365 Field Service and experience some of the new features.
Download overview guide | Watch Field Service video
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
In OOTB Dynamics 365 the same address (e.g. Some Address 1, USA) can and needs to be created for two different customers, which gives us challenges in terms of customer asset "ownership" and identification (i.e. ensuring we do not created duplicate customer assets).
An example could be a mall.
Store 1 is created as a billing account with the service account Some Address 1, USA. Upon servicing this customer, a customer asset ABC is created.
4 months later, the the owners of the mall contact us to purchase our services. The mall owners are created as a billing account with the service account Some Address 1, USA.
Since customer asset ABC is associated with the other Some Address 1, USA (belonging to Store 1), we will obviously not see it under the newly created service account Some Address 1, USA.
One could argue - given we can actually identify the customer asset ABC, which in itself is a challenge - that it should be moved to the newly created address. But what happens if Store 1 contacts us again? We will have the same challenges identifying the customer asset, and the process is manual.
One could also argue that functional locations should be used, because they can be "shared" between different service accounts. However, the functional location visualization tree (where customer assets can be shown) ONLY shows the customer assets associated with a specific service account so that gives us the same challenge.
Currently, the only solution we see to the issue is to create a unique service account (integrating to an external database). So in the scenario above, the 2 service accounts with the same address would be populated with a unique ID from the database upon creation, which in turn enables us to create a unique service account automatically. On the unique service account, functional locations and assets would be linked/owned. This ensures it is the unique address which owns the asset (and the functional locations). If the mall gets sold or Store 1 is rented by some other company, they can be created as new billing and service accounts as described above, but the unique address logic would ensure no information about the customer asset and functional locations are duplicated and can easily be found. Also, it would remove the need to manually identify and move customers assets around. In other words, the customer asset is owned by a unique address and in theory not by a customer - a given customer just pays for the servicing of the asset at a given point in time.
It does involve a lot of customization and changes to the standard processes, so have others faced similar challenges which they solved in a better way?
Let's think the Service Account and Customer Asset will be related to the Work Orders regardless of the customer so we can keep the history of services.
When you create the Work Order manually and select the Service Account, Field Service will populate the default Billing Account (which should be the most common scenario for the service account), but you can change to the correct customer.
When the customer buys your services, do you create agreements? You can set a different account for each of them.
I had a similar scenario when the mall had a building manager to look after the property so that the work order would invoice the mall or the building manager depending on the type of service. For the proactive maintenance, the agreement works well. However, when there is reactive maintenance, we created a field in the service account with the billing information, this field would be visible in the work order form via a quick view form so the agent knows how to set the billing account.
You also can consider the opportunity if it is a one-off work order for the shop or the mall. It is likely they would talk to the salesperson first so you could solve it through the opportunity process.
Building on Gabriels suggestion....Create store 1 (within the mall) as an account, create the mall itself as an account, and a functional location (the mall) as some address 1.
Create asset ABC at the functional location, with the account on the asset being the owner of the asset.
When you create the work order, the billing account is who pays the bill, the account is the entity you are providing service for (these very well may be the same as gabriel mentioned), and then functional location as the physical location of service (which could be the same as the service account). This gives you full flexibility where the functional location always stays the same (unless the physical asset moves) and then the service/billing accounts can change on the work order between the tenant of the store and the mall itself based on the scenario.
If asset ownership changes, you just change the account field on the asset to the new owner, but the functional location on the asset doesn't change. This lets you have full service history on the asset and since the work order can have different accounts for the same work order, you have full history for the accounts as well.
This video walks you through details including how to link functional locations to two accounts at the same time -
If you need even more flexibility between assets and accounts, this video shows you how to disable the validation that requires you to select the same account on the work order as the account on the asset
The feature was meant precisely for the scenario you describe so I hope it helps!
Business Applications communities