A flow describes a business process. One representation of a flow is a network of shapes and connectors (directed arrows), each with associated parameters and values. Flows govern:

• How work items are created
• How they progress through one or more flow executions
• How they become resolved (completed)

Flows are the fundamental rule instances that represent business processes, identifying who works on a work item in what sequence, what decisions and processing occur automatically, and many other aspects of the business process.
Some applications don't require users to interact with user forms. Flows that implement straight-through-processing operate without user input. External portals and systems can execute flows through Active Server Pages, JavaServer Pages, Service Portlet or Service JSR94 rules, or other means. Informally, these are known as "headless" BPM applications. A collection of standard activities, flows, and flow actions known as the Process API simplifies building such applications.

Runtime processing — The simple case
​
At runtime, a user can start the execution of a flow by entering a new work item. The system examines the property pyFlowName, in the data transform instance for the class, to determine which flow to start. The flow operates on the work item to advance it through the business process that the flow implements, performing automated steps automatically, or creating assignments for users as appropriate.
You can think of a work item as located "on" one shape or arrow of the flow at any one instant, until the work item becomes resolved or the flow ends. Alternatively, you can think of the flow operating on the data (properties) in the work item until the flow finishes or the work item becomes resolved. Both points of view are correct.
A flow may define many optional detours, side trips, and branches reflecting decisions reached along the way. The path that one work item follows through the flow depends on its own requirements, automatic decisions in rules (such as decision trees and map values) and on available resources. For example:

• One mortgage application that fails to meet the automatic credit approval rules may require special research, while others are handled automatically
• An arriving customer service call in Mary’s territory may be routed to Tom if Mary is unavailable
• A request that is in a foreign language may be routed to a manager who can decide who among his or her team is best qualified to handle the request. Normal requests, not in a foreign language, may be routed automatically based on a round-robin algorithm.
• The system can randomly select one work item out of every hundred for a quality review.

As a flow executes, the following processing often occurs:

• The system generates a unique work item ID for a new work item. (This occurs for starter flows, those for which the Creates a new work item? box on the Flow form is selected.)
• As needed, it creates assignments for human users reflecting the need for more facts, makes judgments, and places the assignment into an appropriate user worklist or workbasket. After a user (or in some cases an agent or external participant) performs an assignment, the work item progresses farther through the flow.
• The system automatically makes decisions, urgency calculations, and gathers data automatically from many sources including outside systems.
• Rules promote compliance with service level goals, and alerts management or raises the urgency value when processing does not meet these goals. This is known as escalation.
• Processing of the flow ends when an End shape is reached. The work item may or may not be resolved at that point.

Types of flows

• A flow that contains no assignments, and so can execute from start to end without human input, is known as a straight-through process.
• A flow that consists only of assignments or decisions and meets other criteria is known as a screen flow.
• A flow that creates a new work item is called a starter flow.
• A flow that is called by another flow is known as a subprocess; the calling flow is called a parent flow. Processing of a subprocess is synchronous, meaning that the calling flow execution pauses for the duration of the subprocess. When the subprocess execution reaches an End shape, the calling flow can continue (if additional shapes are present). See Flow form — Editing with Process Modeler — Editing the Subprocess shape properties.

Parallel processing with Split Join

In some business processes, the order of certain steps is not important as long as all the steps get done. In other situations, a step can be considered complete when either of two other steps finishes.
The Split Join facility ( or ) supports such asynchronous operation, by allowing processing of two or more subprocesses to proceed in parallel. For example, a contract may need approval of both a legal reviewer and a purchasing department reviewer, but order is not important. In the 1980's era of paper forms and in-boxes, only one of these two has the paper — artificial sequencing. With a work-object and a flow that uses Split Join, each subprocess can create an assignment, and the two reviewers can proceed independently.
See Flow form — Editing in Process Modeler — Split Join shape properties
Split Join parallel processing occurs only when considered at the business process level. Although two assignments exist, they both belong to a single work item. During the minutes or seconds that either user performs the assignment (thus updating the work item), the system locks the work item, and the work item is not available to the other user.
Similarly, at a more atomic level, if the two users both access a single-node PRPC system that has a single JVM and single CPU chip, no parallel processing occurs at the Java thread level, even when the two users work on different work items.

Parallel processing with Split For Each
The Split For Each facility () causes multiple subprocesses to start, one for each page of a Page List property. Processing can resume after any one, or all, of the subprocesses end.
See Flow form — Process Modeler — Editing a Split For Each shape.

Parallel processing with Spinoff
A Spinoff shape starts asynchronous execution of a different flow, on the same work item or a different work item. Processing of the current flow does not pause or wait for results from the other flow.
To create a spinoff, use a Subprocess shape (). Select the Spinoff Flow checkbox. See Flow form — Editing with Process Modeler — Editing the Subprocess shape properties.
​
Parallel processing with Start a New Process and flow actions
PRPC offers ways for a flow execution to be started for an existing (open) work item. These are alternatives to calling a subprocess, using a Split Join shape, or using a Split for Each shape:

• Users can access an open work item in update mode, click the  Start a new process   button, and choose a second flow to start. This button is available on most Update user forms. Users may be prompted to enter flow parameters to complete the operation. The  Start a new process   button lists all the eligible flows with the Can be added to a work item? box selected on the Flow form. (To include this button on a user form, reference the standard section Work-.Flows in a harness.)
• Users can select the standard flow action Work-.AddFlow, Work-.AddCovered, or Work-.AddtoCover to start a new flow execution.

Data structure for flow executions

Several system-maintained properties in a work item record the current state of flow executions in process. For example, the integer property @baseclass.pxFlowCount indicates how many flow executions are in process for the work item.
The Page Group property @baseclass.pxFlow contains a page of facts about each execution:

• pyFlowType — Second key part of the flow
• pxAssignmentKey — Key of the current assignment instance for this flow execution. typically an instances of the Assign-Workbasket or Assign-Worklist class.
• pyLastFlowStep — Internal name of the most recent shape or connector processed
• pyNextFlowStep — Internal name of the next shape or connector to be processed
• pyFlowParameters — A classless page containing parameters used to start this flow

Based on HTML and XML standards, PRPC can support a wide range of user interaction facilities and approaches. Your application's user interface can take into account the environment, the domain knowledge of your users, their skills, locale, and language.
The appearance, branding, and interaction dynamics of your user interface can match the context and language that is natural to your application's users.
Evolving an application's user interface is best done by designers and developers who have both application domain knowledge and usability skills.
​
Producing HTML displays and forms

PRPC includes standard facilities for those workers and managers who use PRPC-based applications throughout the workday. These facilities support:

• Entry of new cases
• System-maintained worklists of assignments sorted by decreasing urgency
• Finding, reviewing, updating, and performing assignments

Sophisticated and powerful standard forms known as harnesses are designed for reuse and customization.

Defining user input forms and displays

​For access through the standard portal, PRPC uses harnesses (Rule-HTML-Harness rule type) for work items. Six other rules support the presentation of work items:

• Sections define the contents, appearance, and behavior of portions of harness forms.
• Fragments contain reusable HTML text elements not dependent on a class.
• Control rules determine the appearance of a single property on an HTML input form or display.
• Text File rules, which can define static aspects of your user interface such as Cascading Style Sheets or JavaScripts.
• Binary File rules, which identify images such as JPG or GIF files.

​
The HTML text you enter into HTML rules is known as source HTML. It contains ordinary HTML code plus JSP tags or directives — server-side instructions that PRPC evaluates at runtime to compose the final HTML it sends to the HTTP server (and ultimately to a user's browser session). Known as stream processing, this evaluation accesses the clipboard for text values to insert into the output HTML, incorporates the text of other HTML rules, provides conditional if-then-else testing, and looping through arrays.

Harness forms use the pega:include JSP tag to incorporate multiple sections, which in turn use standard styles and fragments to present properties, labels, and images. For your application, you can copy and tailor parts of these forms as necessary, while inheriting the standard parts.

Tools
​These tools support your evolution of the user interface of your applications:

• Harnesses preview and the Application Explorer — Allow you to interactively revise the content and the layout of a user form or flow action form
• UI Gallery — Presents working examples of controls and user interface features
• UI Inspector — View UI structure for elements in your development environment or application
• UI Tree — View and interact with the hierarchy of page artifacts in a developer environment or in an application at runtime
• Image Library landing page tab — Helps you find and identify the name of images that are available as binary file references
• Clipboard tool — Shows the current property values in internal format

Through open authoring, you can use an HTML editor of your choice to revise HTML text.
When a user submits an HTML form, PRPC records the values entered into input fields as property values on the clipboard. The values that users enter may not be in the format required by the property definition, or may not pass validation tests.