Similar objects with different data.

Question

I appreciate using CRM 2011 to replace one of our existing LOB applications and the question about custom objects.

We have several objects that share some basic information, but each object will require different related objects depending on its type. Also, the verification rules will vary depending on the type. To top it off, each client can support different subsets of the type.

eg.

Employee organization

• Type of employee: full-time, part-time, contract
• Name, address, date of employment, etc.

Different types of employees, depending on the type selected.

Full time:

• Income
• Manual (related items)
• Pension (related parties)

Partial time:

• Hourly payment
• Number of hours / week

Contract:

• Hourly rate
• Start of contract
• the contract
• Contract Information (Related Parties)
• Presented timetables (related objects)

Questions:

• How can you simulate such things in Dynamics 2011? Is there any support for some form of inheritance?
• I am currently thinking that the process automatically creates related objects depending on the type of "Employee" when the Employee is first created. Is there a better way to implement this?
• How to implement validation for this scenario?

Answer 1

We had a similar problem when several of our facilities needed the same field. We finished creating a separate small program that went through and added the correct field for each entity.

Unfortunately, there is no form inheritance (for example, setting up a main form that extends to it by children). And you also cannot copy forms.

Working with relationship building is pretty straightforward. You can create a post post plugin that, when you create an Employee Entity object, adds a type-based relationship (say, a drop). And if you have a subtype, you can add this quite easily.

Validation will be a whole other ball of wax. Let me say that the contractor has become a full-time employee. You will need to have an update plugin in the change (type) field to check and make sure that the correct relationships are in place and the remaining relationships are completed (or cleared).

The situation you are describing is very useful in CRM 2011, the mold material is not the most elegant, but other material is pretty easy to disassemble.

Answer 2

The best way to do this would not be through inheritance, as this will denormalize the data. The best option, in my opinion, is to simply have a picklist / option set that defines the type of employee. Then add additional fields to support each type. If his full-time employee, then the part-time worker fields are likely to be zero, but that doesn’t matter, since any integration you perform will check the parameter to see where he should look for the data.

The only types of "inheritance" I've seen are

• 2011 the ability to create a global type of parameter set that can be quickly copied for use through entities.
• Data mapping. If you create a child, you have the opportunity to map fields from the parent to the child, just as the fields in the row lead to the account / contact / opportunity.

Answer 3

As Cole pointed out, given your requirements, you introduce unnecessary complexity by breaking fields into separate objects. You better track all these fields on one object and distinguish them by the "Employee Type" list (drop-down list). Then you can dynamically display / hide the corresponding fields in the form using javascript based on the selected employee type, and also, if necessary, set the corresponding fields.

Answer 4

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

First make sure that all of your entities are named to identify them with their respective grouping. This will greatly facilitate tracking what is happening.

new_all_dateofhire new_all_name new_ft_salary new_pt_hourlyrate 

Secondly, I would create a main tab with information about the generic employee and an additional tab for each type of employee and use subgrids to display user relationships. Create JavaScript in OnLoad to show / hide only the correct additional tab (or no tab for a new entry).

On the common tab there is a drop-down selector for "Employee Type". Use the OnChange code to force save / update the form when changing the type of Employee. Using the appropriate plugin, you can clear the relationship.