Messages

Messages lists every message that has entered the workspace, newest first, in plain English. Select a message to see its whole story: what arrived, how it arrived, what it became, and every delivery attempt.

Open Messages in the left sidebar.

The Messages list, with the messages that need attention summarised at the top

Find a message

1. Start with what needs attention. The bar at the top counts messages that need a look, by state (Dead-lettered, Failed, Partially delivered, Retry pending) and by most common cause, such as Destination temporarily unavailable. Select any chip to filter the list to it.
2. Search by correlation ID, message type, source, destination or ACK code.
3. Filter by status and format, or select Needs attention to see only messages that did not reach every destination.
4. Under More filters, narrow by Message type, Source, Destination, Pipeline, Transport (HTTP, MLLP, Webhook, SFTP, FTP, Database), Failure cause or when it was Received.

Each row shows the status, when it was received, the message type (for example ADT^A01), a one-line summary, the Source with the way it arrived (for example via MLLP · Hospital PAS – ADT), the pipeline and destination, how many destinations accepted it, and how long it took.

tip

Admins can select Export CSV to download the list as it is filtered. The export holds metadata only (times, types, sources, destinations and states), never message content, and each export is recorded.

Read a message

Select a row.

A message in plain English, with how it arrived

1. The headline says what happened in one line, for example "Delivered. Every destination accepted the message. Nothing to do." If something went wrong, it says what, and what to do next.
2. Plain English describes the incoming message: the event, the patient, the visit and who sent it. High confidence and Rule-based say how the summary was made.
3. Raw incoming shows the original message exactly as it arrived. Members and admins can open it; each time it is opened, that is recorded in Logs.
4. The chips under the summary show the format, the Transport, the source it Arrived through (select it to open the source), when it was received, the processing time, the ACK sent back, and the number of attempts.

Scroll down for what went out and where.

The outgoing message, its destinations and the timeline

5. Outgoing message describes what the pipeline produced, for example "The output is a FHIR Bundle with 5 entries: Patient, Organization, Practitioner, Encounter, Provenance." Raw outgoing shows it in full.
6. Destinations lists each destination with its result (for example 201), the time it took and how many attempts were used.
7. Timeline lists each step in order: received, validated and transformed, delivered, with times.

When a message did not get through

The headline and the Destinations section say why, in plain English, with the cause NEEV classified, such as:

Cause	What it usually means
Destination temporarily unavailable	The receiving system was down or busy. NEEV retries on its own.
Could not reach the destination	The address could not be reached at all. Check the destination's address and network.
Destination did not respond in time	The receiving system took too long.
Destination rejected the message	The receiving system refused it, often because of one field.
Message type not handled	The feed's pipeline is not set up for this message type, for example an ADT^A02 transfer on a feed that handles A01, A03, A04 and A08.
Could not convert the message	The message did not match what the conversion expects.

What you can do from the message:

• Send again sends the output that was already produced, unchanged. Use it when the destination was the problem and is fixed.
• Run again runs the incoming message through the pipeline again, with today's mapping, then delivers it. Use it when the mapping was the problem and is fixed.
• View logs opens Logs filtered to this message.

Both ask you to confirm, warn you if the destination may already have the message, and take an optional reason that is recorded. A message that ran out of retries is also in the Queue.

When a message needs review

Some conversions find something a person should check before the result goes on, for example a patient identifier that could match two people, or a code with no standard equivalent. NEEV then pauses that branch of the route and marks the message Needs review. Nothing from the paused branch has been sent; other branches carry on.

Open the message. The review card, Needs your review, explains why processing paused, lists each issue and shows the output that is waiting. An admin enters a note and chooses one:

Decision	What happens
Approve and continue	The waiting output goes on to the next steps and its destinations. Other branches are not run again.
Rerun after corrections	After you fix the cause, for example a profile or the mapping, the paused branch runs again with the saved configuration. The new result may need another review.
Reject output	The waiting output is never sent. Deliveries already made on other branches stay as they are.

Every decision, with its note, is recorded. Members and viewers see the card but cannot decide.