Working with Active Analytics Framework

This chapter provides an overview of the Active Analytics Framework (AAF) and discusses:

• The use of active analytics framework in CRM.

• CRM delivered active analytics framework objects.

• CRM action types.

• How to configure actions when building policies.

Understanding Active Analytics Framework

This section discusses:

• Active analytics framework overview.

• Active analytics framework and component event processing.

This chapter discusses AAF from the CRM perspective. For more information on AAF components and how to set it up, refer to the PeopleTools documentation on AAF.

See PeopleSoft Enterprise Components for CRM 8.9 PeopleBook

Active Analytics Framework Overview

Active analytics framework (AAF) is a decision-making system that invoke actions based upon the evaluation of user-defined business rules. AAF provides a user-friendly environment where functional users in the enterprise, without having to understand any of the technical complexities involved behind the scenes, can build business rules using the simple if-then structure in a natural business language (for example, English).

AAF provides components for setting up the analytic framework, which includes managing the data library, building policies, managing trigger points and actions. These components provide a mechanism to define flexible business rules (which are called policies), that can be altered without modifying application code. Business analysts and other functional users define policies using an intuitive user interface.

Functional users can create policies that use data elements of various forms and shapes residing in different sources such as the transactional environment, data warehouses, legacy systems, and so on. The data elements are exposed to the business user as terms, which are defined in the AAF data library.

This diagram illustrates the structure of policies, which get evaluated when their triggering events take place:

AAF policy structure

AAF consists of these major components:

Data Library

Data library is a catalog of metadata about information of various shapes that is stored in different data resources. It consists of data elements called terms, which are pointers to disparate pieces of data residing in a data warehouse, external database or the operational environment such as PeopleSoft CRM. Terms are essentially metadata, which provide source and access information about the physical data. A term is associated with one or multiple implementations, which refer to the mechanism through which the data is retrieved, derived or computed. The implementation is responsible for knowing either where the data is physically residing or the algorithm for deriving the value.

In AAF, functional users can reference terms when they build policies in the policy builder. In addition, the data library is used as a common data repository and extraction framework in various CRM applications and functionality. For example:

• Correspondence management replaces the use of tokens with terms in correspondence templates.

• Real-Time Advisor uses terms as placeholders to form personalized questions and informational texts.

• Strategic Account Planning (SAP) and SmartViews use terms to compute and retrieve goal and metric data.

See PeopleSoft Enterprise Components for CRM 8.9 PeopleBook

Action Framework

The action framework provides an infrastructure for IT personnel to define actions that can be associated with policies in the policy builder, and facilitate the invocation of actions at runtime when the conditions of policies are evaluated to true.

An action type refers to a category of actions that can be associated with a policy, for example, display of alert messages, display of product recommendations, instantiation of business projects, and so on. The action type definition points to a class of similar actions. In some cases, the definition of a category of actions may not contain all the information needed by the decision engine in AAF to fire an action. Therefore, when functional users specify an action when they are creating a policy, they need to provide additional configuration details to ensure the proper invocation of the action. For example, when a user associates a business project action in a policy, they need to identify the actual business project in the configuration page that is developed for that action, which gets instantiated by the system.

In addition to creating and managing actions that are triggered in AAF as a result of a positive evaluation of policy conditions, other CRM applications leverage the framework to define actions that would be used by their own application logic, not through AAF. For example, the automated mail processor in ERMS analyzes inbound emails and performs actions on them based on the email intent and predefined rules. It uses the action framework to define these email-related actions (such as auto-route, auto-acknowledge), which get triggered by application class methods that are referenced in the application.

See PeopleSoft Enterprise Components for CRM 8.9 PeopleBook

See Setting Up Automated Mail Processing.

Policy Builder

The policy builder provides a user-friendly environment for functional users to construct policies in a natural business language. A policy consists of three parts—a trigger point, conditions and actions:

• Trigger points. A trigger point is the occurrence of an event that triggers the evaluation of conditions in policies associated with it. Examples are when a customer is presented in a case and after a change request is saved. This is where functional users want the system to drive actions.

• Conditions. A condition is the if statement, which specifies under what circumstance would some action be performed. Examples are if customer value is high and if the change request status is changed.

• Actions. An action is the then statement, which is invoked if the associated conditions are evaluated to true. Examples are display alert message on screen and log a change request history entry.

