Understanding PeopleSoft CRM Workflow

Processes

If the action is a process such as an Application Engine process, simply reference the process and, if necessary, provide a run control ID. (The run control ID is necessary only if the process has input parameters.) You can include multiple processes in a workflow action, but only one run control ID.

Notifications

If the action is a notification, you can configure the notification to be sent to a worklist or to an email address. The content of a worklist notification is limited, consisting mainly of a link to the related transaction. Email notifications can include message text in addition to a link. When you set up an email notification, select a correspondence email template to provide the notification text.

Like email, workflow notifications can have a priority of low, medium, or high. This enables administrators to set a priority to each workflow action. When that action is triggered at run-time, the worklist notification is sent with the predefined priority and appears in the CRM worklist with that priority. The priorities are the same (high, medium, and low) as those that are used for worklist notifications throughout CRM.

You can send notifications to individuals, provider groups, or sales teams. Provider group definitions have a setting that controls whether the notification goes to a group address (either a group worklist or a group email address) or whether it is broadcast to each member of the provider group. This setting applies only to automated notifications, not to manual notifications.

When you define a notification, you need to reference three PeopleTools workflow objects: a business process, an activity, and an event. Because PeopleSoft CRM delivers generic objects, you do not have to use PeopleTools to create them. You do, however, need to know which of the delivered objects to select. This information is included in the documentation for defining workflow actions. Normally, one business process and one or two activities exist for each functional area that supports CRM workflow. Two events are always available: one for sending email notifications and one for sending worklist notifications.

To send notifications to multiple people, you can include multiple notifications in the workflow action.

Roles

To control who receives the notification, you select a role: either a static role that references a list of user IDs or a query role with appropriate binds for the variables. For example, to send a notification to a case's assigned agent, you use a query role and bind in the case ID.

PeopleSoft software provides several query roles, but you can also create your own. To do this, you need to understand how to use PeopleSoft Query. You also need to make sure that the query returns the right type of values for the specified delivery method; the query needs to return user IDs if the notification goes to a worklist, and it needs to return either person IDs or email addresses if the notification goes to an email address.

The role that you enter in a workflow action must return the appropriate type of value for the routing method (email or worklist), according to these rules:

• A role that returns a list of user IDs results in worklist notifications.

  This includes all static (user list) roles and all query roles that return user IDs. Both individuals and provider groups have user IDs. To send email notifications to members of a static role, create a query role that finds the person IDs that are associated with the user IDs.

• A query role that returns a list of person IDs results in email notifications.

  The system programmatically derives the primary email address for each person ID that the query returns. People who do not have primary email addresses do not receive the notification. Provider groups do not have person IDs. To use person IDs as the basis for addressing email to provider groups, write the query so that it returns the person IDs of all members of the group.

• A query role that returns a list of email addresses results in email notifications.

  If the query returns data in the format <address>@<service>.<domain>, the system treats the values as email addresses. Both individuals and provider groups have email addresses.

To send notifications using multiple channels, include multiple notifications in the workflow action. The PeopleTools Security documentation discusses these rules in detail. The PeopleSoft Query documentation discusses how to create role queries.

See PeopleTools: Security Administration andPeopleTools: PeopleSoft Query

AAF

AAF is the most common way used to trigger a workflow notification and is adopted by major CRM transactions. The framework provides a flexible environment where functional users build business rules using the simple if-then structure. If the evaluation of the business rules is true, the associated actions (in this case workflow actions) are invoked automatically.

Here's the high-level procedure on how to set up a workflow action to be triggered by AAF:

1. Create a correspondence template (if it is not already available).

2. Create a role query (if it is not already available).

3. If the workflow action is to run an application class or application engine process, create the process.

4. Configure the workflow action as part of the policy building process. Use the elements that are created in the previous steps.

Refer to the AAF documentation on configuring workflow actions if you plan to enable workflow actions through AAF.

See Workflow Configuration Page.

Business Project Workflow

Business projects are structured, workflow-enabled task lists that coordinate and track work involving multiple people or processes. The term workflow-enabled refers to task lists that can trigger workflow actions at specific points during the business project. Business projects always run in the context of a parent object such as a case, an order, or a service order.

The following table describes how you trigger workflow actions in business projects:

RMA Workflow

The RMA component in PeopleSoft Support contains PeopleCode that triggers specific predefined workflow actions delivered with PeopleSoft software. To activate the workflow, you assign users to the roles referenced in the delivered actions. You can modify the PeopleCode to reference different workflow actions. The following table describes RMA workflow actions:

Interactions

When the system sends a notification using AAF or business project workflow, the system logs the notification as an interaction, which you can then view on the 360-Degree View page or other interaction lists.