Summary
Use a data transform (known before PRPC 6.2 as a "model rule") to define how to take source data values — data that is in one format and class — and turn them into data of another format and class (the "destination" or "target").

What a data transform does
​Generally speaking, a data transform defines how to take source data values — data that is in one format — and transform them into data of another format (the "destination" or "target"). In PRPC, you can use a data transform to:

• Normalize data for use with a data page.
• Define, copy, or map data with activities.
  • Copying a clipboard page to make a new page.
  • Mapping properties (and their values) on one page to another, existing page.
  • Mapping properties (and their values) on one page to a new page.
  • On a given clipboard page, defining one or more initial properties on that page and setting their values. A data transform can set many property values on a page in one processing step.
  • Appending pages from one Page List property to another.

Using a data transform speeds development and is easier to maintain than setting property values with an activity, because the data transform form and actions are easier to understand than the activity form and methods, especially when the activity includes custom Java code. We recommend using data transforms instead of activities for normalizing and delivering your application data.

A data transform is a structured sequence of actions. When the system invokes the data transform, it invokes each action in turn, following the sequence defined in the data transform's record form.

The Data Transform record form
​On the data transform's Definition tab, the actions to be taken are presented as a sequence of rows in a tree grid. Except for the conditional types of actions (such as When, For Each Page In, and similar actions) and transitional actions (such as Exit For Eachand similar actions), the system invokes each row in sequence, starting with the first row.
In the example below, the data transform CopyShippingInformationToBilling maps data from the shipping information for an order to the order's billing information.

​ColumnDescriptionActionAn action to be taken. 
TargetA target, if the action requires a target.
RelationA relation, if the action requires a relation to be specified. This relation is a relationship between the specified target and source.
SourceA source, if the action requires a source.

In this post, i would introduce in brief as to what Pega’s CPM framework is about.
Pega Customer Process Manager (CPM) is one of the products in Pega’s CRM suite of solutions. This framework is primarily to guide Customer service representatives (CSRs) in processing customer service inquires and requests from initiation through resolution. In effect, it helps CSR’s to view complete information about the customer in a single view, take customer queries and initiate a workflow process to resolve them. These customer queries are known as ‘service intents’ in pega parlance. 
There are few terminology used in CPM framework that you should be aware of –
1. Composite – this is the area where you view the 360 degree of the customer. Pega’s integration services are used to connect with external systems to retrieve information and thereby shown in separate sections in the composite area
2. Service intents – these are the customer inquiries that i mentioned of. In an OOTB CPM framework, you would see the following service intents. 

The usual flow is that when a customer calls up a CSR, the CSR would ask for his account information, that could be the customer ID, etc. Post this, the CSR would verify the identity of that person by asking few questions. On successful verification, the CSR sees the complete information of the customer. This is to help the CSR view what are the previous complaints, or queries, or services that were requested by the customer. In the above table, within account category, a customer could request for address change. The CSR would launch this service and complete the request.
3. Dialog scripts – The intention of dialogs is to assist CSR in the flow. Basically, these are nothing but scripts that appear along the interaction with the customer. For example – when a customer calls the CSR, the system will show up a dialog saying ‘Hello Mr. XXX, How can i help you today?’ 
Few screenshots to drive the story –

Pega 7 provides two case locking options and capabilities. You make your basic configurations in the Case Designer at the top-level case type. The settings cascade to all the subcase types.

• Default locking – When a case is opened in a Perform harness, it and its parent case are locked. Only one user can view and update the case at a time. You can override the default behavior at the each subcase type level.
• Optimistic locking​ – Multiple users can open a case in a Perform harness at the same time to review or update it. The first user to submit an update "wins;" users who had updated the form but had not submitted changes must refresh the form, re-enter their updates, then submit them.

This article describes how these locking strategies work and how you configure them in the Case Designer.

Approach
To begin, open a top-level case type in the Cases Explorer and open the Details tab. On the Locking option, click the Edit link.

