---
title: 'Execution and work queue'
description: 'How work gets done — operational ownership, the dynamically ranked work queue, bulk operations, capacity-aware assignment and mobile field execution.'
section: 'Operations Center'
weight: 8
related:
  - interface
  - priorities-and-sla
  - kpi
---

import Image from '@/components/docs/Image.astro';

The Operational Health Matrix treats the remediation of operational problems as a managed process rather than a set of independent tasks.

After an `Operational Issue` is created, the system automatically builds the work context, determines the responsible operational zone, applies the corresponding SLA policy, and places the object into the execution queue.

This ensures a continuous work management cycle from the moment a problem is detected until the confirmed restoration of the equipment's normal state.

## Execution Model

Every Operational Issue passes through a single execution cycle.

```mermaid
flowchart TD
  A["Detection"] --> B["Operational Issue"]
  B --> C["Ownership"]
  C --> D["Planning"]
  D --> E["Execution"]
  E --> F["Verification"]
  F --> G["Closure"]
  G --> H["Continuous Improvement"]
```

At each stage, the system records:

- the responsible party;
- deadlines;
- state;
- change log;
- Evidence;
- related tasks;
- applied Knowledge Base articles;
- verification results.

## Operational Ownership

Responsibility is determined by the operational zone, not by a user.

For example:

| Canon                   | Default Owner           |
| ----------------------- | ----------------------- |
| `no_hourly_archive`     | Backend Integration     |
| `stale_communication`   | Communication Team      |
| `battery_low`           | Field Service           |
| `pressure_sensor_stuck` | Metering                |
| `firmware_regression`   | Firmware Team           |
| `registry_duplicate`    | Registry Administration |

Once the zone is determined, the system assigns a specific engineer based on:

- competence;
- workload;
- region;
- work schedule;
- current backlog;
- clearance level.

If necessary, a manager can change the assignment manually.

## Work Queue

The work queue is a dynamic view of active Operational Issues.

Unlike a traditional task list, the queue is built from a combination of factors:

- Priority;
- Severity;
- Operational Confidence;
- SLA Remaining Time;
- Business Impact;
- Number of Affected Assets;
- Reopen Count;
- Root Cause Confidence.

By default, the most critical objects automatically rise to the top regardless of creation time.

<Image
  src="/images/operations-center/09-my-queue-light.webp"
  srcDark="/images/operations-center/09-my-queue-dark.webp"
  alt="Personal work queue screen listing operational issues grouped by state, with overdue items ranked at the top."
  caption="My queue: overdue first, then to-take / in-progress / awaiting data confirmation"
  width={1440}
  height={900}
/>

## Queue Categories

OHM supports several specialized queues.

### Incoming

New problems awaiting triage.

### Assigned

Problems assigned to an engineer.

### In Progress

Work currently underway.

### Awaiting Verification

Work completed, awaiting confirmation.

### Overdue

SLA requirements have been violated.

### Escalated

Automatically escalated problems.

### Reopened

Problems that recurred after closure.

### Massive Incidents

Systemic operational incidents.

## Queue Prioritization

The system uses an integral priority for ranking.

For example:

$$
PriorityScore =
w_p P +
w_s S +
w_b B +
w_c C +
w_t T
$$

where

- P — Priority;
- S — Severity;
- B — Business Impact;
- C — Operational Confidence;
- T — Remaining SLA Time.

The resulting score is used exclusively for sorting the queue and does not change the object's official Priority.

## Bulk Operations

OHM supports bulk operations on a group of Operational Issues.

For example:

- change the owner;
- change the zone;
- change the SLA;
- assign a common Root Cause;
- merge into a Massive Incident;
- apply a Knowledge Article;
- change the priority;
- export.

All bulk actions are recorded in the Audit Trail.

## Capacity Awareness

Work assignment takes into account the actual workload of departments.

Each engineer is characterized by:

- Active Issues;
- Verification Queue;
- Planned Work;
- Availability;
- Current Capacity.

If the workload exceeds the defined limit, the system recommends redistributing the work.

## Workload Distribution

The system uses balancing to prevent overload.

Distribution takes into account:

- the number of open Issues;
- total criticality;
- average resolution time;
- competences;
- territorial affiliation;
- history of performing similar work.

## Mobile Execution

The field version of OHM provides the engineer with:

- the asset card;
- the route;
- the history;
- the latest Evidence;
- related photographs;
- instructions;
- Knowledge Articles;
- the ability to attach new materials;
- an electronic signature;
- confirmation of completion.

<Image
  src="/images/operations-center/26-mobile-dashboard-light.webp"
  srcDark="/images/operations-center/26-mobile-dashboard-dark.webp"
  alt="Phone-sized view of the Operations Center dashboard showing the field engineer's queue and asset details."
  caption="Responsive layout: the same Operations Center on a phone"
  width={390}
  height={844}
/>

After synchronization, the information immediately becomes available to the dispatcher.