Kaseya BMS email parser setup
Short answer
Point the Kaseya BMS email parser at a mailbox Watchbill writes to. The subject does not contain a BMS ticket number, so recovery is a new ticket.
How The Watchbill helps
- On Pro and Business, a down check can email the address your ticket system already turns into a ticket.
- The recovery message uses that same path.
- Email alerts are included on every plan, including Free.
This guide is the Kaseya BMS mailbox setup for a down check and the recovery that follows it.
On Pro or Business, open Alerting, then Ticket email, and choose Kaseya BMS. Paste the mailbox the email parser reads. Company and board are optional. The message names the company, the site, the monitor, the status, the time, and a link back to the account. Send one test down and one test up before the rest of the checks.
What to set in BMS
Open Admin, Service Desk, Email Parser, and create a parser for that mailbox. The setup page says mail from an active parser becomes a ticket under Service Desk, Tickets. A sender that is not a contact becomes an unknown ticket. The same page says not to use a technician's own mailbox as the parser.
The parser can set a default queue or assignee. It does not describe a field token for company, site, or status. Those lines stay in the ticket body.
What the mail contains
The subject is [Watchbill] Down: or [Watchbill] Up: plus the monitor name. BMS gives an empty subject the title N/A. This subject is not empty.
The body lines are Company:, Site:, Monitor:, Status: (Down or Up), Time:, and Link:, plus Board: when you saved one.
The threading page says BMS appends a note when it finds a message id from the conversation, and otherwise looks for a ticket number in the subject, written as #[%Ticket Number%]# on BMS's own template. This mail does not contain a BMS ticket number. Do not assume the recovery lands on the first ticket. It does not close that ticket.
There is no API call.
A client that should not share the mailbox
On the client, choose Use a set on this client and check this destination. Set the company when the mailbox is shared and the company is not. Set the board when that client should land on a different queue. Leave the client on Inherit the account set when the account mailbox, the account company, and the account board are right for them.
A check can replace the client set. Use that only when one target should land on a different board. The alerting list names the clients that use the destination. All clients means every client that inherits the account set. A client with its own set is listed only when that set includes the destination.
If the account mailbox changes, inheriting clients follow it. Clients with their own set keep the old mailbox until you edit them. After the change, look at the client column. A short list of names means those names need a look. Write down the mailbox, the company, and the board for each client that does not inherit, or the next person will paste the account mailbox and file the ticket on the wrong company. The client page shows whether the set is inherited or set on the client. Trust that line, then open the ticket system and confirm the last test landed where you named.
If two tickets open
Recovery is a second message. This mail does not receive the ticket number the system assigns, so it cannot put that number in the subject. Keep the state word in the subject. Do not put the time in the subject. The time is a line in the body. Send a test down, confirm the company and the board, then send a test up and write down what the system did with it. Do this on a test company before you add the rest of the clients.
A test from the ticket email card sends the same shape and can open a real ticket. The checking mail and the first confirmed up stay on the alert email. They are not this destination. Five terminal delivery failures turn the destination off and email the account once. A missing mail setting does not count as an attempt. The from address stays alerts@thewatchbill.com.
The message names the company when you saved one, the monitored site, the monitor, the status, the time, and a link to the account. Status is Down or Up. It is the check, not a request to close the ticket. The recovery line is in the body so a rule you already know how to write has a stable string. That line does not close the first ticket. Read the vendor page linked at the top of this guide before you add a close step in the tenant. This mail will not send one.
What to write down
Write the mailbox, the company line you tested, and the queue the ticket landed on. The next person who adds a client will otherwise paste the account mailbox. After you change the account destination, look at the client column again. All clients means the new mailbox covers them. A short list of names means those names have their own set and need a look. A pause you chose stays paused. A downgrade pauses a destination over the plan limit and does not delete it.
Send one down and one up, then wait before you send a third test to the same check. Some mailboxes limit how many messages from the same sender they will process in a few minutes. If the third test disappears, wait and send it again. Open the ticket and confirm the site, the monitor name, the status, the time, and the link are the values you expected. If a field is blank, the label in the mail did not match a field that system reads. The vendor page for this system is the source for that label. Do not add a close command in a workflow you expect this mail to trigger.
How The Watchbill helps
On Pro and Business, this ticket email sends when a confirmed outage opens and when it closes. The subject starts with [Watchbill] Down: or [Watchbill] Up:. There is no API call, and the recovery message does not close the first ticket. The shared comparison is in ticket email.