Kinook Software Forum

Kinook Software Forum (https://www.kinook.com/Forum/index.php)
-   [UR] General Discussion (https://www.kinook.com/Forum/forumdisplay.php?f=23)
-   -   Contact Record - Spouses, Families and Groups (https://www.kinook.com/Forum/showthread.php?t=2364)

ashwken 03-12-2007 05:30 PM

Contact Record - Spouses, Families and Groups
 
Looking for some insight on setting up Contact Records when dealing with Spouces and/or multiple Contacts as a group.

I'll admit up front that I'm coming at this from a Real Estate perspective, but this should also have application to other professions.

How best to deal with a Spouse:

Should each Contact Record represent a single person, then link either spouse as a child?

This seems like a plausible solution, except that you would need to duplicate all of the contact information - which can be accomplished by building one record, then Copy-Duplicate and rename as the other spouse (updates could be a pain).


But then what happens if they divorce, widowed, remarry?

Well, for historical purposes you will need to retian the linked Contact Records because they relate to transactions that have occured - but you may also have new transactions that relate to each individual Contact Record.

If you link to the individual Contact Record for future transactions, any updates to the contact information is reflected in all linked Contact Records - this is a good thing, right?


Should spousal contact information attributes be created, then build a custom form to include two named Contacts (using system default Contact and Address attributes and newly created attributes)?

This approach eliminates the need to keep duplicate Contact Records for each spouse (and duplicate updates) and more accurately reflect a real world situation, but if they divorce you will need to create new individual records - plus retain the original record for historical purposes.


How will these multiple records for the same named person impact searches?

I'm assuming that a search for a particular person will return all Contact Records for the named person, but then how to differeniate between records - show a record creation date or address column in the Search Return window?

For example:

John Smith with spouse (original record)
John Smith - the individual (divorced or widowed, new record)


How to deal with a Contact that represents a group (et al)?

In some cases you will have an individual who has Power of Attorney for a group:

John Smith et al - who represents John Smith, Kathy Smith, and Bobby Smith...

It would seem that that this relationship is best represented as John Smith et al is a parent record, and the individuals represented (by the et al) are individual child records.

These child records are actually linked records from the original source record for each individual.


Conclusion:

I'm having a bit of a hard time wrapping my mind around all of these possibilities, trying to envision the pitfalls of one approach over another, and not having the experience with UR to know what to expect from any given course of action.

Any insights or suggestions would be most welcome.

Later,
KenA

kinook 03-13-2007 12:49 PM

There are multiple ways you could do this. You may want to experiment and see what works best for your needs/requirements.

One approach would be to use separate contact items for each individual, then group them together (via logical linking) under higher level entities (Family, Trust, Group, etc. [you could define templates and/or forms for these types of entities]) as needed, updating the relationships when they change. When selecting a contact, Item Parents would show all the other entities they are related to; searches could be limited by the entity type (Contact, Family, etc.) if needed; you could print an entity and all related contact info by selecting it and its children; if multiple individuals have the same contact information, multi-select to update all individuals at once, etc.


All times are GMT -5. The time now is 10:18 PM.


Copyright © 1999-2023 Kinook Software, Inc.