More about service-level agreements

The standard Pega-ProCom agent, operating as a background process, monitors service-level agreements associated with assignments. To make service-level agreements 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 agreements, 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 Pega Platform server.)

Escalation computations

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 item. 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.

Service-level agreements for work items

To associate a service-level agreement with a work item, 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 item — the elapsed time since it was opened.

Allowing users to reset service-level agreements

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

• Include the pyAdjustSLA flow action to allow a user to review, or modify, the service-level agreement associated with an assignment.
• Include the pyAdjustSLATimes flow action to allow a user to adjust goals and deadlines in bulk without providing a new service-level agreement.
• Include the ChangeWorkSLA flow action to allow a user to review, or modify, the service-level agreement associated with a work item.

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.

Recomputations

Business day calculations

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 agreement or the calendar changes later.

Different work items 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, the Pega Platform looks in three places in sequence:

• A calendar referenced in the work item 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.

Correct operation on multinode clusters