While the policy builder is primarily used in AAF to define and maintain polices, other CRM applications leverages the framework for building conditions and getting condition evaluation. For example, profile management allows users to define AAF conditions, which are evaluated at run time to determine whether or not certain profile groups need to be displayed on a CDM (customer data model) component. Real-Time Advisor also takes advantage of AAF condition evaluation in the dialog transition and user segment processing.

The policy builder includes a rich set of tools for functional users to accommodate the creation and modification of policies without assistance from IT personnel. It provides facilities to support an iterative and incremental development process. Policies are validated in the build process before they are deployed.

Please refer to the PeopleTools PeopleBook for a complete discussion on building AAF policies. This documentation also covers other components of the policy builder framework, such as the operator sets, business domains and trigger types.

See PeopleSoft Enterprise Components for CRM 8.9 PeopleBook

See Setting Up Automated Mail Processing.

Active Analytics Framework and Component Event Processing

AAF replaces component event processing, which was the framework that PeopleSoft CRM put in place to automate actions based on the occurrence of events in the previous release. Principle differences between the two architectures include:

• The concept of trigger point.

  Component event processing: Not applicable. In most cases, component event processing is triggered at SavePreChange or SavePostChange. The behavior is hardcoded in PeopleCode and is not configurable.

  AAF: Available to refer to the occurrence of a business event that triggers the evaluation of policies associated with it. IT personnel can specify trigger points for each component based on one of these trigger types: Component PostBuild, FieldChange, SavePostChange and Save PreChange. Refer to the PeopleTools PeopleBook for more information on the implementation of trigger points, which is part of the process that needs to happen to enable components for AAF.

• The concept of event.

  Component event processing: Available to refer logical statements that define the conditions that trigger an action.

  AAF: Events are similar to the if statements of policies, which are the conditions that the decision engine evaluates when it's invoked by a trigger point.

• The concept of event handler.

  Component event processing: Event handlers are available to associate events with actions and capture additional configuration details. Event handlers are action-specific and component-specific. To associate one event with two actions, you need to access each action-specific event handler and add the event to it.

  AAF: Event handlers are similar to the if-then statements of policies, which define the conditions and actions that are invoked if all corresponding conditions are evaluated to true. PeopleSoft CRM delivers action types (replacing event handlers) and they are shared and reusable in the system. When building a policy, users can specify one or multiple action types that are triggered if the policy conditions are evaluated to true.

  Unlike the component event processing architecture where different event handlers need to be defined for action types and components, AAF uses the policy builder to create policies regardless of the component for which they are defined and the type of actions that are invoked subsequently. Another item that is worthy of mention is that in component event processing, the events are built only using data elements present in the component, for which the event is being defined. In AAF, the conditions can be built using terms whose data can come from different sources.

• Use of data elements in conditions.

  Component event processing: When defining events (the conditions) for a component, only the data elements present in the component can be referenced in the events.

  AAF: When building conditions of a policy, the data elements (the terms) that are specified in conditions can come from different data sources.

Use of Active Analytics Framework in CRM

AAF provides a rich set of functionality and they are leveraged fully by a variety of PeopleSoft CRM applications. These AAF features can be broadly classified under four categories:

• Requesting AAF services to evaluate all the policies pertaining to a trigger point, and to invoke the relevant actions of the policies whose conditions are evaluated to true.

• Requesting AAF services to evaluate conditions.

  It consists of the design time interface for embedding condition builder within applications for creating conditions, and the run time interface for requesting the framework to evaluate the condition. Applications perform relevant tasks based on the outcome of the evaluation.

• Requesting the services of the data library engine within AAF to resolve terms.

• The use of the action framework to define actions that are triggered by applications themselves.

These categories are discussed in subsequent sections.

Use of AAF to Evaluate Policies and Invoke Actions

The components present in AAF will be used to build policies. At runtime, applications send requests to the AAF decision engine to evaluate all the policies pertaining to a trigger point. For policies whose conditions are evaluated to true, their associated actions are invoked.

Components that are enabled for this functionality (at least for a single trigger point) include:

• 360 Degree View

• Agreement

• Case

• Change request

• Company

• Create Self-Service HelpDesk Case

• Create Self-Service Support Case

• Defect

• Financial Account Modification

• First Notice of Loss

