Return to Navigation

Defining Workflow Actions for Business Projects

This section provides an overview on roles used for business project notifications and discusses how to define workflow actions for business projects.

Note: Workflow notification is one of the actions that you can trigger using AAF. For the workflow actions that AAF handles, the configuration is consolidated within the framework (administrators no longer access the Workflow Action component to configure workflow actions for AAF). The workflow setup discussed in this section is primarily used for business project workflow actions. For information on how to define AAF workflow actions, refer to the AAF documentation. To define workflow actions, use the Actions component.

Page Name

Definition Name

Usage

Rule Page

RB_WF_RULE

Define general information about the workflow action.

Process Page

RB_WF_RULE_PRCS

Select processes to run when the specified workflow action is triggered.

Notifications Page

RB_WF_RULE_RTES

Specify notifications for the workflow action.

Binds Required

RB_WF_RULE_BIND

Specify the value of any variables in the role query.

This table summarizes the valid combinations of events and query role results:

Role Configuration

Notification Channel

Event to Select

Static role (includes list of user IDs).

Worklist

Task Worklist Event or Business Project Worklist Evnt.

Role query that returns user IDs.

Worklist

Task Worklist Event or Business Project Worklist Evnt.

Role query that returns person IDs or email addresses.

Email

Email Event.

Note: The query role and the PeopleTools workflow event must be configured for the same type of notification.

When writing role queries for business projects, keep in mind the data that can be bound into the query:

  • If a business project-specific event triggers the notification, you can bind in any value from the RC_BP_STATUS record.

  • If a phase-specific event triggers the notification, you can bind in any value from the RC_ACTIV_STATUS record.

  • If a task-specific event triggers the notification, you can bind in any value from the RC_TASK_STATUS record.

Even though these records contain many fields, logically, only the key fields provide useful bind values. For example, you can use the business project instance ID to join any of these records to the RC_CASE record and return a user ID, person ID, or an email address for anyone associated with a case. This strategy enables you to send notifications to the agent who opened the case, the provider group or agent assigned to the case, the caller who reported the case, or any other person associated with the case.

Use the Rule page (RB_WF_RULE) to define general information about the workflow action.

Navigation

select Set Up CRM, then select Common Definitions, then select Workflow, then select Actions, then select Rule

Image: Rule page

This example illustrates the fields and controls on the Rule page.

Rule page

Field or Control

Definition
Active Flag

Select this check box to enable the workflow action.

Message Set Number and Message Number

Select a message set and a message to be used as the text for any email notifications that are sent. Messages are stored in the message catalog and organized by message set number. Each message set consists of a category of messages identified by individual message numbers.

This field is relevant only for RMA workflow actions. Otherwise, the system derives the email notification text from a workflow email template, and it does not use these fields.

Component Interface Name

Select the component interface that triggers the PeopleTools workflow event. The component interface must contain a method called Run Action Routes, which reevaluates the triggering event before a delayed or repeat invocation of the workflow action.

This field is relevant only for RMA workflow.

Run Control Record

The default run control record used to run the processes is RB_RUN_CNTL_WF. This is a generic run control record with no parameters. If the processes associated with this workflow action require a different run control record, enter that run control record here.

This field is relevant only for workflow actions that run processes.

Use the Process page (RB_WF_RULE_PRCS) to select processes to run when the specified workflow action is triggered.

Navigation

select Set Up CRM, then select Common Definitions, then select Workflow, then select Actions, then select Processes

Image: Process page

This example illustrates the fields and controls on the Process page.

Process page

If multiple processes are listed, enter a schedule number to specify the order in which the processes run. Delay minutes and repeat minutes do not apply if the workflow process is invoked from business projects; the process takes place immediately.

See Action Processes Page.

Use the Notifications page (RB_WF_RULE_RTES) to specify notifications for the workflow action.

Navigation

select Set Up CRM, then select Common Definitions, then select Workflow, then select Actions, then select Notifications

Image: Notifications page

This example illustrates the fields and controls on the Notifications page.

Notifications page

Field or Control

Definition
Schedule Number

If multiple notifications are listed, enter a number to define the order in which the system sends the notifications.

Role Binds

If the role is a query role (rather than a static user list), click this button to display the Binds Required page, where you enter the bind values for the query used in the query role.

Business Process Name

Enter RC_BUS_PROJECT.

Activity Name

Enter RC_BUS_PROJECT_ROUTING.

Event Name

Values are:

  • Email Event for notifications sent to the recipient's email address.

  • Task Worklist Event for notifications sent to the task status worklist.

  • Business Project Worklist Evnt for notifications sent to the business project status worklist.

Delay Mins (delay minutes) and Repeat Times

Delay minutes and repeat minutes do not apply if the workflow notification is invoked from business projects; the notification takes place immediately.

To delay a notification, use the Workflow Configuration page in AAF to enter the number of delay minutes and repeat times that the system will send out a notification after a triggering event occurs.

For example, you could set up the system to send out a notification when a technician has not responded to a service call after 30 minutes have passed from the time the customer called in a problem.

Note: Delay minutes and repeat minutes do not apply if the workflow notification is invoked from business projects; the notification takes place immediately.