More about Service Level rules

The standard Pega-ProCom agent, operating as a background process, monitors service level rules associated with assignments. To make service level rules in your application visible to this agent:

1. Create an access group (Data-Admin-Operator-AccessGroup class) referencing all the RuleSets and versions that contain service level rules, in all your applications on the system.
2. Update the Agent Sequence instance (Data-Agent-Queue class) named Pega-ProCom.zzzzz (where zzzzz is a node name) to reference this access group. Make sure the agent is enabled.
3. On a multinode system, disable the agent on all but one node, unless multinode operation is necessary for performance of the agent. If you do run two or more copies of this agent, review and update if necessary the dynamic system settings that affect the agent.

Agent processing depends on the current date and time setting on the PegaRULES database server. Make sure the date and time of the database server is synchronized with the date and time on the application server node or nodes. (The database server can be located in a different time zone than the Process Commander server.)

See  Troubleshooting — Service level rules not executing for more tips on debugging service level processing.

Goal and deadline timers start using the time intervals specified in the General tab. If the assignment remains open (not performed) when the goal or deadline time is reached, the system:

1. Adds the value of the corresponding Goal or Deadline Urgency field to the assignment's urgency.
2. Executes the activity in the Activity field.

This escalation processing occurs only once.

Escalation processing events are not automatically recorded in the history of the work object. If you want the history display to reflect that a goal or deadline was reached, you can reference the standard activity Work-.AddHistory on the General tab, or another activity that updates history.

To associate a service a service level rule with a work object, rather than with a single assignment, use the standard flow Work-.OverallSLA. This flow can trigger processing based on the age of the open work object — the elapsed time since it was opened.

See How to set a service level for a work object.

Optionally, your application can empower all or selected users to change or remove the service level rule associated with a specific assignment or work object, through a local flow action included with an assignment. (These can be helpful when testing service levels, even if they are removed or restricted later.)

• Include the ChangeAssignmentSLA flow action to allow a user to review, or modify, the service level associated with an assignment.
• Include the ChangeWorkSLA flow action to allow a user to review, or modify, the service level rule associated with a work object.

Include the flow action as a choice in the flow, and then ensure that the appropriate users have an associated privilege to see and choose it.

Goal and deadline times once established are not normally recomputed, even if the service level rule is later updated or other properties involved in determining these times change later. Your application can call the standard activity Work-.DefineSLATimes to recompute the goal and deadline times of an existing assignment or work object, or set the properties directly.

If the Business Days check box on the General tab is selected, the system calculates the goal or deadline interval using a calendar data instance (Data-Admin-Calendar class). The calendar instance may identify normal weekly closing dates and holidays that are skipped over in business day calculations. The calculation occurs as the assignment is created. The calculated dates and times are not revised if the service level rule or the calendar changes later.

Different work objects may employ different calendars. For example, in some areas, Saturday may be a work day, while other areas are closed. Some offices may observe holidays that others do not.

To locate the calendar for an assignment, Process Commander looks in three places in sequence:

• A calendar referenced in the work object to which the assignment belongs (in the property named Work-.pyCalendar or an override property of that name.
• A calendar associated with the current operator (who may not be the assignee for the assignment). The calendar for an operator can be recorded in the Operator ID data instance or in the Organization instance referenced in the Operator ID data instance.
• The calendar named Default.

A Calendar data instance has two key parts — a name and a start date. References to calendars identify only the name key part. The system uses the calendar instance with a name that matches the supplied name key part and a start date closest to — but not later than — today's date.

In a multinode Process Commander cluster, service level monitoring may occur on one node and some other assignment-related processing may occur on another node, it is important that the computer clocks be synchronized. See Pega Developer Network article PRKB-10206 How to synchronize server clocks and database clocks with NTP for correct service level computations for more information.