• Installed Product

• Lead

• Manage Self-Service HelpDesk Case

• Manage Self-Service Support Case

• Marketing Campaign

• Marketing Content

• Marketing Offer

• My Service Order

• Opportunity

• Order Capture

• Partner

• Person

• Product Registration

• Service Order

• Solution

• Task

• Worker

Please refer to the appendix to for more information on list of trigger points that are enabled for these components.

See Delivered Trigger Points.

Use of the AAF Condition Builder

Applications can embed the condition builder to create conditions within the applications themselves. At runtime, applications perform appropriate tasks based upon the outcome of condition evaluation that is returned by the decision engine. The CRM applications and features that make use of this functionality include:

• Profile Management—to create and use AAF conditions to decide if a profile group is to be displayed on a CDM component. This can be set up when assigning a profile group to a CDM component.

• Change Management—to decide whether or not the state transitions are allowed.

• Real-Time Advisor—for page transition and customer segmentation.

• Order Capture—to decide when to instantiate business projects, to perform audits and order maintenance.

• Notification and workflow actions in AAF—to decide whether or not delayed invocations are sent.

Use of AAF Data Library Engine to Resolve Terms

PeopleSoft CRM Applications and features that make use of this functionality are:

• Correspondence management—to include dynamic content in correspondence templates.

• Real-Time Advisor Dialogs—to include dynamic content in questions as well as in instructional notes.

• SAP—to calculate goals.

• SmartViews—to calculate goals and metrics.

• Call Center applications—to resolve links.

  In call center applications, link definitions use AAF terms that are resolved at runtime when a related action is performed from Case page. The relevant term is specified in the Search Keys section on the Link Details page of that component. At runtime, the resolved term values are used either in constructing a URL or in performing the related action.

• Audience Builder—to store term metadata.

  Audience builder uses the AAF data library as a repository to store term metadata; it does not use the data library engine to resolve terms. Audience generation in PeopleSoft Marketing is a set-based SQL process. Audience builder develops these resolution methods to support the set-based SQL processing for audience generation:

  • Audience Select SQL Object

  • Audience Select Record.Field

See Using Audiences.

Integration of Action Framework of AAF

The Automated Mail Processor (AMP) of ERMS uses the action framework to define email-specific actions that it can perform on emails at runtime. AMP matches the category of the email with a category rule that is defined in the system, and triggers the associated actions based on the email's threshold value. AMP delivers these actions: auto-response, auto-acknowledge, auto-route, auto-suggest, create case, spam and unsubscribe.

CRM Delivered Active Analytics Framework Objects

To make AAF readily available to work with operational CRM, PeopleSoft CRM delivers a significant amount of system data that provides all the needed building blocks to support the application-specific business processes. System data includes:

• Contexts

  Contexts are considered foundation objects for AAF. Contexts provide the necessary input data (as specified in context definition) needed for resolving the terms by AAF. These terms, for example, can be present in policies, in correspondence templates, or in advisor dialogs.

  See Delivered Contexts.

• Trigger points

  PeopleSoft CRM delivers about 80 trigger points. The occurrence of a trigger point event invokes the decision engine to evaluate all the policies that are associated with the trigger point and triggers all the relevant actions when the conditions are evaluated to true.

  See Delivered Trigger Points.

• Terms

  PeopleSoft CRM delivers over 1000 terms across the system. They are categorized by subject areas (a folder structure). A term selection page appears to facilitate term lookup, for example, when building a policy or creating a correspondence template.

  See Delivered Terms.

• Action types

  PeopleSoft CRM delivers over 25 action types that you can leverage when creating new policies. They include appropriate configuration pages for capturing data while setting up actions in policies and the code for executing actions at runtime using the captured data.

  See CRM Action Types.

• Policies

  PeopleSoft CRM delivers over 200 policies for over 80 trigger points. To review the list of policies that exist in the system, organize the search view by context and then trigger point, or use the Manage Trigger Point page to view policies by trigger point. Some of the policies are delivered in the In Design status (disabled). Activate them by changing the policy status to Active and making sure that the policy falls in a current time period.

  See Delivered Policies.

Important! If Enterprise Portal is used, access CRM-delivered AAF data by navigating to Enterprise Components CRM, Active Analytics Framework. If Enterprise Portal is not used, CRM data is available under Enterprise Components, Active Analytics Framework.