Default Locking
​
Sets to standard locking behavior; the system locks a case when it is opened by a user for a period of up to 30 minutes. No other user can open or work on it. You can change the standard time period in the Custom timeout field.
This conservative approach helps ensure that data can be updated in both parent and subcases with transaction integrity. For example, the parent case may contain properties that count or total values in the subcase. Locking both at once helps keep these counts or totals in sync.
Overriding default lockingIf default locking hampers user throughput in your application, you can override the setting at the subcase level. This lets users concurrently make updates to both parent cases and their subcases without conflict.

To override default locking:

1. Open the subcase type in the Case Designer's Details tab.
2. Open the Locking pop-up dialog.
3. Select the Do not lock the parent case when the child case is being performed checkbox and click the Save button.

Optimistic lockingThe top-level case and all of its subcases can be opened in a Perform user form by multiple users for reviews or updates. This setting applies to all subcases and cannot be overriden at the individual casetype level.

When the first user submits or saves an update, other users who have also opened the case and attempt to submit their updates receive a message indicating that the original form and its data have already been updated; therefore, they cannot submit their updates. In these situations, users can:

• Close their case without submitting the changes.
• Refresh the form to see the other user's updates before submitting their own updates. Users cannot commit changes without using the review option.

Considerations
​In most configurations, use default locking in order to preserve transaction integrity among cases. Optimistic locking may be called for where multiple users need only open and review cases without having to perform updates.

• If it is likely that a multiple users will attempt updates to cases in one or more case types, frequent update conflicts will likely not be desirable.
• Agents and services such as SLAs and bulk actions can update a case that is being worked by an operator. When the user attempts to save work, the update will fail.
• It is possible to create a condition that accepts updates from two operators at same time, although one user's work will not be committed. Audit trail entries for both updates may be present and might actually interleave.
• If a subcase update attempts to update its parent, the system briefly locks the parent to effect the update. If the parent is locked, the updates are queued until a lock can be obtained.

Use the Queue instruction to start asynchronous execution of a second activity. This provides an alternative to the Call instruction, in situations where there is no need to wait for completion of the second activity, or where processing in parallel is feasible and beneficial

BRANCH -- Branching to another activity.Use the Branch instruction to cause the current activity to find another specified activity and branch to it without a return.When the branched activity ends, processing of the current activity ends also; no steps after the Branch step are executed.CALL -- Calling another activity
COLLECT -- Begin execution of a collection rule 
FLOW-NEW -- Start a flow execution
JAVA -- Using Java in an activity step
QUEUE -- Execute another activity asynchronously
RULE -- Using the Rule instruction to implement a custom rule type(Rule instruction is deprecated)

Note:  Rule instruction is deprecated. Instead, call the evaluate Rule activityUse the Rule instruction to cause the current activity to find another activity named evaluateRule that implements a custom rule type. When this instruction executes, control transfers to that activity.

​Project delivery

• You can now create and associate specifications with steps and user forms when you design a case in Case Designer.
• Use the new Document Application tool to generate application profile documents, application documents, and specification documents.
• The Document Application tool captures screenshots server-side for application documents, rather than using an Internet Explorer client-side process. During installation or upgrade to Pega 7.2, your system administrator must enable server-side screen capture.
• To address Google Chrome ending support for NPAPI plug-ins, Chrome users will now upload a Word document as a specification description or export a specification description to Word, instead of using the Silverlight plug-in to create or edit a specification description in Word. Non-Chrome users are unaffected.

The PDN provides overview articles, best-practice solutions to common development challenges, news of the latest product features, access to the latest version of the product help documentation, and many more learning resources.

Learn from the experts. Pega Academycourses provide design and implementation best practices that cover Pega 7 Platformapplication development as well as specialized topics.
Pega Academy courses provide the knowledge and hands-on experience that you need to successfully design and deploy Pega 7 Platformsolutions.
These courses also prepare you to become a Pega Certified Professional.
User interface

• Skin inheritance allows you to create a base skin from which subsequent dependent skins can inherit styles and mixins. A skin can support any number of nested skins. The skin rule form now includes an Inheritance tab where inherited formats can be included or overridden.
• Repeating Dynamic Layouts display large non-tabular paginated lists without incurring the cost of loading it all onto the browser. Pagination is configured in the cell properties of the repeating dynamic layout.
• All components that display headers include a configurable heading level. The heading generates semantic markup and makes the user interface accessible to assistive technologies. The skin includes a Base settings tab to provide heading level styling. Existing container formats are backward compatible.
• You can open a rule properties tab by using Live UI and enable run-time editing by using a Enable live editing link, which creates a run-time branch of the application rule.

