About Data Policies
From LongJump Support Wiki
Revision as of 21:05, 9 June 2011 by imported>Aeric (→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
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.
- 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
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: