===========Dev Studio

overview======

Dev Studio

Robust, enterprise-grade Pega Platform™ applications depend on

cooperation between two key groups of application developers.

Domain experts — business analysts, citizen developers, and front-end

developers — provide valuable insight into processes and user needs.

Implementation experts — system architects, full-stack developers,

database administrators, and security administrators
— provide the expertise needed to address critical
use cases that require complex configurations.

In App Studio, domain experts can access core application development

features (case design, data management, and user experience) and

apply their knowledge to improve development outcomes.

To support advanced rule configuration in applications, Pega Platform

provides implementation experts with a second development environment, Dev Studio.

In Dev Studio, implementation experts access rule forms directly to

address complex or less-common configuration requirements.

In addition, Dev Studio provides features for

>configuring security permissions and access control,

>managing rules to promote reuse,
>addressing the performance limitations of an application.

By providing two development environments, Pega Platform supports each

group of application developers with an environment tailored to their skill level
and optimized for the tasks
they perform.

Co-develop solutions

Business analysts and citizen developers understand business needs.

System architects understand the capabilities of Pega Platform.

To help these two groups work together, Pega Platform enables a co-
development approach that embraces the strengths of each group.

This co-development approach empowers business analysts and citizen

developers as core members of a development team,
leveraging their knowledge to design better business
processes.
 By working together, domain experts and implementation experts can
create better solutions more quickly.

Promote reuse throughout the organization

In App Studio, developers configure rules such as processes, views,

correspondence, and service levels for a single case type.

In Dev Studio, developers access all the layers of an application and

can extend the rule scope from a single case type to an application, division,
or even the entire organization to create a library of
standardized, reusable rules.

Citizen developers and business analysts can use these tested and
proven rules to reduce development time for later releases.

Switch between studios as needed

Application developers can switch between App Studio and Dev Studio as
needed to configure rule behavior.

The upper-left corner of each studio contains a menu listing all the
studios available to the user.

To switch to another studio, select the studio name from the menu.

In addition, from App Studio, you can open specific rules in Dev
Studio.

Naming differences between studios

In Dev Studio, developers can access the rules created by citizen

developers, business analysts, and front-end developers in App Studio, though these
rules often carry different names.

The following table illustrates some common App Studio elements and the
different names used for those elements in Dev Studio.

App Studio
Dev Studio

Field
Property
Goal and deadline
Service Level Agreement (SLA)
Process
 Flow
Data relationship
Page

Developers can switch between App Studio and Dev Studio as needed to
configure rule behavior.

Developers can use Dev Studio to combine rules into solutions such as
completed views or processes for use in App Studio.

Developers in App Studio and Dev Studio configure the same rules, but
Dev Studio provides more configuration options.

Dev Studio provides access to the same application layer that

developers use in App Studio.

Configurations completed in App Studio can become live immediatey,

without requiring a review in Dev Studio.

Directed inheritance is the only option that allows an application

class to inherit rules defined for the Work- class.

Checking out a rule does not prevent an application from running the
rule.

Checking out a rule only prevents developers from updating the rule
until you check in the rule.

===================================================================================
===================================================================================
=================

========================Creating a rule===========================

Rules and rule types

When you model a case type in a Pega Platform™ application, you

configure the application with instructions to create, process, and resolve a case.

These instructions are rules.

Rules describe the behavior for individual cases, such as how the user
interface is displayed and when work urgency increases.

Pega Platform uses the rules you create to generate application code in
the background.

Each rule is an instance of a rule type.

Pega Platform provides many rule types to use as templates for creating
a rule.

The rule type determines the type of behavior modeled by the rule.
 Each rule type models a specific type of behavior, such as automated
decisions or UI design.

For example, to model a process you use a specific type of rule called
a flow rule.

Automated rule creation in App Studio

Much of the work of designing an application can be completed using App

Studio.

Pega Platform provides a simplified interface that automatically

creates and manages the underlying rules while allowing developers to focus on
business tasks.

For example, when you configure a case type in App Studio, you use the
case life cycle and configuration panels to

add processes,
define steps, and
configure views.

In the background, Pega Platform creates and manages the rules that
define

the process flows,

tasks, and
UI.

Application modularity with rules

The use of individual rules makes your application modular.

By describing case behavior with

modular,
task-focused rules,
you can combine and reuse rules as needed.

For example, you create a rule to describe the content of a customer

email regarding the status of a change of address.

By creating the email message as a separate rule, rather than embedding

the message in the case life cycle, you can update the content of the email without
impacting the rest of the business process.

This modularity provides three significant benefits:

>versioning,
>delegation, and
>reuse.
 Versioning

Developers create a new version of a rule whenever case

behavior needs to change.
Pega Platform maintains a history of changes to a rule,
allowing developers to review the change history and undo changes if needed.
Because each rule describes a specific case behavior, the
rest of the case remains unaffected.

For example, a developer updates a UI form with

instructions and removes a critical field.
You can review the history of the form and revert to the
version before the changes were made, without changing other rules in the
application.

Delegation

Developers delegate rules to business users to allow

business users to update case behavior as business conditions change.
The business user updates the delegated rule, while other
parts of the application remain unchanged.

For example, expense reports that total USD25 or less

receive automatic approval.
You create a rule to test whether an expense report totals
USD25 or less and delegate the rule to the Accounting department.
The Accounting department can then update the rule to
increase the threshold for automatic approval increases to USD50,

without submitting a
change request for the application.

Reuse

Developers reuse rules whenever an application needs to

incorporate existing case behavior.
Otherwise, you must reconfigure the behavior every time you
need the behavior.

For example, you create a UI form to collect policyholder

information for auto insurance claims.
You can then reuse this UI form for property insurance
claims and marine insurance claims.

While you can create rules manually in Dev Studio, rules are also
created in the background when working in App Studio.

Rules can be reused.

A rule is an instruction for describing a specific case behavior, such

as a process or automated decision.
 Rulesets

To package rules for distribution as part of an application, you

collect rules into a group called a ruleset.

A ruleset identifies, stores, and manages the set of rules that define
an application or a significant portion of an application.

If a rule is similar to a song, a ruleset is similar to an entire

album.

you can share a ruleset between applications to allow several

applications to use the same rules.

The ability to re-use already-built rules saves development time and

effort.

Ruleset versioning

Developers collect individual rules into an instance of a ruleset,

called a ruleset version.

To update the contents of the ruleset, you create a new ruleset

version.

The new ruleset version is available — or unlocked — for the developer

to make rule updates and add new rules.

It is a best practice to lock older versions of the ruleset.

Ruleset versioning helps developers identify and manage changes to an

application.

Pega Platform™ manages the creation of rules and identifies the ruleset
and version in which to store rules for applications created in App Studio.

Pega identifies rulesets by names and version numbers.

The version number is divided into three segments:

a major version,
a minor version, and a
patch version.

Each segment is a two-digit number starting at 01 and increasing to 99.

Ruleset version numbering starts at 01-01-01 and increments upward.

Major version

The major version represents a substantial release of an application.

 A major version change encompasses extensive changes to application
functionality.

For example, the Accounting department uses an application to manage

expense reports.
If Accounting wants to extend the application to track employee
time off for payroll accounting, you create a new major version of the ruleset.

Minor version

The minor version represents an interim release or enhancements to a

major release.

For example, you need to update an expense reporting application to

make automatic audit travel reimbursements.
You create a new minor version of the ruleset.

Patch version

The patch version consists of fixes to address bugs in an application.

For example, you notice that a field in the current version of an

application has an incorrect label.
You create a new patch version to correct the field label.

Ruleset stack

Each application consists of a sequence of rulesets called a ruleset

stack.

The ruleset stack determines the order in which Pega Platform looks
through rulesets to find the rule that is in use.

Each entry in the ruleset stack represents all the versions of the
specified ruleset,
starting with the listed version and working down to the lowest
minor and patch version for the specified major version.

Each version of an application contains a unique ruleset stack.

The ruleset stack allows an updated application to reference new

ruleset versions that contain updates and new features.

A ruleset stores a set of rules that define an application or major portion

of an application. It is not appropriate to create a new ruleset to address a bug
fix.

Major versions are appropriate for substantial changes to application

functionality. It is not appropriate to create a new major version to address a bug
fix.

Minor versions are appropriate for enhancements to a major release. It is not

appropriate to create a new minor version to address a bug fix.

Patch versions are appropriate for bug fixes.

Rule creation in Dev Studio

If you need more control over how a rule is created and reused, you can
create the rule in Dev Studio.

When you create a rule in Dev Studio, the New Record form prompts you
to provide four pieces of information:
>rule type,
>identifier,
>class, and
>ruleset.

This information is used to identify the rule uniquely within your

application.

This combination allows an application to call the correct rule during

case processing, through a process called rule resolution.

With rule resolution, Pega Platform™ determines the appropriate rule to

run when an application calls a rule.

Note: Dev Studio uses the term records to refer to

>rules,
>properties, and
other objects in Pega Platform.

You can access rules from the Dev Studio navigation menu by clicking
Records and selecting a rule type to display a list of rules of that rule type.

Rule type
The rule type determines the type of behavior modeled by the rule.
Each rule type models a specific type of behavior, such as automated
decisions or UI design.

Identifier
The identifier, or ID, identifies the purpose of the rule.

Class
The class identifies the scope of the rule. You specify the class of a
rule in the Apply to field.
 The class you select determines the extent of how you can use the rule:
within one case type, or across case types.

Ruleset
The ruleset is the container for the rule.
The ruleset identifies, stores, and manages the set of rules that
define an application or a major portion of an application.

Pega Platform creates an instance key — stored using the property .pzInsKey —
to identify each rule on the system uniquely.

The instance key generally consists of four elements separated by a space:

The internal name for the rule type

The applies to class for the rule
The identifier of the rule
The timestamp from when the rule was created, normalized to Greenwich
Mean Time (GMT)

For example, you create a service level at 11:31:52 AM on January 20,

2021, by providing the following information on the New Record form.

Identifier: StandardApproval
Apply to class: MyOrg-MyApp-Work-CaseType

The .pzInsKey for the rule is RULE-OBJ-SERVICELEVEL MYORG-MYAPP-WORK-

CASETYPE STANDARDAPPROVAL #20210120T163152.765 GMT.

Note: Some rule types extend the instance key with additional elements.

Different methods of rule creation in Dev Studio

Method
Information specified on the New Record form\

Create a rule from the Create menu The rule type,

application context, and ruleset are specified by default.
Create a rule from the App Explorer The rule type,
application context, ruleset, and class are specified by default.
Create a rule from a rule reference The rule type,
application context, ruleset, and class are specified by default.

If the name of the rule is provided in the reference, the label and
identifier for the rule are also specified.
Open an existing rule and click Save As The rule type,
application context, ruleset, class, label, and identifier are specified by
default.

However, at least one of the following pieces of information must change, or

Pega Platform returns an error when you click Create and open.
 Identifier

Class

Ruleset

Tip: When creating a rule from a rule reference, the label is

determined from the rule name in the referencing field.

The application context impacts the choices available for class and ruleset
when creating a rule but is not used as part of the instance key.

The rule type helps to uniquely identfiy the rule on the system by
identifying the function of the rule.
For example, an SLA rule performs a different function than a
flow rule.

The class that is applied to the rule helps to uniquely identfiy the rule on
the system by identifying the applicable scope of the rule.
Changing the class of a rule allows you to specialize the rule
for a specific class and any child classes.

The ruleset acts as a container for a rule but is not used to generate the
instance key for the rule.

The name of the rule helps to uniquely identfiy the rule on the system by
identifying the intended use of the rule.

For example, an SLA named Approval codifies the goal and deadline for case
approvals, while an SLA named Claim adjustment codifies the goal and deadline
for an adjustor to estimate the cost of covered
damage for an insurance claim.

To select a class name that is not a case or a data type, click the View all
link.

Note: The Production Rulesets option appears as the first option in the stack
if your current access group has production rulesets defined.
Choosing this option restricts the Add to ruleset field only.

Inheritance methods

Inheritance allows your application to reuse existing rules for other

cases or applications.
 Rule reuse reduces development and testing time without sacrificing
application quality.

Pega Platform™ provides two methods for rule inheritance:

pattern inheritance and

directed inheritance.

Pattern inheritance

Pattern inheritance is automatic. Pattern inheritance uses the class

name structure to determine rules available to reuse.