• You can configure the Date control to show only past dates, only future dates, or any date range that includes the current year.

• Accessibility improvements include assistive technology announcements for wait indicator status, overlays, and layouts. Improved keyboard navigation provides the ability to dismiss overlays by pressing the Esc key and to expand and collapse layouts by pressing the Tab key.

Case management

• Create simple case types that you can gradually extend with a data model, stages, processes, and steps.
• Reuse flows and user actions in a process to save time.
• Use assignments and smart shapes in Case Designer to quickly build processes.
• Implement single or cascading approval techniques to enforce your business policies.
• Create and associate specifications with steps and user forms when you design a case in Case Designer.
• Add validation to fields on a form to define the expected value for user input.
• Calculate the value of a field by referencing numeric fields in repeating field groups.
• Customize Pulse or build your own gadget to collaborate with your team, add tags to posts, and reference other users.
• Configure team settings for case routing and approval, and define user profiles for your team.

Designer Studio

• Delegate correspondences, map values, and circumstanced versions of supported items that you can delegate.
• Define relevant records, which are a collection of properties, flows, flow actions, or sections, that are most likely to be reused for a case or data type, to your contextual class.

Project delivery

• You can now create and associate specifications with steps and user forms when you design a case in Case Designer.
• Use the new Document Application tool to generate application profile documents, application documents, and specification documents.
• The Document Application tool captures screenshots server-side for application documents, rather than using an Internet Explorer client-side process. During installation or upgrade to Pega 7.2, your system administrator must enable server-side screen capture.
• To address Google Chrome ending support for NPAPI plug-ins, Chrome users will now upload a Word document as a specification description or export a specification description to Word, instead of using the Silverlight plug-in to create or edit a specification description in Word. Non-Chrome users are unaffected.

Decision management

• Learn about the functionality of the Predictive Analytics Director (PAD) portal.
• Create Proposition Filter rule instances to define the validity, eligibility, and relevancy criteria for a set of strategy results, based on the proposition data and customer properties.
• Create, test, and implement revisions with the customizable, stage-based Revision Management process.
• Convert legacy batch run simulations into data flows and data sets.
• Execute and monitor runs of batch and real time data flows through the DataFlow-Execute method.
• Configure pre- and post-activities for the runs of batch and real-time data flows.
• Configure, train, and analyze text analytics models for sentiment or classification analysis of various types of text units.
• Identify sentiment-bearing terms with the granular, color-coded sentiment analysis in the Free Text Model rule form.
• Configure the advanced settings for language detection, checking spelling, and classification or sentiment analysis in the Free Text Model rule form.

Decision management

• Perform bulk operations on the Adaptive Models Managementlanding page and in the Adaptive Model rule.
• Estimate the memory that the Adaptive Decision Manager (ADM) system needs to accommodate the models that use the adaptive model configuration.
• Test decisioning strategies by using the updated Single case and Batch case test runs.
• Launch Visual Business Director (VBD) that is embedded in the Pega 7 Platform. Use the VBD HTML client on the Chrome web browser.
• Browse Interaction History data set by Subject ID or Group ID.
• Configure HBase data set and do the mapping without referencing any connector.
• Use advanced configuration options for the Hadoop host configuration.

Mobility

• The Offline configuration landing page is now available.
• The contents of the Mobile tab of the Application rule form have been redesigned.
• The Signature Capture control has been enhanced. Post-processing can be performed after entering a signature. You can also apply a signature to a page instead of an attachment. See Adding a Signature Capture control for more details.

Pega Mobile is an add-on product for PRPC 6.2 SP2 and later releases, offering mobile device users the capability to participate, collaborate, and monitor PRPC work from most major mobile devices, including tablets, phones, and iPods.

