Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
Scenario; Dynamics 365 Online Version 9:
I needed to build a new CRM solution for a client, the client worked from an Excel spreadsheet in the past thus has a system I needed to replicate, primarily to reduce name change from the way the client has been working in the past (so not Account but Company, not Supplier but Provider and finally Location). At first, I thought a simple name change of fields would do a simple name change, but I found issues with this - the primary key allowed format would allow for a format which was not in the requirement of the client (i.e. 12 Numbers) So I opted for new Entities, there were other factors, I had a lot of additional fields to create, and well I could not find a way to centrally name change all fields, as well as reports, views etc.. So from a time element, primary key and naming I created 3 new entities.
My question is - was this the right approach?
You can not change OOB entity or field name , Try to use OOB entity and create fields if you need new new fields based on your requirement.
I am not sure which entity you need , you can use Account entity for the company , just rename the display name.
For supplier you can create new entity or contacts , just rename the display name.
Please note if you use of OOB entity you will get OOB fuctionality , which MS provides inbuilt, so consider OOB entity as much as possible. If your requirement something different than OOB entity go for new entity.
So, if the requirements match most of the OOTB entity attributes then you don't have to create new entities, simple display name change would do. but if you see that there are a lot of changes that need to be done then it would be better to create new entities instead.
You shouldn't think much about attributes when mapping entities.
Think of the business and understand what the CRM entities are meant for?
for instance, in your case company = account; you can rename the display name to company and create new attributes if needed. But the basic will remain same for e.g. name of account will become company name, phone remains phone, fax remains fax, website remain website and so on.
For providers, you need to think if these providers are companies or are they individuals? if these providers are companies then you might want to create a custom entity. But as Goutam said that while creating custom entities, you miss out on some OOB features. In case of contact if you're not using it you're missing out on adding them to a marketing list feature and then run a campaign for them.
Concluding it, if you know the business purpose of CRM entities and you know your client's business requirements then you can map the two and only if you can't see any benefit in using OOB entity, you create a custom one.
It shouldn't be dependent on that you have to create new fields in OOB entity, you're doing the same amount of work on custom entities as well. So business use case is the key.
Hope it helps!
I recommend use the existing out of box entity but change the name (at least for account, for example, change the account entity name to Company) and use alternative key to reference (do not use the default primary key)
Thanks for this, my first issue was the primary key, 'Account Name' and the Primary Key. The account name, as this company used it was likely to be repeated many times making searching difficult, but there was a 12 digit Numerical reference which was always unique.
Exactly! Alone seemed to be time consuming, as well as easy to miss something
I understand your point; it would be great if there were a universal tool for name changing. However, I realised the lack of OOB benefits, but in this case, I didn't need them.
I have got some great responses. Thank you for your insight. It seems people have divided opinion but follow a general theme. Next time I may approach this differently.
Please close the thread by marking the answer verified.
Business Applications communities