Contexts

Contexts are a key component of how the AAF works. The purpose of the context is to describe the computing environment from which the decision engine or the data library engine is invoked and to play a role in selecting the appropriate term implementation to be used at runtime for resolving a term. Please refer to the chapter on managing contexts in the PeopleSoft Enterprise Components for CRM 8.9 PeopleBook to get more information on contexts.

PeopleSoft CRM transactions use AAF for different purposes, such as requesting decision engine for evaluating policies, requesting data library engine for resolving terms present in templates which are used for automatic workflow notification, manual notification or correspondence requests, resolving terms and evaluating conditions present in PeopleSoft Real-Time Advisor dialogs, and so on. In some cases, a single context may not be sufficient to provide the necessary content for delivering all the mentioned functionality for a transaction because some of the features, such as resolving terms present in templates found as part of correspondence requests occurs outside of the transaction. Therefore, there may be more than one context present for a component. The appropriate component-specific context that is used depends upon the functionality that needs to be invoked.

Refer to the appendix chapter to view the list of contexts being used for resolving terms or evaluating policies for each component.

See Delivered Contexts.

Note. Features such as policy builder and condition builder ensure that the terms selected for building a condition are resolvable within the trigger point's context. Similarly, terms presented in applications such as SAP, SmartViews, and Real-Time Advisor are also resolvable for that application-specific context. In this release, there is only one feature, that is the term selection for correspondence templates, where all the terms that are present in the data library subject area are displayed to users. Therefore, users need to ensure that a term can in fact be resolved within that context before selecting it. Terms that are created for use in correspondence templates are categorized within subfolders under the Correspondence Template Terms subject area. Each subfolder contains application-specific terms that can be resolved using other components. Refer to managing terms chapter in the PeopleTools PeopleBook for more information on identifying contexts where a term can be resolved.

See PeopleSoft Enterprise Components for CRM 8.9 PeopleBook

Trigger Points

The applications are enabled to detect the occurrence of these trigger points. It is to be noted that certain trigger points which are delivered might not have any policies delivered out-of-the-box. But the trigger points have been enabled to facilitate the customers to create the policies for these events without having to customize the application.

System-delivered trigger points use these semantics to denote when they are invoked in the life cycle of a transaction:

• When a Support Case is Presented.

  This trigger point will be invoked when either an existing transaction is opened or a new transaction is created for Support Case.

• Before a Support Case is Saved.

  This trigger point is invoked when the save action is performed either by the application or by the user. The policies associated to this trigger point are executed before the actual save is complete.

• After a Support Case is Saved.

  This trigger point is invoked when the save action is performed either by the application or by the user. The policies associated to this trigger point are executed after the actual save is complete.

• When a Customer is identified in Support Case.

  This trigger point is invoked after the selection of a customer.

• When a Product is identified in Support Case.

  This trigger point is invoked after the selection of a product.

Important! Though the framework supports the registration of new trigger points, exercise caution before including new trigger points. Please refer to AAF documentation from the PeopleSoft Enterprise Components for CRM 8.9 PeopleBook for more information how to create new trigger points.

Trigger point and setID based processing: For a single trigger point, policies can be created in multiple setIDs. With this approach, the AAF decision engine can invoke different behaviors based on the setID or business unit of the transaction. In this situation, the application that is requesting the AAF decision engine to evaluate the policies should also specify the relevant setID or business unit. This helps AAF to determine the right set of policies to evaluate, based on PeopleSoft setID processing. Applications also have an option not to pass the setID or business unit. In this case, AAF uses the default setID specified in AAF Installation component to determine the policies that need to be evaluated. For transactions, such as the 360 degree view, which does not specify the setID or business unit for which the policies need to be evaluated, they can have setID as part of the policy's condition to drive different behaviors. Please refer to the appendix chapter for a list of system-delivered trigger points and information on what is specified by transactions for processing each of these trigger points.

Note. The applications refer to the trigger point by specifying the trigger code in their applications. It is strongly recommended that customers refrain from making any changes to the trigger code for the trigger points that are delivered with the CRM system. Changes can cause unexpected system behavior.

Terms

PeopleSoft CRM applications deliver a considerable amount of system data pertaining to terms. The terms that are delivered can be broadly classified into following categories:

• Component buffer specific terms

  A vast majority of the terms fall under this category. These terms get resolved using the data available in the current operating component buffer. The implementation is specific to the context and the implementation type is context variable. Typically, these terms are present in the relevant application's subject area. For example, Case component-specific terms will be present under the Call Center.Case Details subject area. Some of these terms may have additional implementations if they need to be resolved from additional contexts.

  Note. These terms which get resolved by accessing data from component buffer (the implementation type is context variable) can be used only in the policies (pertaining to this context), workflow notification specific templates and in the conditions as well as in the questions of Real-Time Advisor Dialogs pertaining to the context. If these terms need to be used outside of the operating context (like correspondence templates), they need to have additional implementations.
  
  Exercise caution when planning to alter the structure of the component using the Application Designer. Change in the component structure can cause invalidation of term definition and the context variable's definition.

• System terms

  These terms are present in different subfolders within the folder called System Terms. These terms provide information about the operating environment. Most of these terms do not need any additional input from the applications. Hence, these terms can be resolved from any context.

  See Delivered Terms.

• Profile terms

  Profile fields that are delivered as system data are also delivered as terms. These profile terms pertain to either an organization or an individual. Organization terms can be found under in the Organizations.Companies subject area; individual terms are present in the Individuals.People subject area.

  AAF uses one input to resolve organization terms: the BO ID of the customer. Any context that has BO_ID_CUST_PROFILE as the alias for the customer's BO ID is able to use organization terms. As for individual terms, they need two input values to resolve: the BO ID of the customer and the BO ID of the contact. The contact's BO ID is always used to resolve terms. When it's not available (contact BO ID is 0), the customer's BO ID is used instead. Any context that has BO_ID_CUST_PROFILE as the alias for the customer's BO ID and BO_ID_CNT_PROFILE as the alias for the contact's BO ID can use individual terms.

  Note. To see a list contexts for which a term can be resolved, click the View Applicable Contexts link in the Generic Implementation group box of the term definition.

  Profile fields, when activated, are automatically created as terms in the data library. This rule, however, doesn't apply to profile fields that belong to many rows profiles. For profile fields that have choose many as their user type, their terms are not supported in the condition builder.

  Profile terms always have a generic implementation. Therefore, any context that has the BO_ID_CUST_PROFILE and BO_ID_CNT_PROFILE aliases can make use of these terms automatically.

  Note. CDM-related profile terms get resolved by retrieving data from BASICS tables, therefore, make sure that the role types are configured for populating the data in these tables (that is, the role types need to be enabled for basic data).

  See Understanding Profiles.

• KPI terms

  PeopleSoft CRM delivers terms to access key performance indicator (KPI) information that is published by PeopleSoft Enterprise Performance Management (EPM). For each of the 19 delivered KPIs, four terms are created for accessing the resolved value, percentage of target, current target and the assessment respectively. These terms are categorized under different subfolders within the Customer ScoreCard KPIs subject area. Any context that has BO_ID_CUSTOMER as an alias can access all of the terms that are related to the customer dimension. Other dimensions include product, campaign and business unit. The rest of the terms expect values such as product ID, campaign ID or business unit to be supplied in the term configuration process. PeopleSoft CRM applications provide the necessary infrastructure to subscribe to the KP_KPI_ASMT_FACTS application message that is published by EPM. The subscription process populates the KPI data for all the message rows in the CRM database, which can be accessed by KPI terms.

  As delivered, the message is inactive. To set up a delivered application message, first activate the application message. Then activate the message subscription PeopleCode (KP_KPI_EPM_TERMS), and set the associated message channel to Run mode.

  Note. The customer value that is displayed on the toolbar of various CRM transactions comes from the customer value KPI related attributes that are present in the PS_BC table. These values are populated by another subscription process using the same application message.

  See Delivered Terms.

CRM Action Types

This section describes the action types that are delivered in PeopleSoft CRM:

• Workflow.

• Business project instantiation.

• Branch script instantiation.

• Show churn reduction scripts.

• History tracking.

• Case relationship processing.

• Entitlement balance processing.

• Case update.

• Upsell indicator on case.

• Case suggest action.

• Alert message or recommendation display.

• Cross sell and up sell opportunity and recommendation.