It searches for the rule of interest following the class hierarchy — in

other words, pattern inheritance searches classes that share a class name prefix.

Because rules are aggregated at higher levels to reflect their

usability throughout an entire division or organization,
pattern inheritance promotes reuse
based on business suitability.

Directed inheritance

Directed inheritance is inheritance between classes where the parent

class is explicitly specified, unlike pattern inheritance, which is automatic.

You apply directed inheritance to reuse standard Pega Platform rules

and rules from other applications outside the business class hierarchy.
You list directed inheritance on the class rule form.
Because rules are aggregated based on whether they apply to all cases
or cases of a certain type, directed inheritance promotes reuse based on functional
suitability.

For example, a rule may be limited to a specific implementation, such

as an auto insurance application, or applied to all implementations,
including applications for property and marine
insurance.

Inheritance and rule reuse

Pega Platform first searches through the parent classes indicated by

pattern inheritance when reusing rules through inheritance.

If unsuccessful, Pega Platform then searches the parent class indicated

by directed inheritance as the basis for another pattern inheritance search.

This process repeats until the system reaches the last class in the
class hierarchy, called the ultimate base class or @baseclass.

If the system cannot find the rule after searching @baseclass, Pega
Platform returns an error.

All classes inherit from @baseclass.

In a Pega Platform application, @baseclass is the ultimate base class. All

other classes inherit from @baseclass.

Classes

Pega Platform™ facilitates rule reuse between case types and

applications.

Developers often reuse rules — from single data elements to entire

processes — in applications.

Rule reuse improves application quality and reduces development time.

Within an application, Pega Platform groups rules into classes

according to their capacity for reuse.

Each grouping is a class. Each application consists of three class

types.

>The Work class contains the rules that describe how to process a
case or cases, such as processes, data elements, and user interfaces.
>The Integration class contains the rules that describe how the
application interacts with other systems, such as the integration assets that
connect

the application to a customer database or a third-party web server.

>The Data class contains the rules that describe the data types
used in the application, such as a customer data type or order items data type.

Note: When you create a rule in App Studio, App Studio identifies the
appropriate class for you.
You can focus on what you want the rule to do, rather than on how to
create the rule.
If you need control over the class, you can use Dev Studio to create
the rule.
One reason for switching to Dev Studio is to create a rule that you
plan to reuse in a different application.

The Data class is a type of class that contains rules that describe the
data objects used in the application.

The Work class is a type of class that contains rules that describe how
to process a case or cases.

The Integration class is a type of class that contains rules that

describe how the application interacts with other systems.

Pega Platform groups rules according to their capacity for reuse.

Parent and child classes

A class can also contain other classes. A class that contains another
class is a parent class, while a class that is contained by another class is a
child class.
A child class can reuse or inherit any of the rules defined for its
parent class.

The Work class contains a child class for each case type in your
application.
Each case type child class contains all of the rules unique to a case
type, such as an auto insurance claim.
The Data class contains a child class for each data type.

Note: View the classes in your application and their relationships from
the App Explorer, which is accessed from Dev Studio.

Parent class
A class that contains another class is a parent class.

Child class
A class that is contained by another class is a child class.
By the definition of class inheritance, the child class can use
all of the rules that are defined for the parent class.

Class hierarchy

The classes that comprise an application are organized into a multi-

level class hierarchy to organize application assets.
Classes are organized from most-specific to least-specific in the class
hierarchy.
The class hierarchy determines how developers can reuse rules within
the application.
The application can leverage any rule that is available to an
application through the class hierarchy.
The application cannot leverage rules that an application cannot access
through the class hierarchy.

When attempting to identify the rule to use at run time, Pega Platform
starts with the most-specific class and expands the search to increasingly general
classes.

The name of each class identifies the position of the class within the
class hierarchy. Consider the TGB-IT-Work class.
A hyphen separates each level of the class hierarchy (-). So, TGB-IT-
Work is a child of the class TGB-IT, which is a child of the class TGB.
 Case type classes
A case type class describes a specific case type, such as expense
reports or auto insurance claims.
The rules associated with case type classes are unique to the
corresponding case type and are not reused elsewhere in the organization.

Work classes
Work classes contain all case types in an application.
In a Pega Platform application, all case types in an application are
associated with a work class.

While integration and data classes can occur at any level of the class
hierarchy, work classes are generally the most specific of the three classes.

Application classes
The application layer contains the required work, integration, and data
classes for a single application and allows for sharing common rules among these
classes.

Div / Unit classes

You create division and unit layers only when necessary. The division
layer contains the work, data, and integration classes for the division.
The optional unit layer contains the work, data, and integration
classes for the unit.
These classes allow the reuse of rules at the division and unit level,
such as an approval process shared across the entire IT department.

Organization classes
The organization layer contains all the classes for applications across
an entire business or organization.
The organization layer often contains data and integration classes that
can be applied across the entire organization.

Other application classes

Classes from other applications, such as industry-specific Pega
Platform applications, are contained in what is sometimes referred to as the
framework layer.

Base classes
Pega Platform provides base classes. These classes contain rules that
provide basic functionality for case processing.

For example, the Pega Platform provides data elements that record who
created a case and the time needed to complete an assignment.
 Based on the class hierachy, the ABCInc-HR class is a parent class to the
ABCInc-HR-Hiring class. The ABCInc-HR class has a work class, integration class,
and data class.
While integration and data classes can occur at any level of the class
hierarchy, work classes are generally the most specific of the three classes.

===================================================================================
===================================================================================
=======================

=========Manipulating application data=======

Data transforms

The purpose of a data transform is to manipulate data in an

application.

Data transforms copy or manipulate data into the form you require.

Data transforms can be used to convert data from one type to another,
iterate over page lists, or page groups and copy entire pages at a time.

You can use data transforms to convert data from one type to another
type. For example, to complete the checkout process in the purchasing application,
the customer must provide their card number in the payment gateway.

Use a data transform to copy and convert the stored string format
credit card information into the card number property.

Note: To convert the string into a number, open the expression builder,
click the Configure icon, and use the out-of-the-box (OOTB) functions available in
Pega Platform™.
In the credit card number example, you can use the toInt() function.

Tip: When accessing information in different cases (for example, in a

parent-child case relationship), consider referencing data from the parent case
rather than copying information from the parent case to the child case.
Reference data to avoid synchronization issues if data changes on the
parent case.

