Working with the SFA Sample Application

Working with the SFA Sample Application Pega Sales Automation™ 7.13

January 2015

SFASample Package SFA 7.13 ships with a SFASample package that includes:

Sample data - (Accounts, Contacts, Tasks, Opportunities, Leads, Sales teams (Operators and their sales goals)) that fills the different screens in the end user portals with meaningful data.

Utilities to reset dates on sample data instances for easy setup of demo environments.

Sample extensions/rules:

Case life cycle management steps for opportunity case type. − NBAM / NBAA artifacts to setup and visualize integration with NBAM/ NBAA −

Package installation Import the RAP (/install/Sample/SFASample.jar) into the PRPC instance that includes the SFA7.13 code base.

The RAP includes the Rule-Application: SFASample 07.13.

Working with the SFA Sample Application 1

Rules related to the sample implementation are in the SFASample:01-01-01 ruleset.

Package verification You can verify the package installation by following logging into the sales rep and sales manager portals.

1. Go to the sales rep portal in SFA by logging in as tmason with the password: install.


2. Go to the sales manager portal in SFA by logging in as skendall with the password: install.


Resetting Sample Data The sample data that is shipped with the release has data falling into specific time periods. The objective of the Reset button is to ensure valid data is available even if the release is installed in a future time frame. To reset the data:

1. Log in as SFASampleSysAdmin using the password: install.

2. Launch the SFA SalesOps Portal and click Tools.

3. Click the Reset Sample Data option to reset the date ranges for sample data to fit into the current quarter. The current quarter is derived from the current system date and the corresponding time period record defined in the SFA application.

The Sample data set consists of a manager, Sarah Kendall, and her sales team. Clicking the Reset Sample Data button modifies data related to operator skendall and her sales team. An activity rule named PrepareDemoData is invoked that does the following:

Verifies time periods based on the current system date. If the time periods do not exist, it creates time periods (data instances of class PegaCRM-Data-TimePeriod) corresponding to


the Year, Quarter and Months and sales goals (data instances of PegaCRM-Data-SalesGoal) for all operators in the sales team. If time periods already exist for the current quarter then the time periods are not created.

A dynamic system setting named DemoBaseDate captures the baseline for the data in the sample RAP. This changes from release to release as the sample data gets updated. The reset utility uses the current quarter start date (based on current date) and the setting DemoBaseDate to compute the difference in days. The delta determines the number of days the data needs be adjusted.

For each of the opportunities owned by operators in the sales team, the CloseDate is updated by adding the delta.

For each of the tasks assigned to operators in the sales team, −

If status is Resolved-Completed, TaskDueDate value is updated by the delta. - If status is Open, the CompletedDate value is updated by the delta. -

The DemoBaseDate dynamic system setting is reset to the first date following the end of the current quarter. This is done to ensure that clicking on the same button multiple times does not move the data out to dates in future quarters.

Case Life Cycle Management (CLM) – Opportunity Cases Click the Opportunities tab in the left navigation items to display the opportunity page. Click on any of the opportunities to display the Opportunity Object.

The product contains stages for the Opportunity case type. However as steps are specific to implementations that are not included in the product, the sample application defines steps for different stages as working examples. This section of the document describes the sample steps and how they are implemented.

Feature Summary Within the opportunity object screen, the sales team members are provided with a stage view of the whole sales process to get a quick overview what steps are already completed and what needs to be done next.

In this example, the sales process contains the following stages:


Qualification

Analysis

Proposal

Decision

Negotiation

Closed.

At any time in the sales process a stage can be manually defined as the current emphasis and will be highlighted. For this the user uses the Change Stage button to open the screen to move from one stage to another.

As soon as one of the steps is complete, it is marked with a green checkmark as a visual indicator.


NOTE: There are no restrictions on what steps can be invoked in what stage. Any step can be run irrespective of the stage the case is in. Changing from one stage to another one is possible any time. This is to offer a flexible handling of the entire sales process and to be used only for guidance.