Access
Access your application on a mobile device using a WebKit-based browser and the same URL and login as the desktop version of an application. You can also access the application using the free Pega Mobile app, available at on-line app stores, which delivers your PRPC application to your mobile device while giving you convenient access to native device features, such as the camera. The app also allows you to save multiple application configurations, including URLs, logins, and passwords.

Portal and navigation
The Pega-Mobile RuleSet delivers an extensible portal, based closely on the Case Manager portal, that provides mobile device users with access to the PRPC application. Customizable navigation rules define how users move about the application. Navigation is controlled by main and toolbar navigation rules, and the list of items, actions, labels, and icons is completely configurable. You can even prevent display of navigation rules on phones and tablets.

Layouts and controls
Use a set of layouts and controls that are supported for use in sections and harnesses that render on mobile devices. Over 100 PRPC controls are mapped to mobile versions of those controls to facilitate the mobile rendering of existing applications.

Specialization and circumstancing
Most existing harnesses and sections render on mobile devices with no additional work. However, if your application includes features not yet optimized for mobile devices, you may create a specialized version of the section rule that includes features that are optimized for mobile devices.
You can also circumstance your entire UI experience based on the device type. Use Save As to save the portal rule to a new name, and for the circumstance, enter property pxRequestor.PxDeviceTypeand the value phoneor tablet. When you log in using this portal, the application determines the User Agent, and displays the portal, sections, harnesses, and flow actions with a user interface for the specified device type.

Testing and debugging
To test and debug your mobile application, use a physical mobile device when possible. Additionally, configure Apple's Safari or Google's Chrome with a specific User Agent, such as iPad or iPhone, so that you can run the mobile application on your desktop as it would appear on the tablet or phone device. The Mobile Clipboard is useful for examining property values, rule types, and identifying the Remote Tracer Session ID.

Other resourcesThese PDN articles are relevant:

• About Pega Mobile
• How to create a mobile portal
• How to configure section rules for a mobile device
• How to configure navigation for a mobile portal
• Pega Mobile — Frequently Asked Questions
• Testing and debugging a mobile application
• How to specialize your user interface for mobile devices
• Matrix of supported browsers and devices for Pega Mobile
• Installing Pega Mobile
• How to access your mobile application
• How to take and attach a photo with Pega Mobile
• How to use mobile geographic controls
• Guardrails for developing mobile applications
• Configuring the color scheme of your Pega Mobile application
• How to localize your Pega Mobile application
• Button and link controls in Pega Mobile applications
• Customizing button and link controls in Pega Mobile applications
• Create an image navigation grid in a Pega Mobile application
• Create a map of assignments for Pega Mobile users
• View Pega Mobile features and configurations in the Mobile Gallery
• Signature capture with Pega Mobile
• Inspect your Pega Mobile application with the Mobile Clipboard
• Configure QR/Barcode Scanning from your Pega Mobile application
• Display a read-only navigation rule using the MenuBar control in your Pega Mobile application
• Create a badge for item counts on the toolbar navigation menu in your Pega Mobile application
• Maximize screen space on small mobile devices
• Adding custom JavaScript and HTML headers to your Pega Mobile application
• Pega Mobile Mashup and Pega Mobile SnapStart
• Query String Construction in Pega Mobile Mashup

Note: If your application was developed in 6.2SP2 and uses RuleSets ending in _mobile, and you want to operate in ABA mode for best performance, note that _mobile RuleSets appear higher in the RuleSet list in ABA mode than in rules assembly mode. While it is unlikely that this change affects results of your application, some analysis and testing is recommended.

Project Delivery

• Add attachments to requirements using the Application Profilelanding page or Requirement rule form.
• Use the Application Document Wizard to generate project artifacts. Generated documents now include: embedded ERDs, an interactive Stages and Processes diagram, and all flows without restrictions.

  
User Interface

• Single Document Dynamic Containers are now created with frames disabled by default.
• Read-only fields can be marked as an email, URL, or phone numberin the Read-Only Format settings.
• Column Properties include the ability to add a property for sorting and filtering a column that contains a section include.
• Column headings can now be aligned with the column data.
• Improvements to dynamic layouts let you specify refresh conditions and use natural label widths.
• The UI Kit ruleset allows you to build or customize responsive user interfaces with rules and skins based on the latest standard Pega UI.
• Customizable modal templates can be used wherever a modal dialog is launched.
• Stacked layout group lets you stack items in a customizable, responsive format.
• The X-UA-Compatibility meta tag setting can be specified on harnesses to override IE Compatibility View setting.

