Bookshelf Home | Contents | Index | PDF |
Siebel Business Process Framework: Workflow Guide > Defining Custom Workflow Policies > Process of Defining a Workflow Policy > Defining a Workflow Policy ActionThis task is a step in Process of Defining a Workflow Policy. You must define the workflow policy action before you define the workflow policy that uses the action. To define a workflow policy action
Restrictions with Defining a Workflow Policy ActionThis topic describes restrictions with defining a workflow policy action. Calling a DLL or External FunctionYou cannot call a DLL or external function through a workflow policy action. You can use a workflow process to call a DLL or external function. You cannot call a business service from a workflow policy action. Using an Insert Operation with a Workflow Policy ActionStarting with Siebel version 7.x, an insert operation in a workflow policy action cannot update the Primary Owner. For example, you cannot modify a Workflow Policy Program, such as Create SR Activity, to update Primary Activity Owner (OWNER_PER_ID) because Siebel CRM must also update the S_ACT_EMP intersection table. One Workflow Policy Program cannot update two tables in one database operation. To update OWNER_PER_ID, you must use a workflow process. Earlier versions, such as Siebel CRM version 6, can use an insert operation in a workflow policy action to update the Primary Owner because Siebel CRM can assign an Activity to only one employee in the earlier version. Using the Arguments ListThe Arguments list is context sensitive. Siebel CRM displays a different applet depending on the Program you choose in the Actions list. For example:
If you use the Arguments form, then note the following:
For a description of each workflow policy program type, workflow policy program arguments, and valid values, see Types of Predefined Workflow Policy Programs. How Siebel CRM Refreshes the Applets You UseThe applets that Siebel CRM displays in the Workflow Policies view change automatically depending on the program type you choose for the workflow policy action. This behavior is different from most views that you use in the Siebel client. For example, if you navigate to the Administration-Business Process screen, and then the Policies view, then Siebel CRM displays the following applets: If you choose Send Page to Opportunity Sales Rep in the Action field of the Actions list, then it replaces the Arguments list with the Send Page Arguments form. Using the Recipients ListYou use the Recipients list only if you choose Send Email, Send Page, or Send Message Broadcast in the Program field of the Actions list. Using the Send to Relative Recipient TypeThe Send to Relative recipient type sends an email or page to an individual or to the user who is assigned to the position that is associated with the current record, such as Primary Sales Rep or Primary Sales Rep Manager. The choices that are available are context sensitive. They depend on the Workflow Object you choose in the Actions list. If you define a custom Send to recipient, then you can use one of the following recipient types in the Type field of the Recipients list: Email Manager does not send an email to the same recipient twice for the same action. If it detects that it already sent an email to a specific email address, then it does not send another message. If the Send to Relative type returns more than one recipient, then it sends an email to each recipient only if each email address is unique. Sending an Email to Multiple Relative RecipientsYou can define a workflow policy that sends the same email to multiple recipients. To send an email to multiple relative recipients
|
Siebel Business Process Framework: Workflow Guide | Copyright © 2016, Oracle and/or its affiliates. All rights reserved. Legal Notices. | |