types of rules in pegaRULE or Pega Platform :-

Application rules: These rules define the overall settings and behavior of the
application.

Data model rules: These rules define the structure and properties of data objects
in the application.

User interface rules: These rules define the layout and behavior of the user
interface for the application.

Workflow rules: These rules define the flow and routing of work items in the
application.

Integration rules: These rules define how the application integrates with other
systems.

Security rules: These rules define the access and security controls for the
application.

A Pega Platform™ provides four role-based authoring workspaces, referred to as

studios.
Each workspace provides specific tools and features for application development. By
using the appropriate workspace,
team members complete tasks by using tools that align with their expertise. A work
object is the primary unit of work completion in an application, and the primary
collection of data that a flow operates on.
Workers using an application create, update, and eventually resolve and close work
objects. A Case is a group of stages , where we configure and understand, how the
lifecycle of a casetype(instance of case) goes.
Within each stage, a case goes progresses through some required and optional
processes.
Work object is an instance of a Case. When you execute or run a Case, you create a
Work object. Blob (Binary Large Object) is a data type that stores binary data.
It is typically an image, audio or other multimedia object that therefore often
requires significantly more space
than most other data types such as integers, characters, and strings. These are
classified as unstructured data. In pega we cannot start any rules, object,
properties with the prefix px, py and pz, as they are reserved keys.
For operator we have class Data_admin-Operator-ID.
pzpvstream stores all the details of work object in binary.
pzinskey is the primary key in the database.
There are two types of classes in pega: Concrete and Abstract.
    Concrete: Concrete classes can be instansiated and are always associated with a
database.
    Abstract: Abstract classes cannot be instansiated and are not associated with
any databases. Pega Platform Role-based authoring workspaces: App Studio: A low-
code workspace designed for business architects, citizen developers and system
architects.
Dev Studio: A low-code workspace with advanced configuration options for technical
team members as well as system architects.
Prediction Studio: An analytics workspace used by data scientists and business
decision-makers.
Admin Studio: A software administration workspace managed by IT staff for system
administration. Each studio consists of three areas: A header
A navigation pane
A workspace APP STUDIO:
The App Studio workspace helps you visualize the key factors of the desired
business process.
As you outline the process, you build relationships between stages of the process,
participating personas, communication channels,
and data required for process resolution. The visual model built in App Studio
helps you plan and manage your development team's workload. The App Studio overview
displays an Application layers widget, which provides a visual representation of
the rules that make up your application.
Hovering your pointer over a layer title or graphic highlights the rules that the
layer contributes to the application. Pega Platform applications comprise
instructions, called rules, that govern application behavior,
just as the rules of chess govern the behavior of various pieces. The rules that
make up an application are organized into layers for reuse
between applications. The Application layers widget also identifies the Pega
Platform application type. Pega Platform offers two out-of-the-box (OOTB)
application types: Theme Cosmos - Theme Cosmos uses the Cosmos Rules ruleset to
build applications on the traditional, section-based user-interface (UI)
architecture. 
Constellation - Constellation uses the Cosmos React ruleset to build applications
on the new view-based UI architecture.
The example and challenge applications in the Low-Code App Builder mission are
built on the Constellation architecture. A Microjourney is a small part of the
overall customer journey and focuses on accomplishing a specific goal. Personas
determine who interacts with the application. Personas align the application user's
specific needs with the desired business outcomes.
Channels determine how a persona interacts with the application. For example, a
persona is a customer or a company employee, and a channel is a
web portal or a chatbot. An application can have multiple personas and multiple
channels. Data is the information that the Microjourney interacts with to
accomplish the customer's goal, and the interface defines where the data comes from
or where it is persisted. An application can interact with multiple types of data,
and data can employ multiple interfaces. A case type is an abstract model of a
business transaction. Case types model repeatable business transactions. A case is
a specific transaction instance. To model the online order transaction in Pega
Platform, you define an online order case type that advances from submission to
processing and then delivery You define the case life cycle for a case type to help
you visualize the work that must be completed as part of the desired business
transaction. The case life cycle represents the business model of the
Microjourney™. The case life cycle models the path your case follows to resolution.
The major building blocks of the case life cycle are stages, processes, and steps.
An abstract model of a business transaction is a case type, while a case represents
work that delivers a meaningful outcome.
Stages are the first level of organizing your work in a case.
Processes contain a series of steps or tasks.
A step is an action or task performed by the system or users. Case life cycle
design modeling technique: This model enables business users to see and interact
with a case the same way that they think about it. Each case life cycle contains
stages, processes, and steps. 

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.
Topics covered Yesterday: FLOWS ARE TWO TYPES:
SCREEN FLOW AND PROCESS FLOW VIEW IN APP STUDIO
SLA

Service Level Agreement (SLA) rules are used to define and manage the performance
targets for specific processes within an application. These targets are used to
measure the performance of the process and to identify any areas that need
improvement.

Start: This is the point at which the service level timer starts ticking. It all
starts at the zeroth hour.
Goal: Its purpose is to specify how long the assignments should take. This step is
counted from the start of the assignment or case.
Deadline: The term "deadline" refers to the amount of time a case or process can
take before it is considered late. It is calculated from the start of the
assignment or case.
Passed Deadline: When the assignment or case has passed the deadline, the term
"passed deadline" is used to indicate when further action should be taken. It
calculates the amount of time that has elapsed since an assignment's deadline.

OPERATOR

an operator is a user who has been assigned specific responsibilities and

permissions within the application. Operators are typically responsible for
performing specific tasks or handling specific types of cases within the
application. They can be assigned different roles and access levels depending on
their responsibilities.

Operators can also be assigned specific roles, such as case worker, manager, or
administrator, which determine the tasks and actions that they are able to perform
within the application.

check out check in:

Check Out/Check In feature in Pega helps to manage and control access to rules by
providing a way to lock rules for editing, prevent conflicts, and keep track of
changes to the rules. It also helps to maintain version history of the rules and
helps to rollback changes if required.

A checkout is a private copy of a Rule- instance that you update and later check in
to replace a base rule version. All checked out rules reside in a ruleset that is
only visible to your operator known as your personal ruleset.
pxobjclass is the instance of the class.
in operator security tab there is a option check out. we have to click this option.
in rule set

Another ans to the last question sir asked: When you create a case type in App
Studio, by default all processes you configure are created in draft mode. Draft
mode allows you to quickly run the case type to check the run-time behavior even
with incomplete configurations.

rule-obj-property created when you give property like name

work
data
int class
ui class
attaching pdf file to the case

server site validation

client site validation

edit validate

in valdiation section we need to edit the condition

multiple relation will be there
flow action -> action->action buttons
can editable

pzdesigntemplete2clumn

design templete region name should be there

covert selction to use a design templete

control pxEmail

server site validation we will not write any validationS

use validate call after removing from the property and it will called by sever side

select a function validation [proparty]

data transfer
declear expression
go to app expoler

create

data model

Data transform
declare expression
flow
flow action
section
property
operator
access group
edit validate
obj validate

check ps /obj class for all the topics

pdf, automation, email, wait