Tray app and Messages

The Tray app is the small, branded OpsMerge client that runs in the notification area on the Windows endpoints you manage. End users open it from the tray icon to raise a request, follow the conversation with your service desk, run self-service scripts, see their device's status and respond to messages and remote-access prompts you send.

It ships with the agent: when a tray configuration is enabled for a client, site or endpoint, the agent downloads the current tray build, launches it in the user's session and keeps it running. Nothing to deploy separately.

What the end user sees

Four tabs in a compact window:

• Status — hostname, CPU and memory, IP addresses, agent version, active alerts.
• Self-Service — the scripts you have published for that device, with confirmation and optional approval.
• Notifications — the history of messages you have sent to the device.
• Messages — the user's conversations with your service desk (below).

Right-clicking the icon gives Open, Request Support, About and Quit. About always identifies OpsMerge and Brindleford under your brand, so a user (or an auditor) can tell what the software on the machine is.

Messages: two-way tickets on the desktop

A request raised from the tray is a normal ticket: it gets a ticket number, your ticket type defaults, priority and SLA, and it fires the same rules as any other new ticket (acknowledgement emails included). The user sees the reference straight away, for example INC-1042.

When a technician posts a public reply on that ticket, the reply is pushed to the user's desktop within seconds:

• a native notification appears ("Acme IT — INC-1042: Tina: Try turning it off and on again"),
• the Messages tab badge shows the unread count,
• opening the thread shows the whole public conversation, newest at the bottom, with a reply box.

Replies the user sends from the tray land on the ticket as customer comments with source tray, exactly like a portal or email reply, and follow the same state rules (a customer reply on a ticket waiting for the customer reopens it).

Email still goes out for every public reply by default. Under Settings → Tickets → Desktop app replies you can hold the requester email for up to 60 minutes when the reply was pushed to a desktop app; if the user opens the reply on their desktop within that time the email is dropped, otherwise it is sent as normal. This only affects the "Notify requester on public reply" email. 3 minutes is a sensible starting point.

Internal notes and third-party conversation comments are never sent to the desktop. Only public, staff-authored replies are pushed.

Which conversations a device shows

A device lists:

• tickets raised from that device, and
• tickets whose requester is the contact the current session identifies as.

The session is identified by the signed-in Windows username (as reported by the agent, not the app) matching a contact's Windows username field, or failing that by the device's primary contact. Recent users of a shared workstation are deliberately not used, so one person's tickets are never shown to the next person who logs in. An email typed into the app never grants access to anyone's tickets, since anyone could type it.

If neither matches, the user is a guest: they still see the tickets raised from that device, and the first time they reply they are asked for their name and email so the reply can be attributed. Set the Windows username on the contact record (Clients → contact → edit) to make identification silent.

Signing in with a one-time code

A guest can tap Sign in on the Messages tab, enter their work email and receive a 6-digit code from your mailbox. The address must belong to a contact of that device's client. Entering the code binds that Windows account on that device to the contact, so from then on the app identifies them without asking, and it fills in the contact's Windows username if it was blank, which makes every other device they log in to identify them too. Codes expire after 10 minutes, allow 5 attempts, and at most 3 can be requested per device and user in 15 minutes. Sign out on the Messages tab removes the binding for that device.

Closed and cancelled tickets stay in the list for 14 days after their last change, then drop off.

Delivery and read receipts

Every pushed reply records, per device, when the desktop app received it and when the user opened the thread. In the ticket thread a small monitor icon next to a staff reply shows whether it was sent to a desktop, delivered, or read there (hover for the time). The same receipts drive the email hold above.

Admin configuration

Tray configuration lives at Settings → Tray and inherits organisation → client → site → endpoint:

Field	What it does
Company name	Window title, tray tooltip and header.
Icon	The notification-area icon (data URL or https link, 32×32 recommended).
Logo	Shown in the app header.
Primary colour	Buttons, active tab, the user's own message bubbles.
Support phone, email, web	Shown at the top of the New request form; each opens the native dialler, mail client or browser.
Self-service scripts	The catalogue for that scope; see Self-service scripts.
Enabled	Turns the tray on or off for the scope. Off removes it from the devices.

Branding covers what the user sees. It does not hide the icon, rename the process or remove the About attribution.

Versions and updates

The tray is versioned separately from the agent (tray-v0.5.0 and so on). A new build is published from the release pipeline, and every agent with an enabled tray picks it up on its next check-in and swaps the binary; users do not need to do anything. The current tray version per device is visible on the device page alongside the agent version and whether the tray is running and connected.

Conversations need agent 0.11.3 or later on the device; older agents still get the one-way request form.

Platforms

Windows is fully supported. macOS and Linux builds exist but the launch-in-user-session path is still being finished; treat them as preview.