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 sort and not the secondary sort. Such a requirement can exist for a work group that wants the oldest workbasket assignments processed first — 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 sort on pxCreateDateTime as opposed to a descending sort on pxUrgencyAssign, which it uses by default.

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

Suppose for Claim cases, a customer-specific SLA deadline duration. That 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 creating a unit-less ratio. It is easy to see that the value for pxUrgencyAssign will be 100 using the above formula when CurrentDateTime = pxGoalTime. The choice of 100 is arbitrary. Any factor could be used such as 80. That value can be defined as a configurable.

Truncating the value of pxUrgency assign to 100 is fine provided 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 where the urgency is not be 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. In the FSG Booking application solution, 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 a SQL Connector to compute distance. It is difficult to incorporate a SQL Connector call into the Pega-provided GetNextWork implementation. Plus, being able to invoke the Get Next Work action requires access to a Pega portal. You can use a different way to access Pega, such as a REST service call, which involves an App Requestor instead of a Browser requestor

A button click action can be configured as 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 workbasket’s 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, one where work had been routed using the ToSkilledWorkBasket activity.

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

The view is similar to work queue lists that are sourced to D_WorkBasket. The difference is that the report definition must take assignment and operator 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 OPSKILL.pyUserIdentifier = OperatorID.pyUserIdentifier