Workflow

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

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 leverages 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, Create Self-Service HelpDesk Case, Create Self-Service HelpDesk Case, and Create Self-Service HelpDesk Case.

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 template packages to send email notifications.

See Setting Up Correspondence Templates, Processing Cases, Managing Meetings.

In addition to sending notification, you can set up workflow actions to run 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. Examples are the call center applications, account management, and policy and claim presentment.

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.

In account management, policies are defined for the modify account feature to trigger the business project action from the After modify Account is Saved trigger point. Post processing for business project action is used to associate the business project instance with the corresponding account modification transaction.

In policy and claim presentment, policies are defined for the first notice of loss feature to trigger the business project action from the After FNOL is Saved trigger point. Post processing for business project action is used to associate the business project instance with the first notice of loss transaction.

See Understanding FNOL, Understanding Account and Billing Management, Managing Related Actions.

Branch Script Instantiation

Use AAF to recommend a script to launch for conducting customer survey or managing churn customers. 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.

Show Churn Reduction Scripts

This action uses AAF to display churn actions that can be taken for customers who are likely to churn. These actions can be viewed on 360-Degree view of the customer. When configuring the action, specify which scripts to display based on churn scores.

This action is enabled for the After view Churn Action is Selected trigger point. At runtime when this trigger point takes place, the system searches for the policies that are associated with it and returns the list of scripts from the corresponding action. These scripts are displayed after agents click the Churn icon on the customer 360-Degree View.

See Understanding Churn Management.

History Tracking

Use AAF to add data to a component's history table. The history provides a record of significant events related to a component. It 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 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

• 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 occurs, 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 these trigger points:

  • After a HelpDesk Change Request is Presented

  • Before a HelpDesk Change Request is Saved

  • After a HelpDesk Change Request is Saved

  • After a Self Service Change Request is presented

  • Before a Self Service Change Request is Saved

  • After a Self Service Request is Saved

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:

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

