Managing Rules When Several Rule Sets Control a Contact

Each contact can be managed by several rule sets at a time. For example, assume Jane Tarnoff is a client that you have brought into InterAction from your accounting system. In this situation, Jane has an external system rule set and a contact type rule set (Clients) applied to manage changes made to her contact information.

When a contact is subject to several rule sets, a ranking system determines which rule set takes precedence. This essentially determines which data steward is responsible for handling the change the user made to the contact information.

When a user makes a change to a contact, the following hierarchy decides which rule set takes precedence:

  1. External system rule set

  2. Contact type or marketing rule sets

  3. User rule set

  4. Default rule set

Because you cannot bring the same contact information in from multiple external systems through Application Collaboration, each contact can have no more than one external system rule set applied. Similarly, one user rule set can be applied to the change because the change is made by one user. A contact can, however, have several contact type or marketing list rule sets. To manage the hierarchy, you can set a priority for contact types and marketing lists. For more information, see Setting the Priority for Contact Types and Marketing Lists.

It is not only the hierarchy of the rule sets that determine which data steward processes a change, but also the restrictions of the rule defined in each rule set, which determines the data steward responsible for managing a change. For example, Ed Roberts adds an address for Jane Tarnoff, and Jane’s contact, as described before, is monitored by two rule sets:

  • An external system rule set for information brought in from the accounting system - this rule set specifies that when a user adds an address to a contact, the address should be applied, however the data steward should have the opportunity to review the change.
  • A client contact type rule set - this rule set specifies that when a user adds an address to a contact, the new address must be submitted to the data steward for approval before it can be applied.

Although the external system rule set takes precedence over the contact type rule set, since the contact type rule set is more restrictive, the ticket is assigned to the data steward responsible for the Client contact type instead of the data steward responsible for the external system.

Setting the Priority for Contact Types and Marketing Lists

Each contact type and marketing list is assigned a unique priority that is used to determine its precedence when processing a change a user makes to the information for a contact. Contact types and marketing lists must have unique priority values. For information on editing contact types, see Managing Contact Types and Marketing Lists.

Priority values are in ascending order, meaning a contact type with a priority value of 1 takes precedence over a contact type with a priority of 10. For example, Client Personnel has a priority of 90 while Alumni has a priority of 70. If Jane Tarnoff has both the Client Personnel and Alumni contact types and a user deletes her home address, the owner of the Alumni contact type is responsible for managing the change and will receive the ticket.

Notifying Other Data Stewards Responsible for a Contact When a Change is Made

Although a ticket can only be assigned to one data steward, you can still notify the other data stewards that are responsible for maintaining information for that contact when a change has been made. For example, you receive a ticket for an address change that you must accept before the change will be applied and you accept the change. Any owners of other rule sets that also specified that address changes must be submitted to a data steward for approval can be notified that you made the address change.

Notification tickets are sent with a status of Notify.

Notify Ticket in the Inbox

The following rules describe when notifications are sent if the rule specifies that a notification should be sent:

  • If both rule sets have the same rule defined (either review or submit), then a notification is sent to the owner of the lower-priority rule set when the owner of the higher ranking rule set completes the ticket.
  • If the lower-priority rule set has a more restrictive rule than the higher ranking rule set, then a notification is sent to the owner of the higher priority rule set when the owner of the lower priority rule set completes the ticket.

These rules allow the owner of a rule set to always be notified of changes to contact information even though the rule set for which they are an owner may not be the rule set that is governing the change.

Depending on the rule used to create the ticket (Submit or Review), the notification will be sent at a different time:

  • If the ticket has the status of Submit, then the notifications are not sent until the owner to which the ticket was assigned has Accepted and closed the ticket.
  • If the ticket has the status of Review, then the notifications are sent immediately.

Which Rule Sets Send Notify Tickets by Default?

InterAction includes 5 out-of-the-box rule sets: Unmanaged, Partially Managed, Managed, Highly Managed, and Externally Owned. Each of these rule sets use different rule collections that govern which actions generate Data Change Management review tickets.

  • Unmanaged and Partially Managed - Notify tickets are not sent
  • Managed and Highly Managed - Notify tickets are sent for specific actions, such as deleting or changing the company name, job title, or phone number for a contact.
  • Externally Owned - Notify tickets are sent for all actions

For more information on the InterAction out-of-the-box settings for rule collections, see Out-of-the-Box Data Change Management Settings.

The Default Rule Set

When no rule sets, contact types, or marketing lists govern a change made to a contact, the default rule set decides whether or not the change requires intervention from the data steward.

The default rule set is used most often in cases where a user enters a change request for a contact, but the contact is not governed by any rule sets, contact types, or marketing lists that would handle the user’s change request. When this occurs, the user or group who is the owner of the default rule set is assigned the user’s change request.

The default rule set is provided with InterAction and cannot be deleted or inactivated. By default, the Data Administrators group is responsible for managing any tickets assigned because of this rule set.

The default rule set uses the unmanaged rule collection. You should avoid changing this because adding rules to the default rule set that restrict user’s ability to change contact information can produce a number of tickets that data stewards must handle for contacts that are probably not as high of a priority to your organization. This rule set automatically accepts all adds, edits, or deletes a user makes to any contact information.