3 of 3 people found this helpful
You certainly picked the hardest concept I think to explain. Let's start with the contracts.
Identity - FRS_CompositeContract_Identity
this is login information to the system, usernames passwords, password reset information.
Contact - FRS_CompositeContract_Contact
These are person records
Entity - FRS_CompositeContract_Entity
These records are for anything else Organistions, departments etc. Who may wish to log tickets. Entity you will see in a few places. (Possibly a bit vague as I haven't work through everywhere it can be used or used it much myself).
So you have Employee this object is actually an SQL view rather than a table and includes The Contact and Identity contracts. This essentially binds the contacts to an identity and then allows new relationships and fields to be added.
Adding a new employee actually adds a new records to FRS_CompositeContract_Contact and add their login details to FRS_CompositeContract_Identity.
The incident object pulls data from FRS_CompositeContract_Contact but you can directly call other fields from employee using business rules.
it is possible to add new objects for example locations, shops offices etc. Then link contacts to them or allowlogins to those entities.
if you let ok at the accounts object then it allows you to have the concept of a customer account and then you can add external contacts to the account. Have a look if you are interested and you can take it a part to the base FRS_CompositeContract_ objects.
i hope this helps explain it, shout if you need anymore.
Thanks Alasdair, this is helpful. Just today I realized Employee was a view and not really a true BO. So now I am really confused... ;-)
Question: So is the best place to add new custom fields for a person the FRS_CompositeContract_Contact and NOT Employee?
1 of 1 people found this helpful
Yes employee is a view, I always like the question of where to add fields...it depends (sorry).
If you would like every contact (employee, external contact, a.n.other contact derived/created) then add to FRS_CompositeContract_Contact. if it is specific to say your LDAP import then just add to the Employee object. You can access the fields from employee or FRS_CompositeContract_Contact using the same link relationship as they are all on the same object.
If you want to be safe and have all bases covered, like all grouped (or derived) objects add the fields to the base object in this case FRS_CompositeContract_Contact, then they are available to the derived objects.
Thank you! Your explanation is helpful!