Return to Navigation

Understanding CRM Action Types

This section provides a method for looking up action types and describes some of the action types that are delivered in PeopleSoft CRM, including:

Action Type Lookup

PeopleSoft CRM delivers 53 action types that you can use when building your policies. They include appropriate configuration pages for capturing data while setting up actions in policies and the code for performing actions at runtime using the captured data.

To look up the PeopleSoft delivered action types:

  1. Select select Enterprise Components, then select Active Analytics Framework, then select Action Framework, then select Register Action Type.

  2. Click the Search button.

  3. Select an action type name.

    The system displays a page that lists the action type name, a description of what it does, action behavior, and action type triggers.

Workflow

Use AAF to trigger workflow actions, which are PeopleSoft CRM objects that can schedule processes and send onetime or repeating notifications. Workflow notifications can be either sent as email or worklist items. The system can process workflow actions immediately or schedule them for later.

You can also use terms to set up run time delay notification actions. You can these notifications on run time data. For example, you can set up multiple delayed notifications for Support, HelpDesk and HR HelpDesk cases, including service level agreements (SLAs), using percent of response and restore minutes. PeopleSoft delivers these terms for Call Center applications.

To create new terms for other applications requires customization, which PeopleSoft does not support. Attachments are also not supported in email that is sent as workflow notifications by AAF.

When AAF triggers notifications or processes that are scheduled in advance, you can associate them with a condition. The action is invoked only if the evaluation of the specified condition is true when the action is scheduled to start.

When AAF sends a notification, the system logs the notification as an interaction, which can be viewed in the 360-degree view or the corresponding interaction list.

In addition to the functionality that's mentioned, some applications perform additional tasks using the post processing feature that is available in the workflow action. Examples are the call center applications and task management.

Call center applications leverage the workflow action's post processing functionality to remove worklist entries. Call center applications use AAF to automatically create worklist entries based on events in the life cycle of a case and remove those entries when they are no longer needed. For example, when a case is assigned, the system sends a worklist entry to the assigned-to agent regarding that case. When the case is closed, that entry is automatically removed from the agent's worklist (the entry is marked as worked). Post processing for workflow action is supported in all the case contexts:

  • Case

  • Create Self-Service HelpDesk Case

For the Solution component, you can configure policies using the Notification & Workflow action to send a notification to a user's worklist or email, when a user changes the solution status on a case or service order. Use the After a Solution is Saved trigger point to build your policies. PeopleSoft does not, however, deliver any policies that use the After a Solution is Saved trigger point with the Notification & Workflow action.

Task management leverages the workflow action's post processing functionality to update the task management tables after sending notifications, which helps to prevent duplicate notifications from being sent to task assignees.

The notification and workflow action of AAF uses correspondence templates to send email notifications. It also sends notifications to user and group worklists. An example is service level agreements, with their contracted response and restore times. You can configure terms in a notification action that automatically warn the agent of pending response and restore milestones when the case's task list indicates inaction. The times for notification can even be determined from data entered when the service order is placed. The order capture application leverages post processing as well.

See Understanding Correspondence Templates.

See Understanding Processing a Case.

See Run Time Delay Page.

See Define Post-Process Page.

In addition to sending notifications, you can set up workflow actions to run the application engine or application class processes. Here is the guideline for writing application class-based processes.

The constructor of the application class needs to be coded to accept an instance of the RB_AAF_AF:PostPrcsData class. The application class must have the ActionPrcs method. This method is automatically invoked by the Notification & Workflow action. The ActionPrcs method is responsible for performing tasks that need to be completed. The PostPrcsData object contains ACTION_ID and CONTEXT_OBJECT. Here is the sample application code of an application class-based process:

import RB_AAF_AF:PostPrcsData;


class RestoreActual
   method ActionPrcs();
   method RestoreActual(&TM_PostPrcsData As RB_AAF_AF:PostPrcsData);
private
   
   instance RB_AAF_AF:PostPrcsData &obj_ppdata;
   
end-class;

/* Constructor */
method RestoreActual
   /+ &TM_PostPrcsData as RB_AAF_AF:PostPrcsData +/
   &obj_ppdata = &TM_PostPrcsData;
end-method;

REM +---------------------------------+;
REM | Update Restore Actual Date/Time |;
REM +---------------------------------+;
method ActionPrcs
   
   Local Record &recCase = CreateRecord(Record.RC_CASE);
   &recCase.CASE_ID.Value = RC_CASE.CASE_ID;
   &recCase.BUSINESS_UNIT.Value = RC_CASE.BUSINESS_UNIT;
   &recCase.SelectByKey();
   
   &recCase.RC_RESTMET_DATE.Value = %Date;
   &recCase.RC_RESTMET_TIME.Value = %Time;
   &recCase.Update();
   
