Skip to main content

​
Channels

  • Email
  • Slack
  • Teams
  • SMS

​
Sending only in certain cases

Custom instructions on a notify action can be conditional. Write the condition in plain language and Neo sends nothing when it is not met:
  • Only notify for P1 and P2 tickets. For P3 and below, send no notification.
  • Do not send a message if a technician was assigned.
When the condition is not met, no message is delivered and no notification is recorded. The action itself still runs and still reports a result, so you will see it as skipped rather than failed. On Notify Internal Team, the run’s output says the notification was skipped because the custom instruction’s condition was not met, and an instruction with no condition always sends. Instructions that set the format, choose the fields, or describe what an earlier action did (After assigning the ticket, send one Slack message) are not conditions. Neo decides once for each message, before it writes anyone’s copy, so every recipient of the action gets the same send-or-skip decision.
State the condition as something the notification’s own content can settle, such as the ticket priority or whether an assignment was applied. Neo judges the condition from the messages the earlier actions produced and the ticket facts below, so a condition that depends on a value neither mentions cannot be evaluated reliably.The ticket’s description is not one of those facts. To notify only when the client asked for something urgently or by a set time, have your triage write that into a field, such as the due date or the priority, and word the condition on that field: Only notify when the ticket is due within 4 hours.
A conditional instruction is a filter on the message, not on the workflow. Every earlier action still runs, and the ticket is still processed. To stop the work itself, use the ticket conditions on the action that finds the tickets.

​
Ticket facts a custom instruction can use

This section covers the actions that notify your own people: Notify Internal Team, Notify Ticket’s Owner and Notify Ticket’s Resource. Notify Ticket’s Contact writes to the end user through a different path and does not receive these details. Neo gives the notification the details of the ticket the message is about, so your instruction can ask for them by name: company, contact, board or queue, status, owner, priority, type, subtype and item, the created, closed and due dates, and the SLA targets. That is normally the ticket that triggered the workflow. When an earlier action produced a message about a different ticket, the details follow that one, so they match the ticket named in the message heading. When an earlier action in the same run assigned the ticket or updated its fields, Neo reads the ticket again before the notification, so the details show the values that action wrote. It also gives Neo how long the ticket has held its current status, so you can ask for that directly:
  • State how long the ticket has been in its current status.
The figure is counted in business hours, using the business hours set for your account, not wall-clock time. A ticket that changed status at 16:45 on Friday reads as a few minutes on Monday morning, not a whole weekend. Public holidays count as ordinary working days: Neo skips only Saturday and Sunday.
Neo leaves the line out rather than guess, so write the instruction so the message still reads correctly without it. The figure is left out when the notification is not about one identifiable ticket, which is the usual case for a scheduled run covering many of them; when your PSA is not ConnectWise, Autotask or Halo, which are the three whose audit trail Neo can read; and when the audit trail records no status change for the ticket in the last 30 days, which also covers a PSA that is not answering.
On ConnectWise and Autotask the same figure is also available when you choose which tickets to act on: add the Minutes spent in current Status ticket condition on the action that finds the tickets. Halo has the figure in the message but not as a condition. Note that a workflow triggered by a status change sees a value near zero, because the status has only just changed.