For data transforms that initialize cases, use the pyDefault name.

the Context section, specify the Pega Platform ruleset context for your
data transform
 Data transform actions for Clipboard

To save time while processing your cases, populate data in your

application by using data transforms.
When you use data transforms, you can convert data from one format and
class to another format and class.

When you configure a data transform using the Clipboard data model, you
select an action that you want to perform on the data.

You can select the following actions:

Set

Sets the target to equal the source. You can set single-value
properties, top-level pages, embedded pages, page lists, and page groups.
You typically use this action to initialize properties.
If the target pages that you specify do not exist on the
clipboard, the Set action creates the pages.

Remove

Deletes the target and any associated values from the clipboard.

Update Page

Sets the context for setting properties on the target page. Use
to set properties on a page that is different from the primary page.
If the target page does not already exist on the clipboard, the
system creates the page.
If the source page is different from the primary page, from the
Relation list, select with values from, and then specify the source page.

Apply Data Transform

Applies another data transform to a clipboard page that the

previous action specifies in the current context.

Sort

Creates custom ordered lists. You can sort a page list according
to single-value properties in that page list.
You can specify a sorting order for each property as either
ascending or descending order.
In the Target column, click the View Sorting Properties icon to
specify the properties on which to sort and the sorting order for each property.

Comment

Specifies descriptive text. Use this action to provide comments

within the sequence.
 For example, you can explain the goal of a branch of steps.

When

Specifies a condition to evaluate to determine whether to apply

the subsequent actions.
If the condition evaluates to true, the system applies the action
within the child rows.
If the condition evaluates to false, the system continues with
the action specified within the next row.
If the action in the next row is Otherwise or Otherwise When, the
system applies the action if the condition evaluates to true.

Otherwise When

Specifies another condition to meet before the system applies an

alternate condition.
If the condition evaluates to true, the system applies actions
within the child rows.
If the condition evaluates to false, the system continues with
the action specified within the next row.
You can use this action after you use a When or Otherwise When
action.

Otherwise

Specifies the alternate actions to apply if the preceding When or

Otherwise When action evaluates to false.
You can only use this action after a When or Otherwise When
action.

Note: If you add When, Otherwise When, and Otherwise actions to your
data transform, the system performs only one of these actions,
depending on the first of these actions that evaluate to true.

Append to

Copies a page to the target. You can copy a page if the source
and the target are of the same class,
or if one of the classes
is higher in the class hierarchy in the inheritance path.

Append and Map to

Adds a page to the target and maps properties and their source
values to the target properties.
The source and target can be of different
classes.

For Each Page In

Iteratively applies actions specified in the subsequent rows to

all the pages in the specified target.
Ensure that the target is a Page List or a Page Group.
 Exit For Each

Exits the current iteration defined by the preceding For Each

Page action.
You can use this action only as a child
row of a For Each Page In action.

Exit Data Transform

Stops the data transform at the row that contains the Exit Data
Transform action.

Note: You can also call a data transform automatically from a case life
cycle in a low-code way in App Studio.

A data transform can be configured to set a value on a target property.

A data transform can be configured to copy some or all items from a

list.

===================================================================================
===================================================================================
=================

========Escalating late work==============

Passed deadline interval

The passed deadline interval defines when to take further action

because the step or case is past the deadline.
The interval measures the time that has passed since the deadline for a
still-open assignment.
The passed deadline interval is configurable in Dev Studio only.

Unlike the goal and deadline intervals, you can configure the passed
deadline interval to repeat a fixed number of times, or repeat indefinitely until
the user completes the assignment.
You can continue to increase the assignment urgency and send an
escalation action each time the passed deadline elapses.

Urgency with the passed deadline interval

The maximum urgency is 100.

 At an urgency value of 100, Pega Platform™ ignores further urgency
adjustments and continues other escalation actions.

For example, if the deadline passes, Pega Platform notifies the

assigned user.
If the assignment urgency is 100 at deadline, Pega Platform ignores the
urgency increment and still sends the notification.

Configuring a passed deadline interval

Enforce service level agreements and maintain the timely resolution of

cases by defining goal, deadline, and passed deadline time intervals.
Goal and deadline intervals are defined in App Studio or Dev Studio
from the case life cycle.
The passed deadline interval is defined in Dev Studio from the service
level agreement rule.

Goal and deadline intervals do not repeat.

You can configure the passed deadline interval to repeat a fixed number
of times or repeat indefinitely until users complete the assignment.

The assignment urgency increases to 30 at 4 P.M. Wednesday. The urgency

then increases to 50 at 10 P.M. Wednesday.
The urgency then increases to 70 at 4 A.M. Thursday. The urgency then
increases to 90 at 10 A.M. Thursday.
The urgency does not increase again until 4 P.M. Thursday, so the
urgency remains at 90 at 1 P.M.

===================================================================================
===================================================================================
=========================

=========Configuring cascading approvals with a reporting

structure============

Cascading approval

Approvals vary depending on the case type. An auto insurance case type
may need one approval from the company underwriter.
Some case types, such as a purchase request or an expense report, may
require a series of approvals — a cascading approval process configures a series of
approvals.

When configuring a cascading approval, consider the following

questions:

>Who needs to perform the approval?

>How many approvals are required?
>Is approval by the entire reporting structure required, or only
a subset of the hierarchy?

The two cascading approval models are reporting structure and authority
matrix.
Cascading approvals based on reporting structure require the approval
of a user's direct manager and higher.
You can also configure business logic to set thresholds to determine
the number of required approvals.

Reporting structure cascading approval options

You configure cascading approvals in Dev Studio.

Reporting structure cascading approval options include:

>The operator that completes the approval

The reporting structure approval generates a set of
approvers using the information on the user's operator ID record.
Either the user's Reporting manager or the Workgroup
manager completes the approval.
At run time, Pega Platform™ looks up the appropriate
approver based on the current user.

>The number of approvers in the structure

One – The Reporting manager or the Workgroup manager
All – The entire manager hierarchy
Custom – Number of levels as needed to evaluate when
rules

===================================================================================
===================================================================================
=============

====== Automating
decisions with decision tables========

Decision tables in Dev Studio

