Personalized Community is here!
Quickly customize your community to find the content you seek.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2021 Release Wave 1Discover the latest updates and new features to Dynamics 365 planned April 2021 through September 2021.
Release overview guides and videos Release Plan | Preview 2021 Release Wave 1 Timeline
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
The amount of columns in our contact table is quickly growing very large. We have several departments using our CRM and there are dozens of columns (and more on the way) that are only used by one department. Putting all these columns into the contact table and forms is taking up a ton of space.
For example, there's one department that pretty exclusively uses a "College" column. It was suggested that we consider creating a "College" table in which we add new colleges as needed and then make a lookup column in the contact form for this table. This would help with our reporting but I don't see how doing this with this column or others would help with having too many columns in the contact table.
Does anyone have a good process or rule of thumb for determining when to make new entities and dealing with large amounts of columns in one table?
From a performance perspective you would want to reduce the number of joins that would occur. Therefore I think the primary point to consider is whether a new table/entity would be used on its own or would it usually be used in context of the contact table. If the department that uses the college table would not typically query for related information in the contact table then it might make sense to separate the tables. However, if this department typically needs to query for data in both the college and contact tables then it might make more sense to not split the tables and keep "college" as a type value within contact.
From a storage perspective the total amount of space used will not differ greatly in either case unless you have duplicate fields.
As for cluttered forms and views you can define separate forms/views to match the needs of the various departments.
Business Applications communities