Step Definitions All steps are defined as short processes which contain at least a short description of what needs to be done in the appropriate step. In addition, a couple of steps contain values that need to be set or a specific kind of document that needs to be attached.

Commonly, a step is built by one screen only and can be completed by clicking Submit. This results in the green checkmark in the stage view. The step flows cannot be reset to their initial status but can be modified as needed at any time.

Determine Timeframe

This step can only be completed when the Close Date is set as a valid date. This value corresponds to the Close Date on the opportunity object.

Identify Stakeholders

A validation is implemented on the flow action to check if at least one stakeholder is defined for this opportunity. The list of stakeholders corresponds to the list on Contacts tab on the opportunity object.


Determine Budget

The opportunity Amount needs to be set prior to the step completion. This value is also shown on the opportunity object itself.

Identify Competition

The step completion is only possible when at least one competitor is defined for this opportunity. Therefore, a validation is implemented which runs when the user clicks Submit.


The list of competitors corresponds to the Competitors section on the opportunity object.

Identify Sales Team

Like other steps which contain lists, the step is only able to be completed when at least one sales team member is defined for this opportunity. Therefore, a validation is implemented that runs when the user clicks Submit.

This list corresponds to the Sales Team section on the opportunity object.

Proposal Development In this step a document attachment of the Proposal type is required before the step can complete. This is validated when the user clicks Submit.


Confirm Decision Date

The Close Date must be set before the step can be completed. Like the Determine Timeframe step, the close date field corresponds to the Close Date of the opportunity object.


Request Discounts

In comparison to most of the other steps, in the Request Discounts step no mandatory fields are defined.

Prepare Contract

Like the Proposal Development step, this step requires a document attachment of the Contract type before this step can complete. This is validated when the user clicks the Submit button.


Send Thank You

On this step, no fields are defined as required. By clicking Create Email, an Outlook mail template is created that is pre-filled with the following example content.

The sender is always the current operator logged into the system.

The recipient is the primary customer contact to this opportunity.

The cc recipients are all other customer contacts as well as the sales team members who are involved in that opportunity.

The mail body is provided by a template which is forwarded to the Outlook client during creation of the mail.


The step content is dynamic, depending on the closing status of the opportunity. As long as the opportunity is in progress or reactivated, or the opportunity is closed as Won, you see the Won content in the step as well as in the mail. If the opportunity is closed as Lost, the content in the step and in the mail changes accordingly.


Schedule Post-Mortem

On this step no fields are defined as required. The list that displays shows all appointments belonging to the current opportunity.

The appointment screen used in this step itself corresponds to the appointment definition which is reachable in the menu by clicking Appointments and either creating a new appointment or selecting an existing appointment from the list.

By clicking Create Appointment, the operator is able to schedule an appointment which is enhanced with the following content:

Subject and Body are pre-filled based on a template.

The attendee list contains all sales team members and is created prior to the display of the appointment screen.

If no Outlook information is available for an attendee, the schedule grid displays in grey color, otherwise the time schedule displays according to the attendee’s availability.

The operator is able to make any changes before the appointment will be sent.


Like the Send Thank You step, this step content is dynamic depending on the closing status of the opportunity.

As long as the opportunity is in progress or reactivated, or the opportunity is closed as Won, you see the Won content in the step as well as in the mail.

If the opportunity is closed as Lost, the content in the step and in the mail changes accordingly.


Stage Flows

Although stages and steps are independent from each other during the handling of the Opportunity Lifecycle Management, SFA provides the ability to run a step related to a specific stage in a combined stage flow. This is currently implemented for the Qualification stage/

The flow can be executed by clicking the Qualification link and runs all steps within that stage from top to bottom. However, the operator has the ability to cancel and leave this flow anytime. If parts of the stages are completed by clicking Submit during the run, they are marked in the stage view later on with a green checkmark.