A decision table uses a set of conditions to test property values and

return an appropriate response.
In App Studio, you can use a decision table to calculate the value of a
field.
In Dev Studio, additional capabilities of decision tables allow you to
>delegate responsibility for maintaining decision logic,
>expand the result options, and
>direct flow processing.

Expand the options for returning a result

Decision tables used to calculate a property value return a single

result based on the decision logic.
In Dev Studio, you can configure a decision table to return all
successful results or set the value of additional properties.

Evaluate all rows

To return all successful results from a decision table, select the

Evaluate all rows check box in the Results tab of the decision table rule form.
When enabling Evaluate All Rows, all rows of the table are checked.
When the condition is met on a row, the defined action and return
calculation for the row is performed.
Clear this check box to stop processing after the system finds the
first row that evaluates as true.

Note: When Evaluate all rows is set to true, the Allowed to return
values setting is disabled.

Direct flow processing

The sequence of steps required for a case sometimes varies based on the
details of the case itself.
You can automate decision-making during a process by using a decision
table.
Two examples of using decision tables in a process are determining the
next step in a flow and routing an assignment.

Determine the next step in a process

You can determine the outcome of a flow using a decision shape to

return an outcome based on several testable conditions.
Adding a decision shape to the flow makes business processes flexible
and responsive by providing conditional paths that a case can follow to reach a
resolution.
In Dev Studio, you add a decision shape to a flow by clicking on Flow
shapes and selecting Decision.

Tip: When you specify the decision table for a decision shape, Pega
Platform™ automatically adds a connector for each decision result.
 Route an assignment

Determine the appropriate operator or workbasket for an assignment by

selecting a decision table router,
such as assigning a portfolio consultation to the appropriate branch
office based on the address of the requestor.

The router uses the decision table logic to determine the appropriate
operator or workbasket for the assignment.

A decision table is used to set the value of a property (in this

example, user status) based on conditional logic.
If a user reached the Bronze, Silver, or Gold spending and sale
thresholds, their customer status field would return the appropriate status.

Orders over USD50 ship free by using a standard ground service, whereas
orders over USD500 ship by using an expedited shipping service.

You can configure a property value to be greater than and lower than
certain amounts.

Note: A warning icon appears in rows that are unreachable or empty.

At run time, your application processes all rows in the table and
performs all the results from the columns that evaluate to true.

===================================================================================
===================================================================================
==================

============Automating decisions with decision trees=================

Decision tree logic

You can use decision trees to handle logic that returns a result from a
set of test conditions.
Decision trees can evaluate against different test conditions and
properties.
A true comparison can lead to additional comparisons.
 Differences between decision tables and trees

Both decision tables and decision trees evaluate properties or

conditions to return results when a comparison evaluates to true.
While decision tables evaluate against the same set of properties or
conditions, decision trees evaluate against different properties or conditions.

Decision table

In a decision table, the values in a column evaluate against the same

property/operator pair, such as Account type =, to return a value or property.
Developers can use a decision table when they have to evaluate many
combinations of the same set of properties or conditions to return one value or
property.

For example, a company uses the number of years at the company and
ratings on five employee evaluation metrics to determine bonus eligibility.

Decision tree

Each branch in a decision tree evaluates the property/operator pair

against a single value to perform an action, such as return a value or evaluate a
nested condition.
Developers can use a decision tree when they must evaluate conditions
on different properties that may be dependent on other conditions.
Each branch in a decision tree is evaluated, and all branches that
evaluate to true perform the action that is described after, such as continuing the
evaluation to the nested condition.

Decision tables and decision trees cannot always be used interchangeably

within Pega Platform™ applications.

You can reference a decision table or decision tree on flow rules, declare
expressions, activities, or routers.

Some configurations, such as cascading approvals with an authority matrix,

only support evaluation of decision tables.

The line-by-line structure of the decision tree makes it easy for a business
stakeholder or low-code developer to configure and
update dependent conditions that evaluate
against different properties.

The table structure of the decision table makes it easy for a business
stakeholder or low-code developer to configure and update a decision that
evaluates against many of the same
properties.

Tip: Conflicts are reported as warning messages when you save the form and
displayed on the Guardrails landing page.

Calculate a value from a set of properties or conditions where true

comparisons can lead to additional comparisons,
organized and displayed as a tree structure, by
creating a decision tree.

===================================================================================
===================================================================================
===========

======Configuring cascading approvals with an authority matrix=======

Cascading approval

There are two cascading approval models:

>reporting structure and
>authority matrix.

A cascading approval based on an authority matrix is more flexible than

a reporting structure.
You use the authority matrix model when configuring a process that
requires approvals from multiple entities, with at least one entity outside of the
reporting structure.
A set of rules directs the approval chain to entities outside of the
reporting structure, within and external to the user's organization.

An expense report that requires approvals outside of the reporting

hierarchy (for example, to accounts payable) uses an authority matrix model.

Authority matrix data structure population

A cascading approval with an authority matrix requires the

configuration of a data structure that identifies the approvers.
The application queries the structure for each approval until the
listed approvals are exhausted.

Pega Platform™ provides several ways to populate the data structure.

One common approach is to configure a decision table to identify the
approval levels and corresponding parties.
Pega Platform parses the list to populate the data structure.

Tip: When using a decision table with an authority matrix, set the decision
table to Evaluate all rows to return a list of results.
Otherwise, the decision table returns only one
result.

===================================================================================
===================================================================================
================
 ======Creating and managing teams of users========

Teams of users

Resource-sharing across the organization

Operators and work queues are associated with business units in the
organization.
You can create work groups so that resources can be shared across the
entire organization, regardless of the business unit the operator is associated
with.

Note: Operators in Dev Studio are also called users and people in App
Studio.
A work group identifies a cross-functional team that contains a manager
and a work queue.
The work queue in a work group contains shared work.
Operators associated with a work group can share work among operators
in different business units.

Work groups and operators

Each work group contains one work queue that can be shared by operators
associated with the work group.
An operator must be associated with at least one work group and can
belong to more than one work group.
Associating operators to work groups allows businesses to manage how
individuals share work without affecting the organizational hierarchy.

Work group managers

A work group identifies one operator who is the work group manager.
The system can use manager information in a work group for notification
tasks and routing tasks.
Work groups give managers the flexibility to assign, monitor, and
report on work performed in each work group.
Managers use the User Portal to access the work performed in work
groups.

