Several relationship types are provided with InterAction. For a complete list, see Relationship Types Included with InterAction.
Use the following guidelines as you identify any other relationships your organization needs to track:
- Do not change the meaning of the dictionaried Relationship types. These types are used for automatic processing. For more information, see System/Dictionaried Types.
- When you define a pair of relationship types, you should make it easy to identify each side of the relationship. For example, use “Parent” and “Subsidiary” instead of having both sides use a generic term like “Related Company.”
- A relationship type can be the converse of itself. For example, the converse of “Acquaintance” is also “Acquaintance.” For more about choosing the wording for the converse, see What if I Can't Find a Converse Relationship Type That is Always Correct?
- Consider the information users will want to use as search criteria. Specific types are easier to search for since they are always entered the same way.
-
Although specific types are easier to search for, a large number of detailed types for every possible relationship may confuse users. Limit the number of relationship types you create.
For example, if your organization often does business with charities and special organizations, you may want to split out the “Member of” relationship type to be more specific. However, an organization that does not often work with charities may not need such detailed relationships for memberships.
For more guidelines about when to create specific and more general types, see How Specific Should the Relationship Types Be?
- When possible, provide a custom description label. This label appears in the user interface and can give the users guidance about the type of information they should enter in the “description” field.
- Get feedback on the list of types you plan to use before completing your deployment.
How Specific Should the Relationship Types Be?
Although you can create a huge set of very detailed relationship types, overdoing the detail is not necessary.
Specific types are most useful when searching. For instance, it is much more reliable to search for all contacts that have a “Board Member” relationship with Wellington Industries rather than all contacts with an “other” relationship with the company and description text indicating board member.
On the other hand, separate types for “husband,” “wife,” “parent,” and “child.” are probably not necessary for most organizations. The default type “Other Relationship” is probably sufficient for these – the users can enter a description of the relationship when creating it. If you want more specificity, then a “Relative” type would probably be enough. Avoid overwhelming users with a large list of types.
In addition, you can customize the description label field to give users guidance on the type of additional information they should enter.
As a general rule, if users are likely to perform searches on the relationship, use a specific type. If the information is more “nice to know” or something users will browse for when viewing a contact (such as family members), use a general type such as “Relative” or “Other.”
System/Dictionaried Types
The following relationship types are used in special InterAction processing.
| ID | Type | Converse |
|---|---|---|
| 78 | Duplicate of | Duplicate of |
| 1 | Former Employee | Former Employer |
| 2 | Former Employer | Former Employee |
| 84 | Knows | Known By |
| 85 | Known By | Knows |
The only attribute of these types that you can edit is the description label. This is because these types are used for special processing:
- The Duplicate relationship is used when duplicate contacts are merged. For more information, see the InterAction for Data Stewards and Marketing Users guide.
- The Former Employee and Former Employer relationship types are used to automatically record the relationship a contact had with a company when that person’s company association changes. For example, if Jane Tarnoff leaves Telenorth and you remove her company association, a relationship is automatically created that indicates that Jane’s former employer is Telenorth and similarly, Telenorth’s former employees include Jane.
- The Knows and Known By relationship types are used for Who Knows Whom™. For more information on this feature, see Who Knows Whom.