Processes landing page

The Processes landing page gives visibility into the business processes implemented by your application.

Access it by selecting the > Process & Rules > Processes menu item.

The following tabs are available on this landing page:

Flow Errors
SLAs (Service Level Agreements)
Status Values
APIs (Application Programmer Interfaces)

Using the Flow Errors tab

This report lists flow errors that are routed to your worklist or work group in your current application by a getProblemFlowOperator activity. Each row identifies one flow problem. Rows may reflect a common condition or unrelated conditions from multiple applications.

Using the View errors located in drop-down list, select Worklist or Workbaskets to see flow errors that are routed to one or the other in your current application.

Column	Description
Add	Select to designate one or more rows that you want to apply your problem resolution choice as defined by the button you select on this tab.
Error Message	Underlying problem that caused the flow error.
ID	Identifier of work item associated with this error.
Flow	Name of the flow in which the error occurred. To open the flow, click the displayed name.
Step	Name of the problem flow step in which the error occurred (pyFlowParameters.ProblemFlowStep).
Operator	ID of operator to whose worklist the problem flow assignment is routed by the getFlowProblemOperator activity. To open the Operator ID rule, click the displayed name.

After you have diagnosed and addressed a problem, check the Add box in one or more rows of this report and click a button to implement your disposition of the problem.

Button	Result
Select All	Selects the Add box for every row in the report.
Deselect All	Clears the Add box for every row in the report.
Resume Flow	Click to resume flow execution beginning at the step after the step that paused, without re-executing any rule in the step that paused. This choice is common after many types of repairs to rules or data objects. For example, if a flow is stuck at a Decision shape, you can either: Update the flow to add a missing connector and click Resume Flow. Update the decision tree, decision table, or map value to return a value that the flow already accepts, and click Retry Last Step.
Retry Last Step	Click to resume flow execution but begin by re-executing the step that paused. This choice is typically appropriate for connector failures or timeouts.
Restart Flow	Click to start flow at the initial step.
Delete Orphan Assignments	Deletes an assignment for which the work item cannot be found. Such orphans may arise through design or implementation errors, access issues, RuleSet issues, or database integrity issues.

About flow errors

When it detects a flow error, Pega 7 normally starts the standard flow Work-.FlowProblems (using the same work item ID). It creates an assignment and places the assignment on a worklist, typically named administrator@zzz.com, where zzz.com is the organization of the operator who last worked on the work item. You can customize the standard activity Work-.getFlowProblemOperator in each application to send these to a different worklist or to a workbasket.

For example, these conditions cause a flow error execution to start:

The flow references a rule that does not exist, or a rule that the user (or agent) executing the flow lacks RuleSets, versions, access roles, privileges, or other prerequisites to execute. Examples: an activity, service level, decision tree, harness, map value, or subprocess.
The flow references a data instance that does not exist. Examples: workbasket, operator, organization, work group, access group.
The flow execution is stuck, in that following a decision shape, none of the outgoing connectors evaluate to true.
An activity has failed, or a connector rule has failed or timed out.
The work item contains invalid data that causes one of the above conditions.
The database, hardware, network, or system software has failed.

In a production setting, review and diagnose every flow problem or problem assignment to insure data integrity.

Using the SLAs (Service Level Agreements) tab

Service Level Agreements (SLAs), defined in service level records , are time constraints placed upon a case as it moves through the system. Use the SLA tab to display the overall case process, stage, flow, and assignment service levels defined in the current application, and identify the flows or case type records that reference the service levels.

Column	Description
Name	Name key for this service level. Click the name to open its form for review or updates.
Applies To	Class key for this service level. Click the class name to open the class form for review or updates.
Goal	The Goal value defined on the service level form's General tab.
Deadline	The Deadline value defined on the service level form's General tab.
References	The count of case type records or flows that reference this service level. Click the reference count to open a list of flows (for assignment or flow service levels) or case types (for overall case or stage service levels).

Using the Status Values tab

Work status values are the primary indicator of the progress of a case towards resolution. The Status Values tab provides a single place to view all of the work item status values currently defined and available in the system. The values, such as New, Open, and Resolved, indicate the progress of a case as it moves through its business cycle.

The columns are described below.

Column	Description
Status Name	The name of the work status (for example, `Resolved-Withdrawn`). To view or modify it, click the name to open its Field Value rule form.
Class	Applies To class of the work status.
Description	Description of the work status. The description is set in the rule form that defines the name and value of the corresponding work status.

Using the APIs (Application Programmer Interfaces) tab

This tab shows the standard activities, flows, and flow actions that comprise the Process API. Use the Process API to start and advance flows without implementing user forms. These rules can support BPM processing through Service Oriented Architecture (SOA) facilities including agents and service activities.

Business process management applications can use an external portal or external system and call Pega 7 services that in turn call Process API rules to create work items, advance the work items through a flow, perform assignments, and so on. You can also use these in certain places within browser-based, interactive applications, or without user forms in headless applications or straight-thru-processing.

For more information about API activities, see Atlas — Process API.

Click the expand icon in a header row to show the full description, usage, and parameters for the rule. The value in the References column indicates the number of rules that reference the API rule. Click the value to open the Referencing Rules display.

Column	Description
	Click the expand icon in the row header to learn more about each activity, flow, or flow action. Information includes the rule's parameters (except flow actions).
Rule Name	The Activity, Flow Name, or Action Name key part of the activity, flow, or flow action, respectively. Click the name to open the rule form.
Category	The name of the rule type (activity, flow, or flow action).
Description	A short summary of the rule's purpose.
Applies To	The Applies To class of the rule.
References	The number of rules in the system that reference this API rule. Click the value to open the Referencing Rules display.

	landing page, service level rule, flow errors
	About flows About flow actions About service level rules

This display is also available from the main help menu. On the Designer Studio header, select Help > APIs > Process to open the APIs tab.

Tools — Process and Rules