Note: The User Portal refers to work groups as teams.

Work groups can contain Authorized managers to help transfer

assignments.

A user has access to the work queue for their work group.

When assigned to multiple work groups, a user can access the work queue
for each of their work groups.

A work group gives users access to a work queue shared among users from
different business units.
===================================================================================
===================================================================================
==========

=================Viewing data in memory================

Cases are collections of data.

Sources of case data include user input, calculations, system actions, and
integrations to external systems such as a database of registered motor vehicles.

Pega Platform™ applications capture, manipulate, and present data throughout

a business process to process and resolve a case.

As a result, applications generate large amounts of data.

While developing applications, you may need to review the application data to
check for correctness.

Incorrect information can cause errors that lead to undesired results for
cases.

Each data element in a Pega Platform application is a pairing of two pieces

of information:
>the name of the data element (determined by a property rule),
and
>the value assigned to the data element or property.

While processing a case, these data elements remain in memory for use by one
or more users.

Each data element is stored in memory on a page.

A page is a structure for organizing data elements in an application.

Some pages are created by the system to track user or session data.

During case processing, each page remains in memory in a structure known as

the clipboard.

The clipboard is the portion of memory on the server reserved by Pega

Platform for the data generated by applications.

The clipboard consists of all of the pages used to track the property-value
pairs that represent case and session data.

The clipboard receives its name because pages can be added to or removed from
memory as needed to track case or session data.

When a value is assigned to a data element, the data element and its value
are on the clipboard.

As you run a process, Pega Platform updates the clipboard, adding or removing
pages and properties from memory.

Your application uses the clipboard to populate fields on UI forms, perform

calculations, and evaluate decisions.

The Clipboard tool

Pega Platform™ provides the Clipboard tool to display data in memory.

The Clipboard tool organizes and presents all the pages in memory,
listing all the properties on each page and the value of each property.

You can also use the Clipboard tool to update and add properties to
test features that rely on data not yet added to a case, such as decisions and UI
forms.

The Clipboard tool is accessible from the Developer toolbar and

contains three areas:
>the header,
>the left pane, and
>the right pane.

The Clipboard tool provides a snapshot of the current contents of

memory, such as the current user information.

The Clipboard tool allows you to set a property value on data not yet
added to a case.

Clipboard page organization

Pega Platform organizes pages on the clipboard into four categories

>User Pages
>Data Pages
>Linked Property Pages
>System Pages

User Pages

The User Pages category contains pages created due to user

action, either directly or indirectly.
User pages contain data related to work being performed in the
selected thread.
While a user processes a case, all the pages used to store data
about the case are listed in the User Pages category.

A page named pxFlow("VacationRequest"), an element of a page

group named pxFlow on the top-level page named pyWorkPage
 Data Pages

The Data Pages category contains read-only data pages defined by

data page rules.
Data pages cache in memory data sourced elsewhere, such as from a
third-party service or a system of record.

A read-only page named pxResults, on the top-level page named

D_pzListOfProductTypes, sources data from an external database

Linked Property Pages

The Linked Property Pages contains read-only pages created by

linked properties, which contain information from data type referenced by a linked
property.
Linked properties are advanced data constructs, typically created
and configured by more senior developers.

A read-only page created by the .pyOrigDivision property that

references two source properties to display the Division Cost Center

System Pages

The System Pages category contains pages that describe the

current user session, such as the active user and the active application.
For example, while a user is logged in to Pega Platform, Pega
Platform maintains a clipboard page containing information about the user, such as
their current time zone.

A page named pyUserPortals(1)(Embed-PortalLayout) on the top-

level page named AccessGroup (Data-Admin-Operator-AccessGroup)

pyWorkPage stores data that is generated during case creation and processing.

pyWorkPage is a specific page on the clipboard and stores data such as the
case creation date or the case ID.

Embedded pages within pyWorkPage store sets of case data as defined by a data
type.

When you open a child case, the clipboard also contains the page pyWorkCover.

pyWorkCover contains the case data for the parent case.

The page enables you to copy data between the parent case and the child case
and confirm that any data mapped from the parent case to the child case is correct.

===================================================================================
===================================================================================
================
 ===============Validating data in Dev Studio=========================

Data validation and Dev Studio

In App Studio, you can configure validation conditions that perform a

true/false comparison to the value of one field against either a constant value or
the value of another field.

More complex validation scenarios might require additional capabilities

that are provided by validate rules in Dev Studio.

Consider the following scenarios, each of which requires behavior that

you can configure only in Dev Studio:

>When a Canadian customer submits their address, the postal code entry
must conform to the standard format for Canadian postal codes.
>When an investor opens an investment account, they complete a
questionnaire to determine their experience level.
Only
individuals with extensive investing experience can add margin trading to their
account.
>When a person enrolls in a healthcare plan, the applicant must upload
a consent form to allow disclosure of medical information to third parties.

Validate rules

Validate rules ensure that the data that your users provide meets the
conditions that a case requires in order to go forward.

By assigning validation rules to flow actions, you can prevent users

from entering information that your application cannot process and reduce the
number of processing errors.

In Dev Studio, you can extend validate rules that are created
automatically in App Studio.

You can also create new validate rules in the Process category.

Edit Validate rules

Edit validate rules are typically applied to properties, and consist of

Java code that compares the value of a property to a defined pattern.

Because of the potential to introduce custom Java into an application,

edit validate rules represent a potential security risk for your application

Edit validate rules are used for client-side validation, which means
that the value users enter is validated immediately without referencing the server.
 Validation occurs when users make a change to the entered value.

To apply an edit validate rule to a property, reference the edit

evaluate rule on the Advanced tab of the property rule form, in the Use validate
field.

===================================================================================
===================================================================================
=================

==========Setting default property values==========

Default values

When a user creates a case, you may want to set default values for
properties that are already known.
Setting default values can reduce the time users spend entering data.

In a development environment, setting default values can also be

useful.
When you iteratively run a process to test your changes, using a data
transform to enter default values in required fields saves time.

pyDefault and pySetFieldDefaults

Pega Platform™ provides two types of data transforms that are used to
automatically set default property values and page properties when you create a
case:
>pyDefault and
>pySetFieldDefaults.