Technical Implementation The appearance of the Opportunity Lifecycle Management leans toward the stage view which is already implemented in Pega out of the box to provide the case management for work. Also parts of this implementation are reused as far as possible.

However it is customized to cover the needs to support a flexible and efficient sales process because the standard implementation is made to support a powerful way to handle standard processing of flows and work objects, not explicitly made to cover a sales process.

This section describes the parts of the technical implementation of Opportunity Lifecycle Management and serves as an introduction for further customization and extension. Note that those definitions are technical and internal and are not necessarily reflected in the names used in the user interface. Also consider that any change to this configuration needs to be developed


by a system architect. Changes at runtime are not possible due to the fact that rules in Production rulesets are locked.

Case Type Rule In Pega terminology, the specific definition of a work type such as a sales opportunity is defined as case. The main configuration of this case takes place in a case type rule. For details how to define stages and steps for a case type, see the case management topics on the PDN and in the online help.

The SFA application itself contains the case type rule as well but without any step definition. Due to the rule resolution implemented in Pega, after the deployment of the sample application the sample data case rule is selected automatically during runtime.

The case type is defined as Opportunity (Work Class: PegaCRM-Work-SFA-Opportunity), and the associated technical rule is named pyDefault within that case type. All steps used in the stage view are defined within that rule, and any step definition represents a flow which is performed when the step is called - the step flow configuration is specified in a later section.

The red rectangle examples indicated in the image below are:

Opportunity: common case type definition

pyDefault: rule of this case type

Stage Qualification: definition of a specific stage

Manually launched processes, PurchasingTimeframe, IdentifyStakeHolder, and DetermineBudget are steps of the defined stage above, in this case these steps belong to stage Qualification.


All steps are maintained in the case type rule. So, if steps are added or removed, this needs to be configured in this rule.

To follow the intention to provide a most flexible sales process, all steps are defined as processes to be performed manually.

The Closed stage has a special configuration. When an opportunity is closed, the sales person needs to provide a reason for closing which can be either Duplicate, Lost, Suspended or Won. Depending on that reason, different steps with different content can be displayed.

In practice for this example it means that if an opportunity case is not closed or has any other close reason than Lost, then the Won-Content is used for step Send Thank You (SendThankYouWon) and Schedule Post Mortem (SchedulePostMortemWon), otherwise the Lost-Content (SendThankYouLost, SchedulePostMortemLost). During runtime this decision is made by specific When rules which check the related status and properties.


Not implemented in this version, but useful for further customization: the change from one stage to another one also can be validated by a specific Validation rule which is performed prior to the stage entry. In this validation rule particular conditions and requirements can be defined to check if the change to this stage is valid. The example shows that when stage Analysis is entered from any other stage, the Validation rule crmValidateAnalysisStageEntry assigned to the Analysis stage runs first.

Summarization The case type rule contains all stages and steps which are defined to build the whole sales

process.

Stage changes can be validated prior to be entered.

Each step represents a flow.

Steps can show up conditionally and verified by a specific When rule.


Stage View Customization In addition to the technical definition of stages and steps the standard stage view implementation in Pega serves as an overview where the object stays currently in the process and does not provide a step overview in the UI. However, for a sales process this is essential to keep efficient control in time.

To bridge that gap the solution is implemented by using the following features:

The crmLoadStageStatusDP load activity to calculate and store the appropriate visualization data.

The D_crmCaseStagesAllSteps data page on the clipboard as a container for opportunity specific visualization data.

Additional UI sections to provide a visualization of the Opportunity Lifecycle Management.

A value group property in the opportunity to track the step completion.

Load Activity

The crmLoadStageStatusDP load activity is used to propagate the needed visualization data on Data Page D_crmCaseStagesAllSteps.

The following description does not cover all details of the activity but focuses on the relevant functionality for the visualization. Attention should be paid to that visualization in this context means showing the needed identifier and providing related information, not UI styling which is not part of this description.

