The purpose of GetNextWork is typically to return the most urgent assignment for the user to work on based on Access Role match and Skills match for a list of workbaskets added to the user's Operator record.
Typically "Get from workbaskets first" is checked on Operator records, Failing to find something in a Workbasket, GetNextWork will search the user's Worklist. If "Get from workbaskets first" is not checked on the Operator's record the Operator's Worklist s searched first and must be drained before checking Workbaskets.
Workbaskets are not necessarily assigned Access Roles but should be. If a Workbasket is not assigned any Access Role and the Workbasket is mentioned on an Operator's record, that Operator would not be questioned when executing GetNextWork. If, however, a particular Access Role is assigned to Workbasket that the Operator is not granted, the Operator would not be allowed to fetch an assignment from that Workbasket.
Skills do not need to be associated to Workbasket assignments. However, if skills are assigned to a WB, the Operator must not only have each skill but also at a rating equal to or greater than the corresponding assignment skill level.
Over time a Service Level rule can increase Assignment urgency, against which the GetNextWork query does a descending sort, but it also possible to specialize the query to return the oldest qualifying assignment, i.e., an ascending pxCreateDateTime sort.
There is a lot more to explain but the above should be a good start.
Thank you for this article. Quick question, is there a way to disable the Get Next Work button if there is no available work in the Work Basket? or failing that, display a message that there is no further work in the work basket. Currently we only get a message when both the operator's work queue and the work basket are empty.
This sounds like you want to offer a Workbaskets View in a user's portal to allow them to see whether or not a particular WB is empty.
Attempting to change the GetNextWork response to say "Workbasket is empty" would be an overly complex, non-guardrail-safe approach.
Starting in 7.1.9 it is possible to customize a Dashboard to include a "Workbaskets Widget" (see CASE MANAGEMENT widgets).
If added to the Portal it would be the User's responsibility to refresh the Workbaskets view to see the current count.
A potential problem with this approach is that it would allow users to "cherry-pick" from the Workbasket list as opposed to using GetNextWork.
The Data-Portal pyWorkListWidgetGridsAuto Section is what displays the Workbasket list.
You could, for example, override this UIKit section, then disable the on-click "Open Assignment" action configured against the Assign-.pxRefObjectInsName Property in the Reporting Grid sourced to D_WorkBasket.
This change would affect all users which may be perfectly fine.
If, however, the change should only apply workgroups/actors, as opposed to "Save-As" use "Specialized by circumstance".
You can define a Data-Admin-Operator-ID "PrimaryRole" Property that is set by a Declare Expession defined as "what comes after last" - AccessGroup.pyAccessFroup - colon.
The value would be populated on the OperatorID clipboard page.
You would circumstance Data-Portal pyWorkListWidgetGridsAuto by Operator.PrimaryRole