Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2022 Release Wave 1 PlanDynamics 365 release plan for the 2022 release wave 1 describes all new features releasing from April 2022 through September 2022.
2022 release wave 1 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | 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