| Print Open PDF Version of Online Help

#### About Time-Based Workflow Rules You can configure certain workflow rules so that actions are performed after a wait period has passed. For example, you can configure a rule so that an action on the rule is performed after the due date of a record has passed, or if a record has not been worked on for some time. There are two ways to configure time-based workflow rules: By configuring scheduled events. A scheduled event is a workflow rule that is not triggered by a user action. Instead, the scheduled event is automatically executed when a specified date and time is reached. You can optionally configure a scheduled event to be executed multiple times, at an interval that you specify on the scheduled event. The workflow actions on a scheduled event are performed on a list of records, whereas the actions on other types of workflow rules are performed on a single record. For more information about scheduled events, see About Scheduled Events and Creating Scheduled Events. By configuring Wait actions on a workflow rule or scheduled event. ### About Wait Actions You can add one or more Wait actions to certain post-event workflow rules, including scheduled events. In each case where you want a time-based action to be performed, you create a Wait action that specifies the period of time for the delay, or the end-date and time of the delay. You can specify periods of time or dates directly, or you can create an expression to calculate the period or date. You then order the actions on the rule so that the Wait action comes immediately before the action that you want to delay. If more than one rule is required to fulfil a business process, you order the rules appropriately to achieve your objective. NOTE: You cannot configure Wait actions on pre-event workflow rules. ### About Re-evaluating Workflow Conditions After Wait Actions When you set up a Wait action on a post-event workflow rule with any trigger event other than Scheduled Event, you can specify if the workflow rule condition is to be reevaluated when the wait period ends. If the Reevaluate Rule Conditions After Wait check box on the Wait action is selected, then after the wait period ends the record is reread and reevaluated against the condition on the workflow rule. If the rule condition is not met (because the record has been changed during the wait period), the remaining actions on the rule are not performed. By default, the Re-evaluate Rule Conditions After Wait check box is selected on Wait actions. If you deselect the Reevaluate Rule Conditions After Wait check box on a Wait action, then after the wait period ends the record is reread and the next action on the rule is performed without checking that the record still meets the rule condition. If you have more than one Wait action on a rule, the Reevaluate Rule Conditions After Wait check box must be selected on each Wait action where you want the rule condition to be reevaluated after the wait period ends. NOTE: You cannot configure a condition on a scheduled event, that is, a workflow rule with the Scheduled Event trigger event. Therefore, selecting or deselecting the Reevaluate Rule Conditions After Wait check box on a Wait action on a scheduled event has no effect on the processing of the rule. ### Example of Using Time-Based Workflow Rules Using Wait Actions The following is an example of how you might configure time-based workflow rules using Wait actions. You might use time-based workflow rules differently, depending on your business model. Three priority options are used for service requests: Standard, Urgent, and Critical. The priority of a service request is set to Standard by default when the service request is created. A business process for service escalation requires the following actions: After a new service request is created, and if the status of the service request is not updated within 24 hours, the priority of the service request is changed to Urgent and an email is sent to the owner of the service request to notify the owner that the service request must be updated. If another 24 hours pass without a change to the status of the service request, the following happens: The Priority field on the service request is changed to Critical The service request is reassigned to the original owner’s manager An email is sent to the original owner of the service request and to the new owner to tell them that the service request has been reassigned to the owner's manager and the Priority has been changed to Critical To meet this requirement, the company administrator sets up a workflow rule for the service request record type, which is configured as follows: The rule trigger is set to the following value: When New Record Saved. The rule condition specifies that the status of the service request is not set to Pending, as follows: [<Status>]<>LookupValue("SR_STATUS", "Pending") The following sequence of actions is on the workflow rule: A Wait action with a duration of 24 hours, with the Re-evaluate Rule Conditions After Wait check box selected An Update Values action to change the Priority field on the service request to Urgent A Send Email action to send email to the owner of the service request to notify the owner that the priority of the service request has changed to Urgent and the service request must be updated A Wait action with a duration of 24 hours, with the Re-evaluate Rule Conditions After Wait check box selected An Update Values action to change the Priority field on the service request to Critical An Update Values action to assign the original owner’s manager as the new owner A Send Email action to send email to the owner of the service request and to the owner's manager to notify them that the service request has been reassigned and the priority of the service request has changed to Critical For information about creating Wait actions and Update Values actions on workflow rules and on scheduled events, see Creating Workflow Actions: Wait and Creating Workflow Actions: Update Values. NOTE: The language-independent field names and the field-name syntax used in any example expressions in this topic are the field names and the field-name syntax that were used in Expression Builder in releases earlier than Release 29 Service Pack 1. These examples are still valid. However, if you select the corresponding fields for an expression from the Fields list in Expression Builder in Release 29 Service Pack 1 or later, then the field names and the field-name syntax will be different from those shown in the examples. It is recommended that you always select the fields for your expressions from the Fields list in Expression Builder, so that the field names and the field-name syntax are always correct. For more information about the field names and the field-name syntax in expressions, see About Expressions. #### Related Topics See the following topics for related workflow information: About Workflow Rules About Workflow Actions Creating Workflow Rules Changing the Order of Workflow Rule Actions Deactivating Workflow Rules and Actions Deleting Workflow Rules and Actions

Published August 2022 | Copyright © 2005, 2022, Oracle and/or its affiliates. Legal Notices.