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
We are currently implementing Dynamics 365 across multiple business units at the University (which is the first time my own unit is sharing information on the Accounts with other business units).
Previously we would maintain the accounts (which, in our case, the organization type for these accounts was always "school"), but now with other business units involved, the same "school" that we use may be labeled "non-profit", "private" etc.
Now the discussion around the table is to have the organization type dedicated to the other units (such as the Executive education division) with the values of profit, non-profit, public, thus giving the other units full use of the this field and removing the "school" type completely. And instead, we add a new field call "account type" that shows values, high school, university, adult education etc. The reasoning, I was told, was that a high school to us is a school, however, to the exec education staff, they see it as a non-profit account where they can recruit and train staff. The downside of this is that we no longer have a field that binds all the "schools" under one category, (the users would just have to know that in order to find all "schools", they have to individually pick "high school, university, etc" out of the "account type" field.)
I'm pushing to have the organization type changed to a multi-select so an account can have more than one Org type (so that it can be a school AND a non-profit). However, I feel that the implementation consultants have fatigued our stakeholders (through rounds and rounds of repetitive requirement gathering meetings) into wanting less customization (although personally I feel that this is a very small one and the customization of new fields is relatively simple).
For current users of the dynamics CRM, is there any experience that you can share on this topic? Am I creating more trouble if I ask for the field to be multi-select? Or am I over-complicating things thinking that all the "schools" should be bound by a category?
We currently have roughly 8000 accounts and want to avoid any duplicates of accounts or efforts (especially now control and maintenance is going to be shared).
Is there a specific reason why it should be a dropdown? In this case I would go for two lookups going to the same custom entity 'account type'. Lookup 1 would be 'Master type' and Lookup 2 would be 'Sub Type'.
In the entity 'account type' I would create a self-referential lookup so you can create a master type 'school' and sub types 'University' and 'High school'.
In the form config I would set the sub type to be filtered on the master type and create a business rule on the form that unlocks the sub type if the master type is filled in.
Alternatively you can lock the master type and only use the sub type field and on an update/create of the sub type run a workflow that fills in the master type in the background.
That way you can still create reports/views on all records with 'master type = schools' or better even 'where sub type has master type = equal to my selection eg: university' (makes sense I hope?)
If for any reason in the futher a school should get an extra parameter as being lets say 'non - profit', you can just add this characteristics to the entity itself and with one simple modification you can use it straightaway in your views/reports etc.
That's my 50 cents on the case. :)
Thank you Wouter! In this case, if a new parameter had to be added, we would be adding by going to the organization type right? So you're suggesting that we use organization type for any type other than "school", and account type would be Master type=school, subtype= high school or university etc. Is that correct? thanks again
Yes, the main problem I see with a multiselect field is that you have no validation in selections. So, a user can select a school as non-profit and profit at the same time.
If you work with lookups you have control over the selections. (And you are even able to implement security on the new entity so user x can only use option a b and c while user y can also use option e and d.)
Just to be clear, in my method 'organisation type' and 'account type' are relations to the same table.
In this table you can add as many master types and as many subtypes as you want.If high school is not existing, you can click on the '+' icon in the lookup (just like adding a new contact on an account) and create a new record 'High school' that is linked to 'School'.
And if you want another parameter you just customize the type entity itself eg:
I hope that's a bit clear what I mean? (Apologies for the handwriting, never been my strong suit :) )
Before you confirm any design changes, you need to consider that you have existing 8K record which you need to update to have the updated design.
I agree with the above suggestion of avoiding multi select for various other reasons/ limitation however if you change the type to lookup then you have to do data update as well for those existing 8K record. Although having a lookup is more useful compared to optionset as explained above.
My suggestions (if possible) to keep the "School" under Organization Type and add the new ones s well. Now add another field "Account Type" or "School Type" and have the other values there "non-profit", "private" etc. In addition to this, have a business rule to show "Account Type" field only when Organization Type "School" is selected.
By doing above, you don't need to change the existing data, you may need to populate Account Type field which you can do it very easily with excel.
To be honest, it is not that big change. I agree we have to design the best sytem with minimal changes but sometimes business requirement and best practices doesn't go along and we have to compromise with the best practices. The key here is to identify and find if there will be any future changes to the particular implementation. If yes, then you should invest time on thinking and considering the best approach but if it is just adding another type in the field then I wouldn't worry much :)
Hope this helps.
Thank you for the suggestion. We are going into dynamics as a brand new client, so the data update before we dump everything into dynamics shouldn't be a big issue via excel. We are trying to future-proof any expansions of the use of Accounts so thinking ahead about the design is very important. Thank you again. :)
Thank you Wouter for bringing up the point about multi-select. I hadn't thought about the possibility of conflicting values (non-profit and profit at the same time). I think this would solve our current problem of have multiple properties associated with a single account. I'll run it by the users and see how they feel about the design. Thanks again!
Business Applications communities