Work Items provides a generalised system for processing requests which cannot be actioned in real-time and may require decisioning leading to approval or rejection, however are not serviced by other more specific means.
There are primarily two components to Work Items, being the Service (JSON Rest API) and the Fusion Web Application.
As stated above Work Items provides a generalised system for managing exception and asynchronous requests. These are requests which cannot be processed in real-time or require escalation or additional approval and validation. These requests are usually concerned with decisioning, or simply the approval or rejection of such requests.
As a generalised system it is not designed for highly specific or complex workflow management but rather simple requests such as credit balance refunds, gesture of goodwill, breathing space, etc. This service can be used anywhere where work items are needed for a workflow, the service is a part of the Fusion suite but can be utilized by other domains such as Collections for example.
A collection of flows is defined for each desired item type. Items, which conform to one of these flows, will enter the system from other applications and services. Items are assigned to queues, which are access controlled lists, to be worked by appropriate back-office users.
Key Concepts
A flow is a particular process, it defines a type of item; its structure, rules, and life-cycle. An item must specify and conform to a single flow.
NB
- An item must specify and conform to a single flow.
- There is no standard template for a flow, while there are default actions there is no default request schema, rules, queue, etc.
- If an account number is provided as part of the request schema then live account details will be shown to the user, so it should not be necessary to capture the customer’s account details such as their name or address.
An individual request, an item, which must conform to a flow. An item contains the request information as defined by its flow’s request schema as well as meta data such as its creation time, the user who created it, etc.
A queue (sometimes called list) is an access-controlled collection of items. Items are assigned to queues as defined by their flows. A user may only work on items presently assigned to a queue which they have access to. A queue may contain items pertaining to one or more flows. A queue is expected to represent a specific role or level of authority within a business unit. Note that an item can only be assigned to a single queue at a time but may be moved between queues by rules.
An item’s simplified lifecycle is as follows: First an item is created (new), it is then worked (progress or error) and finally it is completed (approved or rejected). Rules are evaluated every time this is changed.
By default workflows follow a simple lifecycle with a standard series of actions.
When a new request (item) is created it it is marked as “New” and a user may “Start Work”. Starting work will mark the item as being in “Progress”. An item which is in progress may then be “Approved” or “Rejected”. If an error occurs (such as a failed fetch event) then the item will be marked as “Error” and the same actions which are available in the progress state will also be available.
Every time an action is taken rules will be evaluated.
Actions may be customized with more appropriate labels to help the user better understand the process they are facilitating.
A flow may define automation rules which will be evaluated when an action is performed on an item. These rules may trigger events (documented below). Rules may be evaluated against all information contained in an item, that is both its meta and non-meta data.
Rules can trigger events which do things such as assigning the item to a list, changing the item’s status (i.e. reject or approve it), or add a note on a linked customer’s account. Further details may be found below.
A flow must define a JSON schema which describes the non-meta information contained in an item. This may define simple JSON properties such as string, number, boolean, and also custom formats such as card-account-id which allows linking an item to one or more customer accounts.
If the flow permits it the work items application can render a form for the creation of an item conforming to this schema.
For more information see JSON Schema.
A flow may define a service-level agreement in days. When a request is received it will then calculate a timestamp SLA days in the future, by which time the item should have been completed. This is clearly visible in the work items application as queues are sorted by SLA with the most urgent items appearing at the top. Items with less than one day SLA remaining will be highlighted in a warning style and items overdue also highlighted in an error style.
Available Events
Recap: Actions trigger rules to be evaluated, and in turn evaluated rules may trigger events.
Assign Queue
Event Name: assign-queue
Assign the work item to a particular queue. This allows for dynamic assignment; we use this to do things like assigning more senior queues to manage delegation of authority limits.
Assign SLA
Event Name: assign-sla
Calculate the item’s SLA.
Approve (Complete)
Event Name: complete
Rules may be used to automatically approve and complete incoming requests. You would generally only trigger this at the time of creation. This may be useful for evaluating if the user making the request has a sufficient DoA so that we can skip the approval process.
Add Note
Event Name: add-note
If an item has an associated account you may add a note to that account. The note’s contents are templated so it may contain any details from the item.
Notify (Fetch)
Event Name: fetch
Call a JSON REST API, parameters may include any details within the item, the type of action which resulted in the event and the user which initiated the action.
This is especially useful for completion, take a simple gesture of goodwill request for example. Upon approval a request is sent to core credit to apply a credit adjustment on the account.
Create Item
Event Name: create-item
Creating a new item is useful in scenarios where a follow-up item is required to complete the journey. This event may include any details from the current item.
Example: When an item is rejected, a follow-up item is created using a different workflow.
- Provide a standard NewDay MSI service authorization JWT token.
- Be on the internal NewDay network to access this API.
Was this page helpful?