end-method;

Business Project Instantiation

Use AAF to instantiate business projects, which are structured, workflow-enabled task lists. Specify which business project to instantiate when you are configuring the business project action.

In addition to the functionality that is mentioned, some applications perform additional tasks using the post processing feature that is available in the business project action, such as call center applications.

Call center applications leverage the business project action's post processing functionality to record the instantiation of business projects in the Related Action page of cases. Post processing for business project action is supported in all the case contexts: Case, Create Self-Service HelpDesk Case, Create Self-Service Support Case, Manage Self-Service HelpDesk Case, and Manage Self-Service Support Case.

See Managing Related Actions, Define Post-Process Page.

Branch Script Instantiation

Use AAF to recommend a script to launch for conducting customer survey. Specify which script to recommend to end users when you are configuring the branch script action. At runtime, the specified script is displayed as a link in the popup dialog box.

Unlike the business project or workflow action, the branch script action does not support post processing. If you use AAF to recommend branch scripts and end users launch them from transactions such as cases or service orders, the system does not add the branch script instantiation as a related action of the transactions or generate log for the event. Currently, branch scripts are added automatically as related actions of the calling transactions if they are instantiated manually from the transactions.

History Tracking

Use AAF to add data to a component's history table. The history provides a record of significant events that are related to a component. Capturing event history is similar to an audit, but you have additional flexibility when configuring the data changes that the system captures.

PeopleSoft CRM delivers the history tracking that is related action types for these components:

  • Case History

    The case history action type logs information into the Events tab of the Case History page. This is a case-specific action and cannot be used for other applications. The history log indicates the policy for which the log is created. It also shows the original and current term values, which are resolved at runtime, as log details. Users can view case event history items from self service cases; they are marked with the all visibility.

    This action is enabled for these trigger points:

    • After a HelpDesk Case is Saved.

    • After a New Self-Service HelpDesk Case is Saved.

    • After a New Self-Service Support Case is Saved.

    • After a Support Case is Saved.

    • After an Existing Self-Service HelpDesk Case is Saved.

    • After an Existing Self-Service Support Case is Saved.

    • Before a HelpDesk Case is Saved.

    • Before a New Self-Service HelpDesk Case is Saved.

    • Before a New Self-Service Support Case is Saved.

    • Before a Support Case is Saved.

    • Before an existing Self-Service HelpDesk Case is Saved.

    • Before an Existing Self-Service Support Case is Saved.

    • When a HelpDesk Case is Escalated.

    • When a Support Case is Escalated.

    Note: The case history action does not support trigger points of the ComponentPostBuild trigger type. Case history data is part of the Case component. In order to log case history, the case must be saved.

  • Solution History.

    The Solution History action type logs information into the History Page of the Solution component. This is a solution-specific action and cannot be used for other applications. The history log indicates the policy for which the log is created. It also shows the original and current term values, which are resolved at runtime, as log details. This action is enabled for the After a Solution is Saved trigger point.

  • Installed Product History.

    This action uses AAF to add data to the Installed Product History table to capture significant events in the life of an installed product, service, or asset. The log is presented on the History page of the Installed Product component. This is an installed product-specific action and cannot be used for other applications. During action configuration, functional users specify what text gets logged in the history table for each policy, as well as the specific terms that are captured. Values of original terms (before the change), current terms (after the change), or both can be captured during runtime. This action is enabled for these trigger points:

    • Before an Installed Product is Saved.

    • Before Product Registration is Saved.

    • After an Installed Product is Saved.

    • After Product Registration is Saved.

    At runtime, when any of the enabled trigger points occur, the system searches for the policies that are associated with it and runs the corresponding action to log installed product event history.

  • Lead and Opportunity History.

    The Lead and Opportunity History action type logs information into the History Page of the Lead or Opportunity component. This is a sales-specific action and cannot be used for other applications. The history log indicates the policy for which the log is created. It also shows the original and current term values, which are resolved at runtime, as log details. This action is enabled for these trigger points:

    • After a Lead is Saved.

    • After an Opportunity is Saved.

  • Change Request History.

    The Change Request History action type logs information into the History Page of the Change Request component. This is a change request-specific action and cannot be used for other applications. The history log indicates the event for which the log is created. It also shows the original and current term values, which are resolved at runtime, as log details.

    This action is enabled for the After a Change Request is Saved trigger point.

Installed Product Relationship Processing

This action updates the status and reason code of all child installed products to the value of the parent installed product's status and reason code. The parent status is cascaded only to those children whose status is equal to the original parent status.