Tip: As a best practice, use pySetFieldDefaults to set values for UI

fields, and use pyDefault for properties not referenced in the UI.

For example, configure pySetFieldDefaults to set the default value for

the Reservation date field on a view to reserve a rental vehicle
and configure pyDefault to set the default urgency
for assignments for the case type.

The first time you create a view for your case type, Pega Platform
creates the pyDefault and pySetFieldDefaults data transforms.

You can also create them manually. When a new case is created, the
pyDefault data transform is invoked by the pyStartCase process.

PyDefault then invokes the pySetFieldDefaults data transform.

Note: To reference the OperatorID data page, you must add an entry to
the Pages & Classes tab.

Superclass feature

Data transform superclass feature

Developers can make data transforms more modular by using a

superclass.

You can combine several data transforms using the superclass

feature to set values at multiple levels of the class hierarchy.

Taking advantage of this feature improves the maintainability of

data transforms.

When the superclass feature is enabled on data transforms, at

runtime, Pega Platform™:

>Identifies the parent of the current class

>Identifies the next level parent until the highest parent
class is located
>Finds the data transform
>Invokes data transforms

Pega Platform identifies the parent of the current class by using

standard rule resolution.

Rule resolution is as an algorithm built into Pega Platform that

identifies the correct rule to use at runtime,
based on factors such as ruleset, class
inheritance, and permissions.

After Pega Platform identifies a parent class, the system

continues to identify parent classes until it reaches the highest parent class.

After identifying the highest parent class, the system uses rule
resolution to find the data transform that has the same name as the current data
transform.

The data transform in the highest class is invoked first. The

data transform of the same name (if any) in the second-highest class is invoked
next, and so on.
The current data transform is
invoked last.

Configure the superclass feature for data transforms

To configure the superclass feature, from the Dev Studio workspace,

create a data transform with the same class name at each level
and ensure the Call superclass data transform option
is selected on the desired data transform.
 If properties are specified in both the parent and subclasses, the data
transform in the subclass overwrites the data transform in the parent class.

Pega Platform comes with standard pyDefault data transforms in the work
classes from which the case types inherit.

The standard Work- pyDefault data transform sets property values that
are used in all case types.

The properties include

work status,
work urgency, and
operator organization information.

Tip: You can override these default settings in the case type pyDefault
data transform.

For example, the Work- pyDefault work urgency value is set to 10.
If you want to prioritize cases in your
case type, you can change the default urgency value for all new cases to 40.

===================================================================================
===================================================================================
============================

================Accessing sourced data in a case=========

Data pages

On-demand data access

Case processing often requires access to data sourced from other

applications or systems.

Ensuring the accuracy of sourced data reduces the chance for errors —
and undesirable outcomes — for cases significantly.

In Pega Platform™ applications, a data page retrieves data from a

specified data source and caches that data in memory.

A data page manages the integration to the data source, separating

business processes from any integration details.

This separation allows application developers to use sourced data in an

application without knowing the data source and connection details.
 Due to the on-demand nature of data page content, data pages are
considered a type of declarative rule.

Pega Platform automatically prepends the characters D_ to the name of a

data page to differentiate the page from other pages in memory.

Note: Data pages created in versions of Pega Platform before 7.1 begin
with Declare_ instead of D_.

Data page definition

In Dev Studio, you can create data pages. When creating a data page, a
developer must provide four key pieces of information:

>The structure of the page contents.

>The object type represented by the contents of the data page.
>The edit mode supported by the page.
>The scope of the data page.

Structure

The structure of the page determines whether the data page can
contain one item or many items.

Set the structure of a data page by selecting an option from the

Structure drop-down list.

Consider a data page that contains pricing information for a

single stock. The structure is set to Page.

However, if a data page contains pricing information for all the

stocks in an investment portfolio, you set the structure to List.

Object type

The object type of the page identifies the information contained

by the data page.

To set the object type for a data page, enter the class of the
object in the Object type field. The object type allows the data page to reference
any property defined for the class

Edit mode

The edit mode of a data page indicates how — or if — an

application can manipulate the information on a data page.

Set the data page mode by selecting an option from the Mode drop-
down list.
 Set the edit mode to Read-Only to prevent an application from
updating the data page except when loading and updating the contents from the data
source.

Read-only mode prevents users from editing information sourced

from a system of record and ensures that the data page content always matches the
content loaded from the system of record.

Note: If a data page mode is Read-Only, the Clipboard tool lists

the data page in the Data Pages category.

Set the edit mode to Editable to allow an application to edit the

data page contents.

Note: If the data page mode is Editable, the Clipboard tool lists
the data page in the User Pages category.

Set the edit mode to Savable to configure a save plan that allows
the application to push the page contents back to the data source.

Scope

The scope of a data page determines the visibility of the page

contents within the application.

To set the page scope, select one of the supported options in the
Scope drop-down:
Thread,
Requestor, or
Node.

Data sources

Use the Data sources section of the data page form to specify how
Pega Platform populates the contents of a data page when an application references
the page.

To configure a data source, specify the type of the source and

the name of the data source.

You can use any of the following options to configure a data

source for a data page.

Data transform
Activity
Connector
Report definition
Database lookup
Robotic automation
Robotic desktop automation
 You must configure a data transform to map the response to the data
model for the case type or data type when:

Using a report definition to source a page structure

Using a lookup to source a list structure
Using a robotic automation
Using a robotic desktop automation

Data sourcing from multiple data sources

If you must combine data from multiple sources to populate a data page,
select the Aggregate sources option.
Then, identify each of the data sources to query. Pega Platform
populates the data page from the specified sources in the listed order.

Conditional data sourcing from a data source

A data page must specify at least one data source.

If a data page contains more than one source, configure a logical
condition for each source to test whether to query the data source.
The condition for the last listed data source is set to Otherwise to
ensure that Pega Platform always identifies the data source for the data page.

To use a parameterized data source, add an entry for the parameter on

the Parameters tab of the data page record.

Note: When users attempt to access a parameterized data page, Pega

Platform ignores any instance of the data page with a different value for the same
parameter.

Referencing data pages

When data needs referenced from a data page, a Query field type is
used.

While most data objects created by Integration Designer will not have a
key or the other needed data pages to create a reference relationship.

