Customer Engagement & Dynamics CRM Forum

 View Only
  • 1.  Accounts for Customer Sites vs. Using a Custom Entity (Field Service)

    Posted Aug 27, 2019 03:47 PM
    Edited by Robert Vessie Aug 27, 2019 04:05 PM

    We're an HVAC service and mechanical construction company that is in the process of structuring our Dynamics365 CE platform (for Field Service, Project Service Automation, and CRM/Sales).

    One of the more fundamental items we are trying to determine (before we begin configuring and customizing) is whether to use a custom entity for "Customer Sites."   Our consulting partner is advocating that we utilize Accounts for this purpose, by designating the Account Type as "Site" and making it the subordinate account to the Parent Billing Account.

    They say that we run the risk of running into issues with future updates, if we go the route of creating the custom entity. 

    I'm not sure I agree, as all of the custom entities I've deployed in our existing production instance (for CRM/sales) have not had any issues since 2012. 

    My hesitation to utilize Accounts for Customer Sites stems from the fact that we envision a Many-to-Many (N:N) relationship between Accounts and Customer Sites, and we were therefore thinking it made the most sense to un-bundle the two.

    In our business it is certainly not uncommon for one customer Account to have multiple/different Customer Sites associated with it (e.g. large property managers or commercial real estate owners with multiple sites).  If that was it, then a parent and subordinate relationship between two Account types (i.e. the Billing Account and the Site) would suffice.   But in our business it is also possible to have multiple Accounts associated with a single Customer Site.  For example, on Customer Site XYZ, we might perform work for the tenant, the owner, a general contractor (GC) or a construction manager (CM).  Hence, we were thinking a Many-to-Many relationship makes more sense. We also have entirely different data fields we want to track for the Customer Site vs. the Account. 

    We additionally want the Customer Assets (equipment we install/service) to be subordinate records associated to the Customer Site (parent entity), so that when the site changes hands and is purchased by a new Customer Account, we can easily maintain the continuous service history of the Site and Assets under the new ownership Account.

    Does anyone see any reason why we shouldn't create a custom entity for Customer Sites?  Is there inherent functionality in the Account entity and how it relates to Work Orders, Cases, Invoices, Orders, etc. that would make this a bad idea?

    Appreciate any feedback the community can provide.

    -Rob V.

    Rob V.


  • 2.  RE: Accounts for Customer Sites vs. Using a Custom Entity (Field Service)

    Posted Aug 28, 2019 04:14 AM

    We're using Billing and Service accounts in the way your D365 partner recommends and it works fine.  I can't see how you'd benefit from creating what is essentially another account entity.  Bear in mind that a lot of the OOB reporting relies on standard entities rather than custom entities.

    I'd just use the standard account entity as the "path of least resistance" - very little needed to get going.


    Stewart Tranter
    Business Systems Manager
    TCL Group
    Derbyshire, UK

  • 3.  RE: Accounts for Customer Sites vs. Using a Custom Entity (Field Service)

    Posted Aug 28, 2019 08:39 AM
    We use separate entities as you are suggesting.  We have the complication that the accounts are integrated with our ERP, so having to weed out the sites would be more complication than it's worth.  But I'm just expecting that your sites won't be looking for nearly the level of detail that actual accounts are, and a separate entity feels more organized.  I've never heard of any reason to be concerned with custom entities (and boy I'm in trouble if that's really a thing lol).  We also have one account to many buildings.  In the other direction, tying other accounts to that building (GC, contractor(s), etc) are done on a case by case basis (opportunities).   Good Luck!

    Tim Miller
    IT Manager
    R.L. Deppmann

  • 4.  RE: Accounts for Customer Sites vs. Using a Custom Entity (Field Service)

    Posted Aug 28, 2019 10:17 AM
    Edited by Rex Kenley Tan Aug 28, 2019 10:18 AM


    I would like to know what those risks are as well. We currently have over 300+ custom entities and I have been updating from 8.2 to 8.2.8 (8 updates with no issues). I hope your consultant is not pulling your chain just to avoid work. *wink*

    The best question to ask about creating a new entity is how many fields are there that won't be used by the account entity? If it's just one (the discriminator) then I would go with your consultant's recommendation.

    A self referencing N:N relationship is supported in Crm

    or you can also use connection roles.

    Based on what you have written, I would say connection roles are your best bet.


    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.

  • 5.  RE: Accounts for Customer Sites vs. Using a Custom Entity (Field Service)

    Posted Aug 28, 2019 10:50 AM
    Hi Rob,

    As a partner, I've been presented this challenge a few times (we work with a number of home security companies) - my approach was to use a custom entity.  As you've expressed, the many-to-many relationship between company, contacts and where things are installed can be tricky, and I always felt it was easier to represent when something was physically installed as a separate thing.  You also brought up a great point about history when a site changes hands - that was another big reason we went with a custom entity.  I also like to keep Accounts as representing a company, as opposed to multiple different things.

    In our case, we called this entity "System", to avoid a conflict with the out-of-the-box "Site" entity, although I think calling it "Customer Site" would be fine too.

    We added relationships where required, to things like Cases, and with these systems being in place for many years now, haven't run into any majors gotchas.


    Nicholas Hayduk
    Engineered Code Consulting Inc.
    Regina SK

If you've found this thread useful, dive deeper into User Group community content by role