Step 2: this java step collects all data used to display the stage view later on. It accesses the case type rule to get the stage and step definition and creates the appropriate data structures for the current opportunity object.

Step 5: this java step prepares the data content which is important to show the stage view chevrons later as expected.

Step 6: the prepared visualization data is copied to the final Data Page.


Data Page

Commonly in Pega, Data Pages have the characteristic that they are created automatically at the first access or reference in the case they do not exist on the clipboard. Also, the defined Load Management automatically forces them to refresh. This behavior is used to simplify the implementation of the propagation of the stage view visualization data.

The Data Page to provide the stage view content is named D_crmCaseStagesAllSteps and is configured to Thread mode because each opportunity in fact has the same stage view but for instance the step completion state may differ.

It is also reloaded once per interaction to immediately cover any step state changes.


UI sections

The data of an opportunity case is presented in the pyWorkSummary section. This section is now extended with section crmDisplayStages which contains a repeating layout of all class entries stored on the D_crmCaseStagesAllSteps data page of the Embed-Stages class. This data is used in the crmStageName section embedded in the crmDisplayStages section.

For the step presentation each stage entry on the data page contains a list of steps belonging to a specific step. This data is used in the crmStageProcesslist section as a repeating layout of the .pxProcess page of the Embed-StageProcessHistory class. This section is embedded in the crmStageName section.

Value Group Property

The Opportunity Lifecycle Management provides the ability to indicate the step completion by using a green checkmark in the UI.


The indicator is set automatically when a step completes by clicking Submit.

During the post-processing actions on the flow actions of each step a data transform stores that information in the crmSetFlowsCompleted value group property by adding the current flow name as the value. The property itself is stored into the opportunity object. The following images demonstrate an example on a flow action and on the clipboard.


The crmFlowsCompleted value group property is used any time the stage view in the opportunity is rendered again.

Step Flow Definition

In the stage view, each step is represented by a link which performs a specific step flow by clicking on it. Those step flows, except the Schedule Post-Mortem step, do not create new work objects but they modify specific data of the opportunity itself or provide the ability to run certain actions such as sending emails and appointments as well as attaching documents to the opportunity.

The following description describes the common implementation of a step, and the specific implementation excerpts with regards to attachments, emails, appointments and validations.

Example: ProposalDevelopment step

The screenshot below shows the technical base flow definition which is almost equal for all step flows.


1. Setting properties, especially the initial value Proposal to identify the relevant attachment category for this flow.

2. The ProposalDevelopment assignment shape is used for user interaction and internally places the piece of work into the SFADefault workbasket from where the user picks up the work object.

3. The crmProposalDevelopment flow action performs the user interaction when the user clicks Submit. The user input is saved,the completion checkmark is set, the flow ends and the user returns to the opportunity screen.

4. The crmCancelAction flow action performs when the user clicks Cancel and runs some cleanup actions. Then, the user returns back to the opportunity screen without any modifications.

However, if needed on flow actions pre-processing actions (Activity or Data Transform) can run prior to the UI is shown to the user, validations can run to validate the user input, and post-processing actions can run to finalize the user interaction.

In the Proposal Development flow, the following actions are defined:

The crmPrepareProposalAttachments pre-processing activity runs prior to showing the UI. It prepares the list of already attached proposals to the opportunity on a temporarily clipboard page and initiates an indicator to show the attachment section only when attachments of the Proposal type are already exist.


The crmValidateProposal validation runs when the user clicks Submit to verify that a proposal is attached to the opportunity. Only in this case can the step flow complete successfully.

During post-processing, the crmSetCompletedFlows data transform simply sets the indicator that the flow is completed. The related property is used to show the green checkmark in the UI when returning to the opportunity object.


In post-processing, crmClearProposalAttachments activity runs after the attachment validation and cleans up the clipboard by removing the temporarily created attachment page.

