Alternative ways to find work

Recall the discussion about circumstancing and how to customize Get Next Work. Suppose the workbasket assignment’s pxCreateDateTime property is used as the primary sorting criterion, not the secondary sorting criterion. This requirement can exist for a work group that wants the oldest workbasket assignments to be processed first —  this is known as First In, First Out (FIFO). The pyGetWorkBasket report definition behind the D_WorkBasket list data page that is used to display workbasket assignments can be modified to use an ascending sorting criterion on pxCreateDateTime, as opposed to a descending sort on pxUrgencyAssign, which D_WorkBasket uses by default.

You can derive a value for pxUrgencyAssign after the fact by means of reverse engineering, taking into account @ CurrentDateTime() and the work queue assignment creation. The value for pxUrgencyAssign does not need to be computed until it is displayed in a UI.

Example scenario

For an insurance company's Claim cases, a customer-specific SLA deadline duration is required. The duration is added to the pxCreateDateTime of each Claim case to establish the case's deadline DateTime.

All ClaimUnit subcases of that case must be completed by their parent Claim case's deadline. Different ClaimUnit case types, however, take different durations, on average, to complete. For efficiency, each ClaimUnit type's average time to complete could be made available within a node-level Data Page.

A ClaimUnit spun off to a work queue could compute its pxGoalTime DateTime property as @CurrentDateTime + (customer deadline – average time to complete). Here, pxGoalTme represents the DateTime. The ClaimUnit is fetched from its work queue to allow sufficient time to complete the work.

A circumstanced version of the Assign-WorkBaset GetNextWork ListView can perform an ascending sort on pxGoalTime instead of using pxUrgencyAssign descending. A circumstanced version of the pyGetWorkBasket report definition can also perform an ascending sort on pxGoalTime.

The rule declare expression for pxUrgencyAssign can also be circumstanced. The following example shows how pxUrgencyAssign can reverse engineer its value based on datetime properties:

pxUrgencyAssign = min(100, 100 * ((CurrentDateTime – pxCreateDateTime) / (pxGoalTime - pxCreateDateTime)))

where:  CaseDeadlineDateTime = CaseCreateDateTime + CustomerSLA (Assign-)

  and:  pxGoalTime = CaseDeadlineDateTime – CaseAvgTimeToComplete

Note how the time units within the numerator and denominator, whether minutes, hours, or days, cancel each other out, which creates a unit-less ratio. It is easy to see that the value for pxUrgencyAssign will be 100 using the above formula when CurrentDateTime = pxGoalTime. But the choice of 100 is arbitrary. Any factor could be used, such as 80, and can be defined as a configurable.

Truncating the value of pxUrgency assign to 100 is fine, provided that both the Get Next Work query, and the work queue assignment list query, sort by ascending pxGoalTime, not descending pxUrgencyAssign. It is possible to use the same Report Definition for both purposes.

There are situations in which the urgency is not based on time but on something else, such as distance. A shuttle driver, for example, wants their next assignment to be based on proximity to their current location. For example, in the FSG Booking application, a shuttle driver’s location is used to identify the closest hotel or parking location where event attendees are waiting for transport to or from an event.

The booking application invokes an SQL Connector to compute distance. It is difficult to incorporate an SQL Connector call into the Pega-provided GetNextWork implementation. Additionally, being able to invoke the Get Next Work action requires access to a Pega portal. You can use a different means of accessing a Pega portal, such as a REST service call, which uses an App Requestor instead of a Browser requestor.

A button click action can be configured as an Open assignment; that action requires an assignment pzInsKey. An Assign-WorkBasket Data Page can be asked to supply the pzInsKey.

The Assign-WorkBasket data page can call a report definition. The report definition can filter out assignments where pyErrorMessage is not null. A post-query data transform can check if the assignment and its associated case is locked, skip it, and move to the next assignment. Skill matching can be performed by using a subreport defined against Index-AssignmentSkills that, in turn, is joined to Index-OperatorSkills.

Get Next Work is not the only option with which to retrieve an assignment from a skilled work queue, to which work has been routed using the ToSkilledWorkBasket activity.

Suppose a Facility Coordinator portal contains a UIPages view that shows Parking case assignments. The Facility Coordinator persona should not see anything in that view unless they possess the Parking Skill.

The UIPages view is similar to work queue lists that are sourced to D_WorkBasket. The difference is that the report definition must take assignment and user skills into account. The following code is pseudo-SQL for how this can be achieved: 

Main Report:

          Parking work queue assignment list (similar to D_WorkBasket)

          JOIN to FSG-Booking-Work-Parking (CASE) WHERE pxRefObjectKey = CASE.pzInsKey

Filters:

          pxRequiredSkillCount = COUNT(rows in subreport)

Subreport:

          Index-AssignmentSkills JOIN to Index-OperatorSkills (OPSKILL) WHERE pxRequiredSkill = true AND pxSkillName = OPSKILL.pxSkillName

Subreport filters:

          pxInsIndexedKey = (main report) pzInsKey pxSKillRating <= OPSKILL.pxSKillRating AND OPSKILL.pyUserIdentifier = OperatorID.pyUserIdentifier

--

Check your knowledge with the following interaction: