Administering Oracle CRM On Demand > Business Process Management > Workflow Configuration > About Workflow Rules
About Workflow Rules
A workflow rule is an instruction to Oracle CRM On Demand to perform one or more actions automatically each time a specified event occurs.
About Setting Up Workflow Rules Functionality
If you are a new customer, then the workflow rules functionality is automatically enabled. However, if you are an existing customer, then Oracle CRM On Demand Customer Care and your company administrator must configure the Oracle CRM On Demand workflow rules functionality, as follows:
- Oracle CRM On Demand Customer Care Setup. When Oracle CRM On Demand Customer Care sets up the workflow rules functionality, the Workflow Configuration link is visible in the Business Process Management section of the Admin Homepage. Also, the Administrator user role has the Manage Data Rules - Manage Workflow Rules privilege enabled. For more information about user roles, see Adding Roles.
NOTE: To create workflow rules for the User record type, you must also have the Manage Data Rules – Manage Workflow Rules for User privilege in your user role. Your administrator can enable this privilege for the Administrator role and for any other role as necessary. For more information about considerations when creating workflow rules for the User record type, see Considerations When Creating Workflow Rules for the User Record Type.
- Enable Workflow option. Workflow rules cannot be executed until the company administrator selects the Enable Workflow check box on the Company Profile page. For information about configuring your company profile, see Setting Up Your Company Profile and Global Defaults.
- Integration events. An integration event is a mechanism for triggering external processes that are based on changes to the records in Oracle CRM On Demand, including create, update, delete, associate, dissociate, restore, and merge operations. You can specify which fields on a record that you want to track. If your company wants to use workflow rules to create integration events, then contact Oracle CRM On Demand Customer Care to request support for Integration Event Administration and to specify the total size of the integration event queues that you require. When the value changes in a tracked field, the change is recorded in the integration event. You can also specify to which integration event queues the integration events are added. For more information about managing integration events, see About Integration Events.
- Books. If your company wants to use workflow rules to update the associations between records and books, contact Oracle CRM On Demand Customer Care to request support for Book Management. For more information about book management, see Book Management.
Trigger Events and Actions on Workflow Rules
A workflow rule is evaluated when the event specified on the rule (the trigger event) occurs. If the conditions on the rule are met (or if there are no conditions on the rule), then the actions specified on the rule are performed. For example, you can create a workflow rule to specify that when an opportunity is created (the workflow rule trigger event), an email is sent to the opportunity owner's manager (the workflow rule action). You can also specify that the email is sent only if the revenue on the opportunity is in excess of a certain amount (the workflow rule condition), and you can specify the content of the email.
You can also configure workflow rules so that actions are performed when a specified period of time has passed, or when a specified date and time is reached. For more information about time-based workflow actions, see About Time-Based Workflow Rules.
Workflow rules can be triggered by one of the following:
- A record is created, updated, restored, merged, or deleted.
NOTE: Starting with Release 20, an update to a record by a workflow action does not trigger new sequences of workflow rules. For example, if an Update Values action on a workflow rule for the account record type updates a field on an account record, then this change to the record does not trigger any workflow rules for the account record type, even if some of those rules have the Before Modified Record Saved trigger or the When Modified Record saved trigger events. If you want Oracle CRM On Demand to perform any additional actions as a result of the change to the record, then those actions must be configured on the same workflow rule as the action that updated the record.
- A record is associated with another record or dissociated from another record.
Association and dissociation workflow rule triggers are supported for associations between certain record types only. For more information, see the Association and Dissociation Trigger Events section of this topic.
NOTE: Workflow rules support cascade-delete operations and deep-delete operations. For example, when an account is deleted, any related address that is an unshared address is also deleted. The deletion of an address in turn triggers any workflow rules for the Address record type that have the Before Record Is Deleted trigger event. For more information about cascade-delete operations and deep-delete operations, see About Deleting and Restoring Records.
Workflow rules are configured for a record as a whole, and not for individual fields. There are several types of trigger events for workflow rules, but each workflow rule has only one trigger event. Depending on the trigger event you select for the rule, you can specify that Oracle CRM On Demand is to perform one or more actions automatically when the workflow rule conditions are met.
NOTE: After a rule is created, you cannot change the record type or trigger event on the rule. However, you can update the workflow condition.
The trigger event for each rule is shown on the Workflow Rules List Page and on the Workflow Rule Detail page. The following table shows the actions that are available for each trigger event.
Trigger Event
|
Available Actions
|
When New Record Saved
|
- Send Email
- Create Task
- Assign a Book
- Create Integration Event
- Wait
- Update Values
|
When Modified Record Saved
|
- Send Email
- Create Task
- Assign a Book
- Create Integration Event
- Wait
- Update Values
|
Before Record Is Deleted
|
- Send Email
- Create Task
- Create Integration Event
|
Before Modified Record Saved
|
|
After Association With Parent
|
- Send Email
- Create Integration Event
- Wait
|
After Dissociation From Parent
|
- Send Email
- Create Integration Event
- Wait
|
When Record Is Restored
|
- Send Email
- Create Integration Event
- Create Task
|
When Records Are Merged
|
- Send Email
- Create Integration Event
- Create Task
|
Some additional workflow actions are available for Oracle CRM On Demand Life Sciences Edition and Oracle CRM On Demand for Partner Relationship Management. For more information, see About Workflow Actions.
NOTE: Processing of blocked products is not supported for sample request items when you use workflows in Oracle CRM On Demand. For more information, see About Sample Request Item Workflows and Blocked Product Rules.
NOTE: For certain record types, workflow rules that are configured with the When Record is Restored trigger event are never triggered because it is currently not possible to restore a record of that type. For example, it is currently not possible to restore an account team record. If support for restoring such record types is added in the future, then any workflow rules that are configured with the When Record is Restored trigger event will be triggered where appropriate.
Restrictions That Apply to Workflow Rules and Rule Actions
The following restrictions apply to workflow rules and rule actions:
NOTE: When a workflow rule is triggered by a record association or dissociation action, the integration event created by the workflow can contain fields from both the child record and the parent record.
Workflow Rules Order
When you create a workflow rule, Oracle CRM On Demand automatically assigns the rule to the next unused order number for the rules that are based on the same record type and the same trigger event. If the trigger event for the workflow rule is After Association With Parent or After Dissociation From Parent, then Oracle CRM On Demand automatically assigns the rule to the next unused order number for rules that are based on the same record type, the same trigger event, and the same parent record type. The order number determines the order in which Oracle CRM On Demand invokes a sequence of workflow rules that are based on the same record type and the same trigger event, and if applicable, on the same parent record type. You can change the order of your rules. For more information about changing the order of workflow rules, see Changing the Order of Workflow Rules.
Exiting a Sequence of Workflow Rules
You can specify that Oracle CRM On Demand is to stop processing a sequence of workflow rules if the condition on a workflow rule is met. When a workflow rule is triggered, the condition on the rule is evaluated. If the condition on the rule is met and the Exit check box on the workflow rule is selected, then the active actions on the current workflow rule are performed, but the subsequent workflow rules that are based on the same record type and the same trigger event, and where applicable, the same parent record type, are not processed.
Association and Dissociation Trigger Events
Association and dissociation trigger events on workflow rules are supported for associations between certain record types only. The following actions are available for association and dissociation trigger events:
- Send Email. This action is available for all association and dissociation trigger events.
- Wait. This action is available for all association and dissociation trigger events.
- Create Integration Event. This action is available for some associations and dissociations only.
The following table lists the associations that support association and dissociation trigger events and indicates which of the associations and dissociations support the Create Integration Event action.
Parent Record Type
|
Record Type
|
Create Integration Event Action Supported
|
Account
|
Address
|
Yes
|
Account
|
Contact
|
Yes
|
Account
|
Custom Object 01
|
No
|
Account
|
Custom Object 02
|
No
|
Account
|
Custom Object 03
|
No
|
Activity
|
Contact
|
No
|
Contact
|
Account
|
Yes
|
Contact
|
Address
|
Yes
|
Contact
|
Custom Object 01
|
No
|
Contact
|
Custom Object 02
|
No
|
Contact
|
Custom Object 03
|
No
|
Contact
|
Opportunity
|
Yes
|
Opportunity
|
Contact
|
Yes
|
Opportunity
|
Custom Object 02
|
No
|
The following table lists the actions that can trigger an association or dissociation workflow rule. It also shows the integration events that are generated by the workflow rule in each case (if an integration event action is configured on the workflow rule).
NOTE: Depending on the data in the records, additional integration events can be generated. For example, if a new contact created on an account is the primary contact for the account, an additional (account update) integration event is generated.
Action
|
Parent Record
|
Child Record
|
Channel
|
Integration Event
|
Create a new account with an unshared address.
|
Account
|
Address
|
User Interface
|
Account: Insert
Address: Insert
Address: Associate
|
Web Services
|
Account: Insert
Address: Insert
Address: Associate
|
Create an unshared address for an existing account.
|
Account
|
Address
|
User Interface
|
Address: Insert
Account: Update
Address: Associate
|
Web Services
|
Address: Insert
Account: Update
Address: Associate
|
Remove an unshared address from an account.
|
Account
|
Address
|
User Interface
|
Address: Delete
Account: Update
|
Web Services
|
Address: Delete
Account: Update
Address: Dissociate
|
Create a new account with a related, existing shared address.
|
Account
|
Address
|
User Interface
|
Account: Insert
|
Web Services
|
Account: Insert
Account Address: Insert
|
Link an existing shared address to an existing account.
|
Account
|
Address
|
User Interface
|
Account Address: Insert
|
Web Services
|
Account Address: Insert
|
Create a new shared address from the Address related information section of an account Detail page.
|
Account
|
Address
|
User Interface
|
Account: Update
Address: Insert
Address: Associate
|
Web Services
|
Not Applicable
|
Remove a shared address from an account.
|
Account
|
Address
|
User Interface
|
Account Address: Delete
Account: Update
|
Web Services
|
Account Address: Delete
|
Create a new contact on an account.
|
Account
|
Contact
|
User Interface
|
Account: Update
Contact : Insert
Contact: Associate
|
Web Services
|
Contact: Insert
Contact: Associate
Account: Update
|
Link an existing contact to an account.
|
Account
|
Contact
|
User Interface
|
Account Contact: Insert
Contact: Update
|
Web Services
|
Contact: Associate
Account: Update
|
Remove a contact from an account.
|
Account
|
Contact
|
User Interface
|
Account Contact: Delete
Contact: Update (primary contact only)
|
Web Services
|
Contact: Dissociate
Account: Update
|
Link an existing account to a contact.
|
Contact
|
Account
|
User Interface
|
Account Contact: Insert
Account: Update
|
Web Services
|
Account Contact: Insert
Contact: Update
|
Remove an account from a contact.
|
Contact
|
Account
|
User Interface
|
Account Contact: Delete
Contact: Update (primary contact only)
|
Web Services
|
Account Contact: Delete
Contact: Update (primary contact only)
|
Create a new contact with an unshared address.
|
Contact
|
Address
|
User Interface
|
Contact: Insert
Address: Insert
Address: Associate
|
Web Services
|
Contact: Insert
Address: Insert
Address: Associate
|
Create an unshared address for an existing contact.
|
Contact
|
Address
|
User Interface
|
Address: Insert
Contact: Update
Address: Associate
|
Web Services
|
Address: Insert
Contact: Update
Address: Associate
|
Remove an unshared address from a contact.
|
Contact
|
Address
|
User Interface
|
Address: Delete
Contact: Update
|
Web Services
|
Address: Delete
Contact: Update
Address: Dissociate
|
Create a new contact with a related existing shared address.
|
Contact
|
Address
|
User Interface
|
Contact: Insert
|
Web Services
|
Contact: Insert
Contact Address: Insert
|
Link an existing shared address to an existing contact.
|
Contact
|
Address
|
User Interface
|
Contact Address: Insert
|
Web Services
|
Contact Address: Insert
|
Create a new shared address from the Address related information section of a contact Detail page.
|
Contact
|
Address
|
User Interface
|
Contact: Update
Address: Insert
Address: Associate
|
Web Services
|
Not Applicable
|
Remove a shared address from a contact.
|
Contact
|
Address
|
User Interface
|
Contact Address: Delete
Contact: Update
|
Web Services
|
Contact Address: Delete
|
Create a new opportunity on a contact.
|
Contact
|
Opportunity
|
User Interface
|
Opportunity: Insert
Opportunity: Associate
|
Web Services
|
Opportunity: Insert
Opportunity: Associate
Contact: Update
|
Remove an opportunity from a contact.
|
Contact
|
Opportunity
|
User Interface
|
Opportunity: Dissociate
|
Web Services
|
Opportunity: Dissociate
|
Create a new contact on an opportunity.
NOTE: This action is not available through the user interface.
|
Opportunity
|
Contact
|
Web Services
|
Contact: Insert
Contact: Associate
|
Link an existing contact to an opportunity.
|
Opportunity
|
Contact
|
User Interface
|
Opportunity: Update
Opportunity Contact Role: Insert
|
Web Services
|
Contact: Associate
Opportunity: Update
|
Remove a contact from an opportunity.
|
Opportunity
|
Contact
|
User Interface
|
Opportunity Contact Role: Delete
Opportunity: Update
|
Web Services
|
Contact: Dissociate
Opportunity: Update
|
Workflow Rule Action Failures
If a workflow rule action fails to complete, then the following happens:
- If an Update Value action fails, then the operation that triggered the rule is blocked and none of the other actions on the workflow rule are performed. An error message is displayed telling the user that the operation has failed.
- If any other type of workflow rule action fails, then the user gets an error message but the operation that triggered the rule is not blocked, and other actions on the rule are performed. Some error messages, such as the message that is returned when a Create Task action fails because the user is not allowed to create a task, are not displayed to the user. Such errors are written to the log file.
NOTE: If a Send Email action is configured on a workflow rule, and if the email is generated successfully, then the workflow action is considered to have completed successfully. However, the email is not sent out until the operation that triggered the workflow rule completes successfully. Administrators can see a list of the outbound emails that are currently waiting to be sent in the email monitor. For more information about the email monitor, see Reviewing Your Company's Pending and Sent Emails.
Record Visibility and Workflow Actions
When a user performs an action that triggers a workflow rule, some of the actions on the workflow rule can fail if the user’s action resulted in the user losing visibility to the record.
For example, you might have a workflow rule that is triggered when a modified account record is saved. If a user who owns an account record reassigns the account to another user, then the workflow rule is triggered when the account record is saved. If the original owner of the record no longer has visibility to the account record through any other means, such as team or book membership, then any workflow action that requires access to the account record fails.
Record Ownership Modes and Workflow Actions
You can configure record types that support custom books in different ownership modes: user mode, mixed mode, or book mode. For more information about records ownership modes, see About Record Ownership Modes. The record ownership mode interacts with workflow rules and actions.
If an Assign a Book workflow action attempts to remove the primary custom book from a record, then the following happens:
- If the record type is configured in book mode, then the workflow action fails.
- If the record type is configured in mixed mode, then Oracle CRM On Demand removes the value in the Book field on the record when the primary custom book is removed from the record.
- If the record type is configured in user mode, then none of the books on the record is a primary custom book, and the record ownership mode does not impact the workflow action.
If a workflow action has a dependency on the value in the Owner field on a record, such as when a Send Email action is configured to send email using the Relative User on Record option, then the following happens:
- If the record type is configured in book mode, then the workflow action fails.
- If the record type is configured in user mode or mixed mode, and the field that identifies the relative user on the record is blank, then the workflow action fails.
For example, if you configure a Send Email action to send email to an account owner and the Account record type is configured in mixed mode, then the workflow action fails if the Owner field on the account record is blank. However, if the Owner field is populated, then the workflow action succeeds.
Latency
Workflow rules are evaluated in sequence and synchronously. Therefore, until all the rules are evaluated, the overall update operation is not completed. Workflow rules add a certain amount of latency to operations (that is, the time between the start of an operation and its completion). For example, each task created by a workflow rule can add as much as 20% latency to a record update operation. Each email created by a workflow rule adds about 5% latency.
Expressions take less time to evaluate. To minimize latency, add mutually exclusive expressions to your workflow conditions. Build your workflow rules incrementally, keeping performance in mind.
Click a topic to see step-by-step procedures to do the following:
|