Harmonizing Service Desk Efficiency Amidst Concurrent Operations

A race condition occurs in computer science when the behavior or outcome of a system depends on the timing or sequence of events. It typically happens in concurrent or multithreaded programs, where multiple processes or threads attempt to access and manipulate shared resources simultaneously.

In a service desk scenario where multiple agents might be accessing and updating requests or data concurrently, preventing human race conditions is why we invented Znuny. It is crucial to maintain communication integrity and ensure smooth operations.

Here are ways Znuny mitigates doubled and sometimes conflicting effort for your service operations team:

Programmatic Tools:

These are the software settings or parts of code which prevent things from happening, or support your users intentionally through configuration.

Locking Mechanism: By implementing the lock function on important screens, we ensure exclusive access to critical functions like group assignment (queue move) or answering a customer (email reply). For instance, a lock prevents simultaneous emails on the same ticket by different agents. Which screens require a lock can be found in the system configuration by searching for ##RequiredLock.

Atomic Operations: By default, Znuny implements an atomic operation approach, offering you multiple screens to perform individual operations. These screens ensure that specific operations are performed atomically, without interruption, reducing the chances of interference.

Operator Tools:

Ownership Indicator: A request owner has exclusive right to a request, as long as it's locked. Primarily, this person is the last person to have modified the ticket, and should be contacted when questions arise.

State Indicator: A ticket has a state. This state is a great indicator of what is happening with a request.

Understanding Ticket Ownership:

Here is a table referencing the ticket details and their meanings:

A ticket is being actively worked on when the ticket values are.

Lock: locked Owner: any State: new, open, pending

The only exception is the Owner ID 1 (default: root@localhost or Admin OTRS)

A ticket should be considered as not in progress when:

Lock: unlocked Owner: any State: open or new

By combining these programmatic strategies, and training your users how to appropriately use and recognize this within the tickets, you can significantly reduce doubled effort in your service desk operations and prevent users from colliding when handling requests.