This action is enabled for the After an Installed Product is Saved trigger point. It does not require additional action configuration.

Case Relationship Processing

Use AAF to cascade status and resolution data from a parent case to its child cases. Only changes to parent cases trigger the action. You typically associate this action with conditions that evaluate the case's status. For example, when you close a global case, you can close all of the global case's child cases and add the global case's successful resolution to all of the child cases.

The child case status is not updated under the following conditions:

  • The child case is related to a service order that is not canceled, completed, or closed.

  • The child case status category is out of sync with the parent case.

    For example, the child case status has a status category that does not match the status category of the parent case status.

Resolution information cascades differently depending on the parent case's status:

  • If the parent case has been closed, the action copies the successful resolution from the parent case to the child cases.

  • If the parent case has been opened, the action changes the child cases' successful resolutions to failed resolutions.

Configuring a case relationship action also specifies the relationship type. Different case relationship workflow rules can be the main difference between two types of relationships.

When the status and resolution cascade to child cases, any status-related workflow for the child cases is triggered, including cascading statuses to the child cases' children.

This action is enabled for these trigger points:

  • After a HelpDesk Case is Saved.

  • After a Support Case is Saved.

Note: This action does not apply to self-service cases.

Entitlement Balance Processing

Use AAF to update the number of support or help desk cases remaining in an agreement that covers a specific number of cases and time. You typically associate this action with the creation or cancellation of a case. For example, you can decrease the entitlement balance each time that the customer reports a new case, and you can increase the number if you cancel a case.

In the configuration for the action, define whether this action applies to prepaid cases, time, or both. When time is added to or subtracted from the prepaid balance, the calculation is performed by the total time entry in the Manage Time component for the case. The agreement that is selected on the case determines whether prepaid balance exists, and if yes, whether it's time-based or case-based. Depending on the remaining prepaid amount, the prepaid balance can be negative. This action is enabled for these trigger points:

  • After a HelpDesk Case is Saved.

  • After a Support Case is Saved.

Note: This action does not apply to self-service cases.

Case Update

The Case Update action updates a case with fields that are available on the quick code. The action can be run either synchronously or asynchronously to update fields on the Case page. Fields that can be updated using this action are:

  • Case information, such as case status, category, specialty type, detail, priority, severity, and impact.

  • Problem summary and description.

  • Suggested action (link category, version and name).

  • Solution search keywords.

  • Notes summary and description.

  • Case type and subtype.

  • Provider group and assigned to.

  • Product group and product ID.

  • Error code and error message.

  • Interested parties (person, name and reason code).

On the Configure Case Update Action page, you can manually enter field values to be updated in the case, or select to use the quick code values for the update. In addition, you can specify options to:

  • Perform case actions (such as Secured Case).

  • Resolve the case.

  • Set the agreement search option.

Business unit is required to choose most of these values. Functional users must set up separate actions for each business unit. When you are setting a field using the Case Update action, the system reacts as if users enter the field value manually. If you define a quick code in the system, then all the fields that the quick code controls are also set for the case. Because many of the fields that the case update action supports are also available in quick code, users should use this action to set a quick code or some other attributes. Unpredictable behavior can result if multiple methods are used to set the same field value.

This action is enabled for these trigger points:

  • Before a HelpDesk Case is Saved.

  • Before a Support Case is Saved.

  • When a Customer is Identified in Case.

  • When a HelpDesk Case is Escalated.

  • When a HelpDesk Case is Presented.

  • When a Product is selected for a HelpDesk Case.

  • When a Product is Selected for a Support Case.

  • When a Support Case is Escalated.

  • When a Support Case is Presented.

  • When an Agreement is selected on a HelpDesk Case.

  • When an Agreement is selected on a Support Case.

  • When an Employee is Identified on a Case.

  • When a Business Unit is Selected for Support Case.

  • When a Case Type is Selected for Support Case.

  • When a Case Type is Selected for HelpDesk Case.

  • When a Business Unit is Selected for HelpDesk Case.

  • When a HelpDesk Case Adhoc Notification is sent.

  • When a Support Case Adhoc Notification is sent.

  • When a Category is Selected for Support Case.

  • When a Category is Selected for HelpDesk Case.

  • When a Product Group is Selected for Support Case.

  • When a Product Group is Selected for HelpDesk Case.

HHD - Create Cases

This action enables automatic creation of cases for personal and job data updates that are made through various transactions in HCM. The action publishes a message using the Create Case EIP. The message contains the information needed to create an HR HelpDesk case for the corresponding HR data update, such as business unit, quick code, case problem description, and employees for whom and by whom the case is created. CRM subscribes to the Create Case EIP message published from HCM to create a case. When the message is processed, the business unit and quick code are used to pre-populate the case with default field values from the quick code definition.

