Work Queues and Work Items

A Business Process is a sequence of Work Queues, each of which provides the specification of a task. Work Queues start on a specific state (the state in which that task must be performed), and have an end state - the state the entity is left in at the end of the task.

Work Items are the application of Work Queues over specific instances and represent the actual work that needs to be done — assigned to a user or a group of users.

For example, when an Application is submitted, a Work Item associated with the Work Queue: "Perform Interview" is created and assigned to a user qualified to perform it — as shown below.

Completing a task is a straightforward process that may involve interacting with the record’s data. For example, once an interview is completed, the outcome is recorded directly in the application’s record.

At creation:

After Creation:

Agents and Permissions

Work Items may be assigned to humans (), in the form of specific users (such as the owner of a job offer) or a group of users (such as the Human Resources Department).

These may be explicitly defined or dynamically obtained from the field of the central record. For example, an owner of a job offer is the person who ultimately decides who to hire, but this person may change from offer to offer.

#

Other tasks may be automated and instead of being performed by a person, will be executed by an RPA (), written by a developer,. These items do not require any human intervention.

Regardless of the agent, all work items are still visible to all team members - people just can't alter the state of work items not assigned to them (they can alter work items without assignees however). This allows for everyone on the team to remain aware of all that is happening in regards to a specific entity and work in general.

Types of Work

Work Queues are flexible and allow for complex flows of work development. Work Items themselves have associated states and ways they transition between them. A work queue's possible states are decided on creation, but impact the way a user performs their work.

1. To Assign adds an additional work step that must be performed by someone, where they assign that work item to someone.
2. To Do means the task has work to be done.
3. In Progress allows the person performing the work to specify when they start the task and when they finish it.
4. Done is the most standard of states - it represents when a task is finished.
5. Pending allows for work to be paused and later resumed.
6. Error gives the task a chance to fail
7. Canceled adds the possibility of a task being cancelled (not to be confused with a task failing).

When working, depending on the state of a work item, different actions are available to the tasked user. To let the system know which action was taken (work was started, completed, canceled, etc.), we can use the buttons that show up in views:

Time of Completion

The time it takes to perform or start a task is an important statistic that often times is not possible to compute in regular environments. Managing tasks in RecordM allows for that calculation to be performed, because we know when a task is started and when it is completed. However, it is important to note that performing the action Complete, when performed in a To Do item, does not register time to completion - because it is impossible to know when the task was actually started, just the time between its creation and completion (Time of Start). To correctly capture the duration of work, the In Progress state is necessary, where we first tell the item that we started that task and when we completed it.

Work Data

At times, a task will require data to be changed in regards to the instance in question. For example, the work queue "Schedule Interview" should assign an interview date to a job application.

When data is supposed to be filled in a record, a work item that needs that information to be inserted will fail when the user tries to complete it without filling the proper fields. An appropriate message - defined by the work queue creator - is displayed, warning the user.

The Business Process itself may depend on internal data of the record. When a queue has multiple possible end states, it means the state of the central entity after the task completes will depend on data inserted into the record.