Further actions on step flows Some step flows require further actions such as attaching files and sending emails and appointments. The pattern is as follows:

Provide a button which covers the needed functionality

If needed or applicable, data handling is handled by an additional flow action within a modal dialog. The flow action is commonly defined as a local action.


Attaching files to an opportunity As already shown in the example above the standard (out-of-the-box) AttachAFile flow action is widely reused. This is currently implemented for the Proposal Development and Prepare Contract step flows. Both implementations follow exactly the same pattern.

Sending an email via Outlook Pega 7 does not offer a standard implementation to provide data and external calls of email clients. So with regard to the requirements to open an Outlook template prefilled with recipients and text templates the only way to configure this requirement is to use the HTML href tag to propagate the needed data directly to the mail client. The disadvantage for this solution is that href calls the mail application which is set as default on the client machine. Therefore the implemented solution is only warranted to work with Outlook and may require modifications to work with other applications such as Thunderbird or Lotus Notes.

Sending an email is currently only implemented for the Send Thank You step flow.

A pre-processing activity on the flow action binds all needed data and prepares the content of the href tag within a property.


By clicking Create Email, an HTML JavaScript function performs the push of the href tag stored in the appropriate property to Outlook and causes an Outlook mail to be opened which can be modified by the user before sending out.


Sending an appointment via Outlook The SFA application already provides a customized appointment implementation which is reused and extended for this requirement.

The handling of a common appointment is realized as a specific work type and covers the processing within a flow with a separate Pega 7 UI. In this case, the appointment also needs to be associated automatically with the current opportunity.

Performing the Schedule Post-Mortem Won step flow as an example shows the following content:


If any appointments are already associated with the current opportunity, they are listed below. This list is a reuse of the Appointments section on the opportunity Activities tab.

A new appointment can now be created by clicking the Create Appointment button.

Then, the crmCreateAppointment local action is launched and the crmPreparePMWonApptmt pre-processing activity prepares all sales team members on the clipboard for further action and creates the appropriate work type for appointments on the AppointmentPage clipboard page.


By reusing the CreateAppointment section from the genuine appointment implementation the system automatically collects the availability data for all current known recipients via SOAP from the Exchange Server which needs to be preconfigured in Pega. After that the appointment screen appears as shown below:


The user may change the appointment content as needed and send the appointment by clicking on Send.

Then the crmFinishPMWonApptmt post-processing activity performs the creation of the appointment.


Within this activity there are 2 steps which are very important and show the high level of reuse within Pega:

All steps run on the AppointmentPage clipboard page which contains the whole work object data.

The call addWork activity is part of the standard implementation in Pega and provides the ability to perform adding work within an acitivity. This step calls automatically the genuine appointment flow implementation and persists then the appointment work object in the database.

The call crmLinkObjWrapper activity links the new created appointment to the current opportunity. To simplify the access the needed functionality is wrapped into this activity.

After this post-processing activity is executed, the user returns back to the Schedule Post-Mortem flow action and can complete the step flow. In the lower section the newly created appointment is automatically listed.

Guide to extend the Case Lifecycle Management Although it is recommended that system changes be done by a System Architect, they are relatively easy to implement. This section describes the following tasks:

Adding a step to stage (example for step Qualification)

Adding a stage flow


Common Pega rules configuration and setup functions such as configuring ruleset definitions, Operator ID’s or check in / check out are not part of this description.

As long as no other rules from different rulesets are used, all rules apply to PegaCRM-Work-SFA-Opportunity and are saved in the PegaCRM-SFA ruleset.

Adding a Step to a Stage

Because of SFA’s nature all steps are defined as manually launched processes.

There are probably a couple of ways to process this implementation, but in this case the description starts top down. Using the Opportunity as an example, the first step is to check out the case type rule for Opportunity and to select the Stages tab. However this description does not cover the specific functionality of the step flow itself.