This action is enabled for these trigger points:

  • After the person data is updated.

  • After the job data is updated.

Self Service Case Update

This action updates the agreement search option for self service cases. You can select not to have the system search for agreements for cases automatically, or select to automatically search for agreements with the single longest (or shortest) response time when this action is invoked.

This action is enabled for these trigger points:

  • Before a New Self-Service Support Case is Saved.

  • Before a New Self-Service HelpDesk Case is Saved.

Upsell Indicator on Case

Use AAF to define conditions under which the Upsell button appears on the Case toolbar.

No configuration is required for this action at design time. At runtime, if the case opened has a product that is associated with an upsell script, the system displays the Upsell button on the case toolbar when this action is invoked. When users click the Upsell button, the system launches the branch script that is associated with the product for the case and displays the name of the script in the Related Action Summary for the case.

This action is enabled for these trigger points:

  • After a Support Case is Saved.

  • When a Support Case is Presented.

Case Suggest Action

Use AAF to suggest an action that the agent can perform. Actions that are used for suggestion must be defined on the Link Definition page. The result of this action, which is a suggested action for the agent, appears in the Actions section of the Case page. Suggested actions may not be available in the Related Actions drop-down list box on the Case page. The values that are available in the Related Actions drop-down list box are limited to the actions in the action group for the display template. The actions that are associated with the Suggested Action field on the case do not have this restriction.

This action is enabled for these trigger points:

  • After a HelpDesk Case is Saved.

  • After a Support Case is Saved.

  • Before a HelpDesk Case is Saved.

  • Before a Support Case is Saved.

  • When a HelpDesk Case is Presented.

  • When a Support Case is Presented.

Case Task Action

The Case Task action enables users to automatically create a task for the case based upon user specified conditions. Users can create AAF policies that use the action to create case tasks. The creation of a case task occurs when a case is saved on-line.

This action can be triggered:

  • After a Support Case is Saved.

  • After a HelpDesk Case is Saved.

The task action configuration page contains the Task Group Template field where you can select a Task Group Template. To view the Task Group Template page, go to select Set Up CRM, then select Common Definitions, then select Task Management, then select Task Group Template. The data in the Task Group Template is used to create the task when Case Task Action is triggered.

See Understanding Task Management.

Case Survey Action

The Case Survey action enables users to execute surveys (as dialogs) that are defined in the online marketing application.

This action can be triggered:

  • After a HelpDesk Case is Saved.

  • After an Existing Self-Service Support Case is Saved.

  • After an Existing Self-Service HelpDesk Case is Saved.

  • After a Support Case is Saved.

See Quality Management - Defect Page.

See Understanding Dialogs.

Case Display Template Action

This action type returns a display template that the CRM system then uses to render the Case page.

This action can be triggered:

  • When a HelpDesk Case is Presented.

  • When a Support Case is Presented.

  • When a Business Unit is Selected for a Support Case.

  • When a Business Unit is selected for a HelpDesk Case.

  • When a Case Type is Selected for a Support Case.

  • When a Case Type is selected for a HelpDesk Case.

  • When a Category is Selected for a Support Case.

  • When a Category is selected for a HelpDesk Case.

  • When a Product Group is Selected for a Support Case.

  • When a Product Group is selected for a HelpDesk Case.

  • When a Product is Selected for a Support Case.

  • When a Product is selected for a HelpDesk Case.

  • After a HelpDesk Case is Saved.

  • After a Support Case is Saved.

  • When a New Self-Service Support Case Business Unit is Selected.

  • When a New Self-Service HelpDesk Case Business Unit is Selected.

  • When an Existing Self-Service Support Case is Presented.

  • When an Existing Self-Service HelpDesk Case is Presented.

  • When a New Self-Service Support Case is Presented.

  • When a New Self-Service HelpDesk Case is Presented.

See Understanding Display Templates.

Alert Message or Recommendation Display

Use AAF to display information to end users through the HTML pop-up dialog box. The text that is displayed can be either informational or a recommendation of actions that can be launched by clicking the link. The content can be provided by the these action types:

  • Display alert.

  • Branch script.

Sales Task

The sales task AAF action populates predefined tasks on the Tasks page of leads and opportunities based on the selected task group template.

As delivered for SHARE and IPROD setIDs, this sales task action is invoked by these AAF trigger points when the AAF policy conditions are met:

  • Before a Lead is Saved.

  • Before an Opportunity is Saved.