Customer Engagement & Dynamics CRM Forum

Expand all | Collapse all

Creating custom entity to replace Account

Jump to Best Answer
  • 1.  Creating custom entity to replace Account

    SILVER CONTRIBUTOR
    Posted 08-10-2018 04:39 AM
    The account entity does not model what our business consider to be an account. If I create an entity 'Client' and link contacts, activities etc to this instead of account, will there be any functionality I lose as a result of not using Account?

    ------------------------------
    Pete Axtell
    Winton
    ------------------------------


  • 2.  RE: Creating custom entity to replace Account
    Best Answer

    GOLD CONTRIBUTOR
    Posted 08-10-2018 08:36 AM
    Pete,

    At the end of the day, it really depends on your customer's business needs.  But Accounts and Contacts are so central to the Dynamics 365 model, I would try to avoid replacing it if possible.  Just check out how many related relationships there are related to the Account entity (Settings > Customizations > Entities > Account) , and you will see there is a lot tied out-of-the-box to this Entity (well over 100 1:N, N:1 and N:N relationships).  And then consider how many delivered forms it appears on, and how many views, charts, reports, etc.  You would likely find an awful lot of clean-up work trying to remove Accounts from everywhere it pops up in Dynamics 365.   Delivered Account Hierarchy functionality would be lost.  If you plan to use SharePoint connector, most select the Account or Contact centric folder structure - so that is another option you might find limiting if you go with a custom entity.   I think the more you dig in, you will find that replacing the delivered Account entity with a similar entity will be very difficult.

    You mentioned that it does not model what your business considers an Account.  Is it possible to extend the delivered Account entity either by adding fields or adding a related table, to provide the additional information you need?


    ------------------------------
    Patrick O'Donnell | VP - Business Development, the Americas
    mscrm-addons.com
    Patrick.ODonnell@mscrm-addons.com
    Atlanta GA
    770 781 8260 Cell
    ------------------------------



  • 3.  RE: Creating custom entity to replace Account

    SILVER CONTRIBUTOR
    Posted 08-10-2018 11:02 AM
    Will stick with accounts and hide the fields we don't need. Thanks.

    ------------------------------
    Pete Axtell
    Winton
    ------------------------------



  • 4.  RE: Creating custom entity to replace Account

    TOP CONTRIBUTOR
    Posted 08-22-2018 07:33 AM
    @Pete Axtell
    We renamed the "Account" entity to "Client" and created our form with just the fields we needed, including quite a few custom fields. ​

    ------------------------------
    Karla Keeney
    Chapter Leader, Orlando FL
    Director of Technology
    Resource Consulting Group
    Orlando FL

    [CRM 2016 SP1 on-premises]
    ------------------------------



  • 5.  RE: Creating custom entity to replace Account

    Posted 08-22-2018 08:36 AM
    We had the same situation and not only that, but we also had different teams that needed different fields. We ended up renaming our "Accounts" to "Companies" and have 4 different forms for the record, one for each sales team type (international, domestic, etc.) That really helped clean up what we viewed on the account form to just what each team set needed.

    ------------------------------
    Jessamyn Evans
    Software Trainer
    Neogen Corporation
    Lexington KY
    ------------------------------



  • 6.  RE: Creating custom entity to replace Account

    GOLD CONTRIBUTOR
    Posted 08-23-2018 09:07 AM

    I would not recommend creating a custom entity in place of Account.  There are a number of special features such as marketing lists, campaigns, orders, and cases that are only designed to work only with accounts, contacts and (sometimes) leads.  Moreover, many 3rd party add-ons rely on these entities. 

     

    Instead of replacing the account entity, take the approach that Jessamyn suggested and simply customize the Account entity to meet your needs.  If the term "Account" is really an issue, it can be changed in most places by editing the display name in the entity definition and customizing the site map.  You may have to change labels in some forms and views too. 

     

    Because we are a university, we thought about renaming the account entity, but in the end just left the "account" name alone.  It hasn't been a problem for our users once they understand that "Account" = "Organization".

     






  • 7.  RE: Creating custom entity to replace Account

    SILVER CONTRIBUTOR
    Posted 08-23-2018 09:16 AM
    @Jessamyn Evans​ - do your users have to toggle betweeen the different forms, depending upon the type of Company they are looking at?  We tried the same approach using different forms for sub-types of companies (Customer, Prospect, Supplier, etc.) but found it too cumbersome for users to have to manually switch between the different forms since there is no way to automate which form is displayed for each sub-type.

    ------------------------------
    Shawn Hickey
    Burns & McDonnell
    Kansas City MO
    ------------------------------



  • 8.  RE: Creating custom entity to replace Account

    Posted 08-31-2018 09:02 AM
    We didn't do it by company (account) type, we used a "Relationship Type" field for that and we utilized quite a bit of custom javascript (I did not write it, so I don't know the specifics). We went by division in our company for the form types for accounts. In that way, the International team only had to set their form to International once, and all the companies they viewed came up with just the fields they needed. We are still on Dynamics 2016 on-prem, if that helps you. We do have quite a bit of customization on the back end so that if a user chooses a particular market segment/category for a customer additional fields show/hide based on that selection. That level of customization has to be applied to each form its needed on though and can get cumbersome from an admin perspective to monitor and manage.

    ------------------------------
    Jessamyn Evans
    Software Trainer
    Neogen Corporation
    Lexington KY
    ------------------------------



  • 9.  RE: Creating custom entity to replace Account

    TOP CONTRIBUTOR
    Posted 08-23-2018 10:13 AM
    @Pete Axtell - it looks like you've already come to the appropriate conclusion.  But to add one quick thought to your planning process: modifying the Account entity (and other entities) to support your business model is exactly what Microsoft had in mind.  Most organizations drop a significant number of the default fields from the Account form when they rollout (and they also add a significant number of new fields of their own).  In fact, when you look at the data model, you'll see that Microsoft itself didn't even include many of the default fields on the default form design.

    So, in the case of an Account, if what you're trying to model is an organization (which could be a company, a membership organization and in some cases even a family) then the Account entity is where you want to start.  This same principle goes for the other entities in Dynamics 365 as well.

    Hope that helps to guide you along your project path!

    @Shawn Hickey - great insight on using multiple forms. The way forms are designed, Microsoft's intention was to associate forms with security roles. You can associate different forms with different security roles and then, when the form is opened, users will see a different form depending upon their role.  Depending on how your sales team works, this may or may not be possible.

    Microsoft really needs to expand this concept with "record typing" so that the correct form can automatically open depending on a record type field.  It is possible to emulate this functionality using JavaScript.  Let me know if you'd like to discuss either of these in more detail.

    ------------------------------
    Geoff Ables
    Managing Partner
    C5 Insight
    Charlotte NC
    ------------------------------



  • 10.  RE: Creating custom entity to replace Account

    SILVER CONTRIBUTOR
    Posted 08-24-2018 11:21 AM
    @Geoff Ables - we need forms to be based on record type, not security roles.  We have different types of Companies (partners, customers, vendors, etc.) that each require different information.  We also have different types of Opportunities (projects, programs, products, etc.) that also require different information.

    It would be great if different forms were associated with different record types since conditionally hiding/showing a lot of fields isn't a feasible option.  Microsofts #1 CRM competitor allows for this.​

    ------------------------------
    Shawn Hickey
    Burns & McDonnell
    Kansas City MO
    ------------------------------



  • 11.  RE: Creating custom entity to replace Account

    SILVER CONTRIBUTOR
    Posted 08-27-2018 04:50 AM
    Hi @Shawn Hickey

    there actually are 2 possible solutions to you problem. ​

    First one:
    You can create a javascript that loads the desired form based on the record information. The problem with this is that the user notices the change :(

    Second solution:
    CRM saves "the last used form" for entity types. Like "User X last used form Y for contacts". You could manipulate this information in a plugin when retrieving. Users wouldn't recognize this like the first solution. On the other hand you may open hells gate because users might want this solution for a lot of other entities and then it might have a performance impact. (Because you will use a Retrieve plugin)

    Have fun!

    ------------------------------
    Code is poetry and customer is king
    ------------------------------



  • 12.  RE: Creating custom entity to replace Account

    Posted 08-27-2018 10:15 AM
    I agree with many of the comments made on this thread.  As a solution architect, it is imperative to look for ways to use the OOB Account entity as it's tied to so much functionality - invoicing, Field Service, Project Service, etc.  There are always ways to accomplish the business requirements at hand.  In some cases, maybe the existing business processes need a second glance to ensure it's the right way to do things.  If you need different form looks / feel based on data or something else, there are many ways (just as @Roy Carlitscheck mentioned several options).  Before hastily making a significant design change to core functionality - I would explore all possibly avenues (code, different forms for different BUs, etc).  ​

    ------------------------------
    Scott LeFante
    Sr. Solution Architect
    Hitachi Solutions
    Tampa, FL
    ------------------------------