To associate the new step to the Qualification stage, click the add symbol below the section of the already defined processes which are defined as manually launched, below the DetermineBudget step.


In the marked field, the process behind the new step needs to be placed, either adding an existing one or creating a new one. In this example the existing flow ExecutiveVisit is selected.

If a new flow is created, then it is important that this flow is saved prior to the save of the case type rule. Otherwise, an error message occurs.


Remember: Clicking the add icon (indicated by the arrow) either gives the ability to create a new flow or edits the existing flow.


This flow example is technically constructed very similar to the step flows. That means they have the following in common:

Each flow contains an assignment for user interaction. This assignment is named as the flow itself.

Each assignment has the crmCancelAction flow action which is performed when user clicks Cancel. It is responsible to clean up prepared data for the flow, if applicable.

Each assignment has a flow action to perform the flow-specific action and follows the naming convention crm<FlowName>.

To include a new flow behind a new step, that is all that needs to be done. The new step in the Case Life Management appears now in the Qualification stage. Assuming that the flow behind it is not in draft mode, it can be performed by clicking the ExecutiveVisit step.

If required, the step flow can now be modified and extended as needed.

Adding a Stage Flow A stage flow is nothing other than the serial combination of the step flows contained in the appropriate stage. The flows behind are now connected from top to bottom in a flow which performs them one after another. The only requirement is that the stage flow has to have the same Name as the stage itself. The Qualification step already contains a stage flow which can be performed by clicking on the stage name. It runs the step flow in the order as shown below.

The flow implementation itself has this shape.


Connector properties (A): set an indicator whether the flows are currently running in a stage flow. This influences the behavior of the contained flows.

The PurchasingTimeframe sub-process (1): reuses the already existing step flow PurchasingTimeframe. This applies as well for IdentifyStakeholder (2) and DetermineBudget (3).

Connector properties (B): resets the indicator mentioned for Connector properties (A).

Because each contained flow can be cancelled, the indicator is reset on the crmCancelAction flow action of the appropriate flow, because potentially following flows are not performed and the end of the stage flow cannot be reached.

Also beware that in any contained flow where the user clicks Submit, this flow is later on indicated on the stage view as completed.

As the next step, the flow needs to be associated with the stage. The stage itself represents a link within the stage name.


Technically this link is located in the crmStageName section and requires an Actions set configuration as shown below.

Again, to keep it dynamic, the stage flow name must be the same as the stage itself.


© Copyright 2015 Pegasystems Inc., Cambridge, MA

All rights reserved.

This document describes products and services of Pegasystems Inc. It may contain trade secrets and proprietary information. The document and product are protected by copyright and distributed under licenses restricting their use, copying distribution, or transmittal in any form without prior written authorization of Pegasystems Inc.

This document is current as of the date of publication only. Changes in the document may be made from time to time at the discretion of Pegasystems. This document remains the property of Pegasystems and must be returned to it upon request. This document does not imply any commitment to offer or deliver the products or services described.

This document may include references to Pegasystems product features that have not been licensed by your company. If you have questions about whether a particular capability is included in your installation, please consult your Pegasystems service consultant.

For Pegasystems trademarks and registered trademarks, all rights reserved. Other brand or product names are trademarks of their respective holders.

Although Pegasystems Inc. strives for accuracy in its publications, any publication may contain inaccuracies or typographical errors. This document or Help System could contain technical inaccuracies or typographical errors. Changes are periodically added to the information herein. Pegasystems Inc. may make improvements and/or changes in the information described herein at any time.

This document is the property of: Pegasystems Inc. One Rogers Street Cambridge, MA 02142-1209 Phone: (617) 374-9600 Fax: (617) 374-9620 www.pega.com

PegaSales Automation™

Document: Working with the SFA Sample Application

Product Version: 7.13

Updated: January 2015


Working with the SFA Sample Application

Documents

Transcript of Working with the SFA Sample Application