• If the child case status category is out of sync with the parent case (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 he 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 if 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 if 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

Use AAF to update a case with predefined field values. The fields that can be set using the case update action are:

• Resolved by First Contact

• Priority

• Severity

• Impact

• Status

• Category

• Specialty Type

• Detail

• Quick Code

Business unit is required to choose most of these values. Functional users must set up separate actions for each business unit. When setting a field using the case update action, the system reacts as if users enter the field value manually. If quick code is defined in the system, then all the fields that the quick code controls are also set for the case. Because a lot of the fields that the case update action supports are also available in quick code, it's suggested that users use this action to either 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

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

Upsell Indicator on Case

Use AAF to define conditions under which the Upsell button appears on the Case toolbar. The result of this action depends on whether Real Time Advisor is used.

Without Real-Time Advisor: There is no configuration required for this action. If the case has a product which is associated with an upsell script, the Upsell button appears on the case toolbar when this action is invoked. When users click the Upsell button, the branch script that is associated with the product for the case is launched. The script, once launched, appear in the related action summary for the case.

With Real-Time Advisor: When configuring this action, select the advisor dialog to launch when the Upsell button is clicked. In this case, the upsell branch script that's associated with the product is not used. The advisor dialog, once launched, appears in the related action summary for the case. If an order is created at the end of the dialog session, it is displayed in the Related Action Summary for the case as well.

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 in 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 this case suggest action supports 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

Alert Message or Recommendation Display

Use AAF to display information to end users through the HTML popup dialog box. The text that is displayed can either be informational or 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.

• Cross sell opportunity, up sell opportunity and recommendation related action types.

Cross Sell and Up sell Opportunity and Recommendation

Cross sell and up sell opportunity recognition action types run the Real-Time Advisor engine to get recommendations. Depending on the trigger point and the specific action used, the action type may put recommendations into a display window, offer to run a dialog session to get recommendations, or provide recommendations to an application to display. These actions can be triggered from different applications, including PeopleSoft Order Capture, Marketing, Support and the 360-Degree View.

The action types that fall in this category are:

• Display Activity Advisor Link

• Display Activity Recommendation

• Recommend Advisor Dialogs

• Recommend Link for OCI (order capture)

• Recommendations for OCI

• Start Advisor Session

• Up sell/Cross sell Advice on 360 (360-Degree View)

See Also

Setting Up PeopleSoft CRM Workflow

Working with Interactions

Setting Up Business Projects

Working with PeopleSoft Order Capture Business Projects

Setting Up and Managing Agreements and Warranties

Viewing Solution History

Reviewing Case History

Managing Related Cases

Performing Toolbar Functions

Configuring Actions in Policies

This section discusses how to:

• Configure display alert actions.

• Configure workflow actions.

• Specify process to run in workflow actions.

• Specify bind variables.

• Configure business project actions.

• Configure branch script actions.

• Configure display activity actions.

• Configure installed product history actions.

• Configure sales history actions.

• Configure change request history actions.

• Configure solution history actions.

• Configure case history actions.

• Configure case update actions.

• Configure case suggested actions.

• Configure case relationship actions.

• Configure case entitlement balance actions.

• Configure case upsell actions.

• Configure advisor actions.

Pages Used to Configure Actions in Policies

Configuring Display Alert Actions

Access the Display Alert Configuration page.

See PeopleSoft Enterprise Components for CRM 8.9 PeopleBook

Configuring Workflow Actions

Access the Workflow Configuration page.

Business Processes

Language specific Packages

Configure the AAF workflow to use different packages for different languages. If the role query of the specified role returns a person ID, the system derives the language from the person's record and identifies the correspondence package that is associated with the recipient's language in this grid. If no package is specified for that language, the system uses the default package to send the email notification.

See Also

Defining Workflow Actions

Specifying Process to Run in Workflow Actions

Access the Action Processes page.

Use this page to run application engine or application class processes, with or without sending any workflow actions.

Specifying Bind Variables

Access the Binds Required page.

Use this page to specify how the input values are supplied to the bind variables that are needed for the role query.

See CRM Action Types.

Configuring Business Project Actions

Access the Business Project Configuration page.

Select a business project that AAF instantiates when the evaluation of the policy conditions is true.

See Also

Understanding Business Projects

Configuring Branch Script Actions

Access the Branch Script Configuration page.

Select the scripts that AAF executes if the evaluation of the specified policy conditions is true.

See Also

Understanding Scripts

Configuring Display Activity Actions

Access the Activity Advisor Action page.

Program Details

Configuring Installed Product History Actions

Access the Installed Product History Configuration page.

History Details

Configuring Sales History Actions

Access the Sales History Configuration page.

See Configuring Installed Product History Actions.

Configuring Change Request History Actions

Access the Change Request History Configuration page.

See Configuring Installed Product History Actions.

Configuring Solution History Actions

Access the Solution History Configuration page.

The Extract Term Aliases button works the same as the Merge Tokens button in other history configuration pages.

See Configuring Installed Product History Actions.

Configuring Case History Actions

Access the Case History Configuration page.

Show in Self-Service	Select to give self-service users visibility to case history rows.
Page Name	Select the page that appears when the user clicks the Details button on the Case History page. Values in this drop-down list box include all pages in the agent-facing Case component. Self-service users can view case history, but they cannot access a detail page. Consequently, the system does not display a self-service page.

See Configuring Installed Product History Actions.

Configuring Case Update Actions

Access the Configure Call Center Update Action page.

Enter the field values that populate to a case when this action is invoked for it.

Configuring Case Suggested Actions

Access the Configure Call Center Suggested Action page.

Suggested Action Details

See Setting Up Links to PeopleSoft HRMS Pages and Related Actions.

Configuring Case Relationship Actions

Access the Configure Call Center Relationship Action page.

Child Reaction to Parent

Configuring Case Entitlement Balance Actions

Access the Configure Call Center Entitlement Balance Action page.

Entitlement Balance Details

Configuring Case Upsell Actions

Access the Action Configuration page.

Runtime Mode	Select the mode that the Advisor application is on at runtime, interactive, link or quiet. Interactive: the dialog appears and users interact with it to get recommendation. Link: the dialog appears only when users click on the link provided. Quiet: the dialog works in the background and doesn't involve user intervention.
Action Type	Select if the system should invoke action automatically or display the action so users have the option to execute it or not.

Configuring Advisor Actions

Access the Action Configuration page.

Advisor Dialog	Select the dialog that AAF executes when the evaluation of the specified policy conditions is true. Establish advisor dialogs using the Advisor Workbench. See Understanding Dialog Creation.
Template Name	Select the template to be used with the dialog. Templates are used to control the look and feel of the runtime environment for the end user.