About Data Policies

About Data Policies

A data policy lets you make things happen automatically in a variety of circumstances. Data policies have a variety of attributes that determine how and when they execute, how many things they do, and what kinds of things they do:

Activation Trigger

The thing that initiates the data policy. Two types of activation trigger are available: Action-Based (somebody did something) and Calendar-Based (an alarm went off).

Triggering Criteria

When a data policy is activated, the triggering criteria is checked to see if the policy should "fire" (execute). By default, a policy always executes. But by specifying different criteria, you can cause the policy to execute only under certain conditions--for example, based on data in the record, who the current user is, or what role they play.

Data Policy Actions

The things the data policy does when it executes. Multiple data policy actions can be defined for any given data policy.

Action Based Data Policies

Tip: When you hear "action-based", think "event-based". This kind of data policy is initiated by a "triggering event". That event can be an Action-button in the GUI, or it can be one of several other kinds of events.

An action-based data policy:

• Can be triggered by one or more events.
• Can be conditioned to fire only when certain conditions are met.
• Can be invoked before or after a record is applied to the database.
• Can be invoked before or after batch updates.

Activation Sequence

An action-based data policy can be set to execute either before or after the triggering event. For example:

• Before adding or updating – Validate the incoming data, accept it or reject it by throwing an exception
• After adding or updating – Update Related Objects

Triggering Action

One or more events can be chosen to trigger a data policy.

Note: The Import Batch event occurs before a data import starts, or after it ends. The Import Record triggering event occurs before or after a record is imported.

Examples of Action Based Data Policies

• In a sales department, the local sales representative automatically receives an email notification when a prospective client requests information from the organization's web site. The data policy is triggered by the addition of a new record (prospect), choosing the email recipient based on the territory.
• In a manufacturing operation, the parts department wants to know if the inventory on a popular part is low. The data policy is triggered by an update to the quantity of units in inventory.
• When adding new records, validate the address/phone/email fields before allowing the records to be added to the database
• When importing records (leads file from a tradeshow, for example), verify that the record is not a duplicate of any already existing person/company

Learn more: Build an Action Based Data Policy

Calendar Based Data Policies

Calendar based data policy actions are triggered on a schedule, defined by the following parameters:

• Start Date and Time
• Non Repeating or Repeating (Daily, Weekly, Monthly, Yearly)
• End Date or Never-ending

Tip: A job will start at the time you specify. But the time it takes to complete depends on the system load, so it's a good idea to schedule actions well in advance, to ensure that it completes at the desired time.

Examples

• Drip Campaigns use Calendar-based data policies. These policies detect values and conditions of the data fields and based on them, execute a combination of actions including: sending an email, assigning a task, updating the record content, delivering a Send Outbound message to an external system, or running Java code.
• In a front-desk reservation system, set the criteria to verify that the check-in date must be in the future (after Today) and that the check-out date follows the check-in date
• In a doggy daycare system, check that the pet owner's account has enough pre-paid credits for that week's care

Learn more:

• Build a Calendar Based Data Policy
• Add Actions to a Data Policy