You are on page 1of 43

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

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.

Working with the SFA Sample Application

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

Working with the SFA Sample Application

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

Working with the SFA Sample Application

the Year, Quarter and Months and sales goals (data instances of PegaCRM-DataSalesGoal) 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:


Working with the SFA Sample Application

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.

Working with the SFA Sample Application

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.

Working with the SFA Sample Application

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.
Working with the SFA Sample Application

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.
Working with the SFA Sample Application

10

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.

Working with the SFA Sample Application

11

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.

Working with the SFA Sample Application

12

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.

Working with the SFA Sample Application

13

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.

Working with the SFA Sample Application

14

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 attendees availability.

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

Working with the SFA Sample Application

15

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.

Working with the SFA Sample Application

16

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
Working with the SFA Sample Application

17

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.

Working with the SFA Sample Application

18

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.

Working with the SFA Sample Application

19

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.

Working with the SFA Sample Application

20

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.

Working with the SFA Sample Application

21

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.

Working with the SFA Sample Application

22

Working with the SFA Sample Application

23

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.

Working with the SFA Sample Application

24

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.

Working with the SFA Sample Application

25

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.

Working with the SFA Sample Application

26

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 postprocessing 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.

Working with the SFA Sample Application

27

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.

Working with the SFA Sample Application

28

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.

Working with the SFA Sample Application

29

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.

Working with the SFA Sample Application

30

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.

Working with the SFA Sample Application

31

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:

Working with the SFA Sample Application

32

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.

Working with the SFA Sample Application

33

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:

Working with the SFA Sample Application

34

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.

Working with the SFA Sample Application

35

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 PostMortem 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

Working with the SFA Sample Application

36

Common Pega rules configuration and setup functions such as configuring ruleset definitions,
Operator IDs 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-WorkSFA-Opportunity and are saved in the PegaCRM-SFA ruleset.

Adding a Step to a Stage

Because of SFAs 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.

Working with the SFA Sample Application

37

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.
Working with the SFA Sample Application

38

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

Working with the SFA Sample Application

39

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.

Working with the SFA Sample Application

40

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.

Working with the SFA Sample Application

41

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.

Working with the SFA Sample Application

42

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

43

You might also like