Reporting

• Reduce the load on the main database by running reports against the alternate database. The control is on the Data Access tab of the Report Definition.

  
Integration

• When you create a REST integration, you can create a data page (and its related data type and data transforms) at the same time. The data page uses the integration as one of its sources.
• Give your users the convenience of single sign-on authenticationwith SAML 2.0.

  
System Management

• PRServlet is no longer required in a URL when accessing PRPC. A URL formerly written like this:

http://example.com/prweb/PRServlet?[QueryString]Can instead be written like this:
http://example.com/prweb/?[QueryString]

Most applications require access to data or computations that are provided by another system, or need to respond to requests from other systems for data or computations.
PRPC offers many approaches, technologies, and facilities collectively known as Integration. (Internally, these facilities are in the Pega-IntSvcs RuleSet.) They include:

• Connector capabilities, which allow your application (in the role of client), to request data or services from another system (in the role of server)
• Service capabilities, which allow your application (as a server) to respond to requests it receives from another system (a client).

Like most other facilities, these are rule-based, allowing evolutionary development. Many types of integration can be achieved quickly, with modest development effort.

​ConnectorsRule types provide direct support for these protocols and technologies:

• ATOM syndicated feeds — About Connect ATOM rules
• BPEL — About Connect BPEL rules
• Content management systems — About Connect CMIS rules
• Microsoft .Net — About Connect dotNet rules
• Enterprise JavaBeans — About Connect EJB rules
• File output — About Connect File rules
• HTTP messages (no SOAP wrapper) — About Connect HTTP rules
• Plain old Java classes — About Connect Java rules
• Java Common Connector Interface — About Connect JCA rules
• Java Message Services — About Connect JMS rules
• IBM MQSeries messaging — About Connect MQ rules
• WSDL-based Web services — About Connect SOAP rules
• Relational databases through SQL — About Connect SQL rules

ServicesSimilarly, rule types for services cover 14 protocols and technologies:

• BPEL — About Service BPEL rules
• Microsoft COM — About Service COM rules
• Microsoft .Net — About Service dotNet rules
• Enterprise JavaBeans — About Service EJB rules
• Incoming email — About Service Email rules
• Input files — About Service File rules
• HTTP message (no SOAP wrapper) — About Service HTTP rules
• Plain old Java — About Service Java rules
• Java Message Service messaging — About Service JMS rules
• JSR-94 API — About Service JSR94 rules
• IBM MQSeries messaging — About Service MQ rules
• REST — About Service REST rules
• JSR-168 portlets — About Service Portlet rules
• Web Services — About Service SOAP rules

How connectors workConnector interfaces consist of a call or outgoing message (known as the request), followed by a return or arriving message, known as the response. You can parse, convert, and map data in either direction to or from the clipboard.
Arriving information can be an XML file format (and accepted by the Parse XML rule), in a fixed record structure (accepted by the Parse Structured rule), or a text file with input fields separated by a tab character or other specific characters (accepted by the Parse Delimited rule).
Your flows can include Integrator shapes, which execute activities that use connector rules to gather data or request processing from another system.
For most connector types, you can simulate the operation of a connector before you build the connector. This allows your application development and testing to proceed when the external system is unavailable or is difficult to test with. See Creating connector simulators.
Mapping and ResourcesSeveral rule types facilitate two-way mapping between property values (on a requestor clipboard) and the messages, records, or structures used by the external system or technology. These rule type belong to the Integration-Mapping category. See Data mapping in services and connectors — Concepts and terms.
Resource identifiers — such as URLs, port numbers, usernames, passwords, and the like — may vary between a development or test environment and a production system, and may change during the operation of a production system. Such information is usually better stored in data instances, rather than rules. The data classes belong to the Integration-Resources category.
Landing pagesFour Integration landing pages provide access to integration rules and resources:

• Connectors landing page
• Services landing page
• Email landing page
• Resources landing page

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.