What is it?
A time-based workflow uses a condition based on a date field as the primary trigger for an alert.
When to use it?
Time-based workflows are most often used to reinforce SLAS or remind recipients about an action they should take. These can be triggered proactively BEFORE a specific date value or reactively AFTER a date value has passed. Some common use cases are:
Reminder to Update Close Date (Close Date)
Discovery Call Outcome Update Reminder (Event End Date)
Case Resolution SLAs (Case Creation Date)
Lead Assignment (Lead Creation Date)
Churn Risk (Customer Last Activity Date)
How is it set up?
Additional Information
Time-based workflows are not retroactive. Any record that has already met the time-based condition when the workflow is created will not cause an alert to be triggered.
Ex: If the conditions for a new time-based workflow were that an event ended more than 2 hours ago and the opportunity stage is still discovery, any record that was already more than 2 hours after the event end date would not cause the workflow to fire.
Similarly, the clock for time based workflows starts when the workflow is saved.
Ex: The alert for an opportunity which was last modified on June 12th and a time based workflow with a condition of the last modified date on an opportunity was more than 14 days ago, created on June 15th would fire on June 29th (14 days after the workflow was created).
Consider the message frequency carefully for time-based workflows. If not delivered instantly, it is possible that when delivered the alert could be stale due to the way SFDC manages time based workflow messages.
Ex: An alert for a time-based workflow with a weekly delivery frequency which is intended to flag all active opportunities when their close date is 2 days in the past will be queued up when the conditions for the workflow become true. If the opportunities are updated before the message is scheduled to send, the information in the alert could be out of date.
SEE ALSO:
Create/ Update Alerts