There are three factors that drive what a folder dependency rule will do:
- The relationship between the source and target. You set this by selecting the dependency type.
- The contacts to process. You set this by setting the Contact That Are option for the rule. This essentially identifies a condition to check, such as whether a contact is in a particular folder or not.
-
The action to take. There are two actions available for a rule:
- Add a contact to a folder (or all folders with a particular folder type) or assign a contact type to the contact.
- Remove a contact from a folder (or all folders with a particular folder type) or remove a contact type.
You don’t directly select the action that the rule should perform. InterAction determines the rule action based on the dependency type and the condition to check.
When adding and removing contact types, Folder Dependency Analyzer can either follow the submission rules defined for Data Change Management, or override them. For details, see Folder Dependency Rules and Change Management.
Selecting the Dependency Type
There are two main types of folder dependencies you can define:
- A Direct dependency adds or removes contacts from the target folder or contact type based on whether the contact is in the source folder, contact type, or search result. For example, a contact with the Our Personnel contact type must also be in the Personnel Information folder. This is a direct relationship.
- A Company Association dependency adds or removes people from the target folder or contact type based on whether the contacts’ associated companies are in the source folder or contact type. This type of dependency is used to classify people based on their companies.
For example, the following rule is a direct dependency:
Contacts that have the Our Personnel contact type but are not in the Personnel Information folder are added to the Personnel Information folder.
This ensures that all of your organization’s employees can have profile information stored in the Personnel Information folder.
In contrast, the following rule is a company association dependency:
Contacts that don’t have the Client Personnel contact type, but are associated with contacts that have the Client contact type are added to the Client Personnel contact type.
This ensures that all people who work for your organization’s clients are classified as Client Personnel.
Identifying the Contacts to Process and the Action to Take
When determining which contacts need to be added to or removed from a target folder or contact type, InterAction needs to know what condition to check. For example, a rule might check whether a contact has a particular contact type, or is linked into a particular folder. The condition to check identifies which contacts will be processed.
The condition to check then determines the action that will take place for the contacts that meet the condition. For example, note the following rule:
Contacts that have the Our Personnel contact type but are not in the Personnel Information folder are added to the Personnel Information folder.
This rule breaks down as follows:
The condition to check is “Contacts that have the Our Personnel contact type but are not in the Personnel Information folder”
The action that will take place is “added to the Personnel Information folder.”
The following table lists the possible conditions to check and the resulting actions. For simplicity, this table refers to just source and target folders. These rules work the same for contact types and search results. Also note that the examples in the third column always use “Folder A” for the source and “Folder B” for the target.
| Condition to Check | Action | Goal of the Rule |
|---|---|---|
| Options Available for a Direct Dependency | ||
| Contacts that are in the source, but not in the target. | The contacts will be added to the target. | A contact in Folder A should also be in Folder B. |
| Contacts that are in the target, but not in the source. | The contacts will be removed from the target. | A contact that is not in Folder A should not be in Folder B. |
| Contacts that are both in the source and in the target. | The contacts will be removed from the target folder. | The folders are mutually exclusive--a contact in Folder A should not also be in Folder B. |
| Options Available for a Company Association Dependency | ||
| Contacts that are not in the target, but are associated to companies that are in the source. | The contacts will be added to the target. | A person associated to a company in Folder A should be in Folder B. |
| Contacts that are in the target, but are not associated to contacts that are in the source. | The contacts will be removed from the target. | A person that isn't associated to a company in Folder A should not be in Folder B. |
You select the condition to check by selecting an option from the Contacts That Are list box. This list only includes valid options for the dependency type.
Selecting the "Contacts That Are" Option
[A] For a Direct dependency, these options are available. InterAction looks at which contacts have the primary entity (the Alumni contact type) to determine which contacts should be linked into the target (the Personnel Information folder)
[B] For a Company Association dependency, these options are available. InterAction looks at the associated companies to determine which people to link into the target (the Client Personnel contact type).
Practicing Safe Folder Deletes
A folder dependency rule can be configured to delete contacts from folders. This is especially useful with company association dependencies. For example, InterAction comes with the following two rules:
- People associated with companies that have the Client contact type are added to the Client Personnel contact type.
- People who have the Client Personnel contact type, but not are associated to companies that have the Client contact type are removed from the Client Personnel contact type.
The second rule ensures that the Client Personnel contact type is only applied to contacts that really do work for your clients. In this case, removing contacts from the Client Personnel contact type (which actually removes the contacts from the Client Personnel folder) is fairly straightforward.
However, it is possible to create rules that inadvertently delete data you don’t want to lose. For example, suppose you have these three rules:
- Contacts with the Our Personnel contact type should be added to the Personnel Information folder.
- Contacts that don’t have the Our Personnel contact type should be removed from the Personnel Information folder.
- Contacts with the Alumni contact type should be added to the Personnel Information folder.
At first glance, this looks like a good idea. It would ensure that the only contacts in Personnel Information are either current employees or alumni. However, this setup defeats the entire purpose of using shared information folders for profile information! When an employee leaves your organization and becomes an alumni, the following steps will take place:
- You remove the Our Personnel contact type from the person.
- You add the Alumni contact type to the person.
- Folder Dependency Analyzer applies the first rule, deleting the contact from the Personnel Information folder and thus deleting all of the folder-specific information stored in that folder (level, languages spoken, etc.).
- Folder Dependency Analyzer then applies the second rule, and adds the contact back into Personnel Information. However, it is too late – the actual information meant to be shared by Our Personnel and Alumni contact types has been lost.
To prevent this problem, be very careful when using the remove action, especially if the source or target is involved with a different folder dependency rule. In most cases, you should never remove contacts from the information folders – only use rules to remove contact types (like the Client/Client Personnel example earlier).