Query fields require either a list or lookup data page.

A Query field does not store any key values within itself, so any
parameters to the data page are external to the field.

Note: A Query does not require the parameter to be a field sourced

outside of the case.
It can have the parameter come from any field in the context of a
containing object or a field from an activity.

Refresh strategies for data pages

Stale data and data refresh

Out-of-date data — also referred to as stale data — can lead to bad

decisions, costly errors, and inefficient processes.

Keeping the contents of a data page current is critical for ensuring

accurate, desirable case outcomes.

The first time users access a data page, Pega Platform™ populates the
page with up-to-date information.

Subsequent users access the same cached data, even if the source data
changes.

To keep data pages current with changes in sourced data, configure a

refresh strategy to identify and limit stale data.

Note: The use of a refresh strategy is optional but strongly

recommended for data pages to prevent users from viewing and acting upon stale
data.

Refresh strategies

The refresh strategy for a data page defines one or more conditions for
testing whether the contents of a data page are considered stale and need to be
reloaded.

When a user accesses a data page, Pega Platform checks the refresh
conditions configured for the data page.

If a page meets at least one of the conditions, Pega Platform reloads

the page contents from the specified data source.

Note: Designing a data page refresh strategy requires balancing

processing effort against the chance that a data page contains stale data,
especially for a page with the scope set to Thread.

Always consult with project stakeholders to determine acceptable limits

on performance impacts and stale data before configuring a refresh strategy.

In a data page record, the Load management tab provides developers with
three options for configuring a refresh strategy for a read-only data page.

Reload once per interaction

The Reload once per interaction option updates the contents of the data
page each time a user accesses the page in memory.

This option is available only for pages with the scope set to Thread or
Requestor and cannot be combined with any other refresh option.

For example, travel reservation populates a data page with seating

information for the flight selected by a customer.

Select Reload once per interaction to update the data page every time
the customer accesses the page, to ensure that the seating information is as
current as possible.

Reload if older than

The Reload if older than option uses a fixed interval of time to

determine whether a data page is stale.

After the interval ends, the data page contents are considered stale,
and the next attempt to access the data page causes Pega Platform to update the
data page.

Tip: Consider the frequency of data changes to design a refresh

strategy that minimizes the processing burden due to reloading data pages.

Pega Platform never refreshes a data page more than one time per
interaction, regardless of how the data page refresh options are configured.

Page autopopulation

Data access options

To autopopulate pages with data, Pega Platform™ provides you with the
option to refer to or copy data that is stored in another system or application.

The option you choose impacts the storage and refreshing of data in a
case.

Refer to a data page

Refer to the data page when you always need the most current data from
an external system or application.

Use this option to ensure that the data displayed in the Pega Platform
application is up to date.

The data reloads according to the refresh strategy specified on the data
page. The property (page or page list) always points to the current version of the
data page.

Whenever a data page parameter is updated, a new data page is created. The
property then points to the new page.
 Copy data from a data page

Copy data from the data page to a case when you need data from a
specific point in time.

Once you copy the data to the case, the data is not retrieved from the
source again unless the request parameters change.

Data access in UI controls

When you populate a list with data from a data page, only the
selected value is copied to the data model of a case.

The value copied to the case does not need to match the value
displayed in the list.

When you populate a list with data from a data page, the items in
the list update according to the refresh strategy specified on the data page.

If the data page accepts a parameter, Pega Platform™ creates a

data page instance each time the parameter changes, updating the list contents.

===================================================================================
===================================================================================
================

==========Saving data to a system of record ================

Savable data pages

You can use savable data pages to save a page or page list of data
specified in a data page back to its system of record (SOR) regardless of whether
the SOR is Pega Platform™ or another system like an external database.

By using a savable data page, you can configure an application to

update the SOR in real-time with case data. The savable data page can manage the
transaction to ensure that
both systems remain
synchronized even if an error, such as a network outage, occurs.

Data save plan

The data save plan for a savable data page details how saves are
performed.
 You specify the data save plan in the data save options section
of the savable data page.

You can specify multiple save options, where each save option is
associated with a when rule that determines when that save option is used.

The data save options include:

Database save,
Activity,
Connector,
Robotic automation, and
Robotic desktop automation.

Note: When you want to commit to multiple data tables at a time, you
can use when conditions in the data save plan.

Whenever the when condition evaluates to true, then the data commit is
performed.

If all the When conditions evaluate to false, then the Otherwise

condition is executed.

Database save
The Database save option saves a single page of data to a single
database row in the configured system of record.
You can configure a data transform to source the information to write
back to the system of record.
How the data page applies changes to the data is dependent on the data
access settings on the property holding the data.
This option maintains transactionality within the save operation when
the data is saved.
The Database save option is available for data pages with a page
structure only.

Connector
The Connector option saves and persists data to an external SOR by
using a REST connector.
Only REST connectors are allowed for use in a save plan. Other
connector types, such as SOAP, cannot be used in a save plan.

Robotic automation
The Robotic automation option uses a Robotic Process Automation (RPA)
to write data to an external system of record.

Robotic desktop automation

The Robotic desktop automation option uses a Robotic Desktop Automation
(RDA) to write data to an external system of record.

Activity
 The Activity option calls an activity to save the data.
You can use this option to access a connector for pages managed by an
external SOR or for a local save to the Pega Platform database.
You can use any supported integration connector option.
Unlike the Database save option, the Activity option does not guarantee
transactionality.

Note: Limit the use of activities when possible.

You can trigger the save plan for a savable data page in one of three ways.

>Add a Save data page automation step in a flow rule.

>Add post-processing for a flow action rule.
>Call the Save-DataPage method in an activity rule.

When triggering the save from a flow or a flow action, Pega Platform
automatically manages the transaction.

If you trigger the save from an activity rule, you can choose whether to save
the data in conjunction with the rest of the transaction or independently as a
separate transaction.

The following save plans are available:

Database save – Use this option to save data to the system of record.

Connector – Use this option to save and persist data.

Activity – Use this option to create logic to persist data to any

system, using any supported integration connector option, for example, REST, SOAP,
and so on.

Robotic automation, and Robotic desktop automation – If you use robotic

automation or robotic desktop automation,
use these options to source your data page when you want to write
updated data back to an external system of record,
or for when you need to use robotics to meet other business needs.