For example, when a lead is created in the system, you can implement an action on the event 'Lead created' to send an email to the person responsible for the customer the lead was created for.
Once the event is raised, the implemented schedule conditions will be evaluated. The system will check if the subject (in this case the lead) complies to the set of conditions. If this is the case, the action will be planned. If not, obviously nothing happens.
After scheduling the action (depending on the action setting 'process time'), the start conditions will be evaluated. This set of conditions determines if the action is allowed to be executed now, or if the system should wait for a different state (i.e. the object changing to another status, or, more likely, a certain moment in time).
Previous articles on actions can be found here.
Let's take a look at a more complicated requirement. Let's say we would like the following action to take place.
Send an email to the responsible employee 10 days before a lead's end date, but only if the lead has status open and is qualified as 'checked'.
This would require us to do the following:
- Create the [enddate - 10] date in the date profile.
- Create the action to send the email
- Create a schedule condition to determine whether the lead meets the requirements for sending the email at all (for instance qualification = 'checked' and status = 'open').
- Create a start condition to determine whether the action should be sent yet.
The action to send the mail would have processing time 'Processing using a selection report'. This particular processing time is used when creating actions that need to be started at a later time (such as the example at hand).
As the schedule conditions are evaluated every time the object is saved, the start conditions will automatically prevent the action from being processed if the status does not comply.
SPPFPIn order for actions to be processed, batch program called 'SPPFP' has to be scheduled.
SPPFP will select all scheduled actions (based on the selection criteria entered) and per action evaluate the start conditions. If the start condition is evaluated as OK, the action will be executed, in our case sending the email.
PerformanceYou can imagine that if you use a lot of postponed actions, the SPPFP job might take a long time to evaluate all the actions periodically (usually daily). Depending also on the complexity of the evaluation, the performance of the system as a whole, etc, this can become problematic. There are a few things you can do to prevent this:
- Use schedule conditions rather than start conditions where possible.
- Try to prevent OR operators.
- Use object attributes rather than methods
- Prevent using linked objects
- Use optimization rules.
When optimization rules are switched on for an action, during the evaluation, a new evaluation date will be determined.
In our example, we could set the [enddate - 10] date as the optimization rule. During the evaluation, the SPPFP would then conclude that there is no need to evaluate the schedule conditions for this particular action until this date has passed. This will relieve the SPPFP processing.
During the evaluation, the date from the optimization rule will be entered in the action record (PPFTTRIGG-RELEVANT). Next time the SPPFP is run, only actions with a date lower than the optimization rule date will be selected.
There are a few settings that need to have been done:
- Set the optimization rule in the action. Note that you should always select the date that is used in the condition as current date > [date in the optimization rule] or current date >= [date in the optimization rule].
- Switch the optimization rules indicator on in SPPFP, and make sure the Relevant Until field is calculated or explicitly empty in the variant.
- Schedule the variant.
How not to use optimization rules
There are a few traps around when using optimization rules.
Pick the date to optimize on well. If you choose the wrong date, your action might be evaluated too late, and the action might never run, and could be evaluated indefinitely. So always choose a date that is evaluated as being lower or equal the current date.
Make sure that your SPPFP variant has the optimization indicator on, and that the Relevant Until Day and Relevant Until Time are not contained in the variant.
Make sure that there is not another variant of SPPFP scheduled that ignores the optimization rules, and processes the action anyway.
Be aware that the date is stored in PPFTTRIGG, so updating the action customizing will not update the already planned actions.