Similar entities with different data

I'm evaluating the use of CRM 2011 to replace one of our existing LOB apps and have a question regarding custom entities.

We have multiple entities which share some base information, but each entity would require different related entities depending on its 'type'. Also validation rules would change depending on the 'type'. To top it off each client can support different subsets of 'type'.

E.g.

Employee Entity

• Employee Type : Full-time, Part-time, Contract
• Name, Address, Date of Hire etc.

Different types of employees depending on which 'type' is selected.

Full Time:

• Salary
• Benefit (related entities)
• Pension (related entities)

Part Time:

• Hourly rate
• Number of hours / week

Contract:

• Hourly Rate
• Contract Start
• Contract End
• Contract Information (related entities)
• Submitted Timesheets (related entities)

Questions:

1. How does one model this sort of thing in Dynamics 2011? Is there support for some form of inheritance?
2. Currently I'm thinking of having a process automatically create the related entities depending on "Employee Type" 开发者_StackOverflowwhen an Employee is first created. Is there a better way to implement this?
3. How would one implement validation for this scenario?

We had a similar issue where a couple of our entities needed the same field. We ended up creating a separate little program that went along and added the correct field to each entity.

There isn't any form inheritance (like setting up a master form which propagates to it's children) unfortunately. And you can't copy forms either.

Dealing with creating the relationships is pretty easy though. You could create a post event plugin that when an Employee Entity is created, it adds a relationship based on the type (lets say a drop down). And if you have a subtype you could add that in pretty easily also.

Validation would be a whole other ball of wax. Let's say a contractor turned into a full-time employee. You'd need to have an update plugin, on field changed (type) to check and make sure the correct relationships in place, and the other relationships are ended (or cleaned up).

The situation you're describing is very doable in CRM 2011, the form stuff isn't the most elegant, but the other stuff is pretty easy dealt with.

The best way to do this would not be through inheritance since that would denormalize the data. The best option in my opinion would be to simply have a picklist/option set that specifies the employee type. Then have the additional fields to support each type. If its a full time employee then the part time employee fields will likely be null but that doesn't matter since any integration you are doing will check the option set to see where it should expect to find data.

The only types of "inheritance" i have seen are

• 2011's ability to create a global type of option set that can be quickly copied to be used across entities.
• Data mapping - If you create a child entity you have the ability to map fields from the parent to the child, much like the fields on a lead will carry on to an account/contact/opportunity.

As Cole mentioned, given your requirements, you're introducing unnecessary complexity by breaking out the fields into separate entities. You're better off tracking all of those fields on a single entity and distinguishing by an "Employee Type" picklist (dropdown). You can then dynamically show/hide the relevant fields on the form with javascript based upon the selected employee type as well as setting the corresponding fields as required.

I would suggest a couple things to help keep this "neat".

First, make sure all your entities are named to identify them with their appropriate grouping. This will make it much easier to keep track of what goes where.

new_all_dateofhire
new_all_name
new_ft_salary
new_pt_hourlyrate

Second, I would create a main tab with the generic employee information and an additional tab for each employee type and use subgrids to show the custom relationships. Create OnLoad JavaScript to show/hide only the correct additional tab (or no tab for a new record).

On the generic tab have a drop-down selector for the "Employee Type". Use OnChange code to force a form save/refresh when the Employee Type changes. With the appropriate plug-in then you'll be able to clean up the relationships.