Kaseya BMS Documentation

Prerequisites/Foundational Information

In order to complete the connection wizard, the following items should be completed.

• Create an API user in Kaseya BMS and document the username and password
• Collect and document the URL and BMS Tenant for your organization
• Create/determine and then document the default “catch-all” Customer and Contact to assign tickets to unmapped organizations.
• Ensure that any PSA Customer you will utilize with SaaS Alerts has at least one Contact created within it.
• Give thought to, and then document, which PSA values you want to use for ticket creation.
• Determine if you will utilize Issue Type/Sub-Issue Types, and what you would like the default values to be.
• Determine how you would like to group alerts (User or User+Alerts).
• Determine if you will utilize Contract mapping, and if so, determine/document the name and pricing for the Default Contract Service.

Create an API User

Follow the official instructions from Kaseya on how to create a Dedicated API Integration Account in PSA.

TIP: Create a specific user for SaaS Alerts (rather than sharing an existing API Integration user) and include SaaS Alerts in the User Name to make it easy to find/troubleshoot in the future.

We recommend the following settings:

Setting	Value
Department	Administration
Employee Roles	Administration
User Type	Api Employee
Security Roles	Administrator
Job Title	Administrator
Employment Type	Full Time
Location	Main Branch

Create/Document Catch-All Customer and Contact

When a ticket (or note) is created in Kaseya BMS, it will always be mapped to a Customer and a Contact.

Ideally, each Organization within SaaS Alerts is mapped to a specific Customer within the Customer Mapping section of the PSA integration wizard.

In the event that a specific Organization is not mapped, SaaS Alerts will utilize the Default/Catch-All Customer and Contact to ensure that a ticket is created.

TIP: Create a specific Company and Contact for the purpose of being the catch-all account, rather than using your MSP Customer. For instance, create a Customer called “Default Customer” and create a contact called “Default Contact” within that Customer. This keeps your MSP Customer clean and separated from unmapped Organizations’ tickets in the future.

Ensure that every Customer has a Contact

We assign each ticket (or note) to a Contact.

We always attempt to find the actual Contact by using the user’s email address from the alert to look up the corresponding contact within Kaseya BMS.

In the event that we cannot find a Contact utilizing the email address, the ticket will be assigned to the default Contact for that Customer.

TIP: Create a specific Contact in each Customer for the purpose of assigning tickets that are not able to be mapped to specific Contact. For instance, for ABC Company, you might create a Contact called “Alert Contact for ABC Company” and use that as the default when mapping the Organization to the Company/Contact.

Ticket Defaults for Service Parameters Screen

Each time a ticket is created, we set the following parameters:

• Ticket Type
• Ticket Source
• Ticket Status
• Ticket Queue
• Ticket Priority

TIP: Consider the values you want to use for each of these mappings to help categorize and find tickets once they have been created. Document these settings to make configuration in the wizard a snap.

Determine if you will use Issue Type / Sub-Issue Types

Issue Type and Issue Sub-Type fields on tickets can be used to help organize/filter tickets as well as to drive Workflows (see Getting Started with Workflows documentation on the Kaseya site).

SaaS Alerts is very configurable in this area and supports the following combinations:

• No Issue Type / Sub Issue type
• Default Issue Type assigned to all tickets
• Default Issue Type / Sub Issue Type assigned to all tickets
• No Default Issue Type (or Sub Issue Type), with an override per specific Alert.
• Default Issue Type (and Sub Issue Type), with an override per specific Alert.

TIP: Create a SaaS Alerts specific Issue Type and utilize this as the Default Issue Type. This allows you to quickly use this value to find tickets and/or use for Workflows.

ADVANCED TIP: Do the above, and then create a few Sub-Issue Types based on different types of Alerts (IAM, Data Leakage, etc.). Then, map an Issue/Sub-Issue to specific alerts, so that Workflows can assign certain types of Issues/Sub-Issues to different queues or adjust priority.

Determine How to Group Alerts

Often, a single user will generate many alerts. To reduce the number of tickets created by SaaS Alerts, we provide two different ways to group those alerts: User and User+Alert.

User

When User is selected, the first alert generated for a specific user will create a ticket. All subsequent alerts - of any type - for that specific user will be added as notes to that ticket until that ticket is closed.

Example Logic:

1. [e-mail] triggers a “Too Many Downloads” alert.
2. We create a ticket because this is the first alert that the user has ever had happen.
3. Then, 15 minutes later, the same user triggers a “Too Many Uploads” alert.
4. Since the user still has an open ticket in the system, we add the “Too Many Uploads” alert as a note to the initial ticket.
5. A tech at your organization reviews the ticket, determines that it is not an issue, adjusts the file alert limits for this particular user up, and they close the ticket.
6. 15 minutes later, the same user triggers a “Multiple MFA Failures” alert.
7. Because the original ticket was closed, a new ticket is created for “Multiple MFA Failures” alert.

User+Alert

Selecting User+Alert will open a new ticket for each specific alert for a user. Subsequent alerts of the same type will be added as notes to the original ticket until that ticket is closed.

Example Logic:

1. [e-mail] triggers a “Too Many Downloads” alert.
2. We create a ticket, because this is the first alert that the user has ever had happen.
3. Then, 15 minutes later, the same user triggers a “Too Many Uploads” alert.
4. Even though the user still has an open ticket in the system from the first alert, we create a new ticket for the “Too Many Uploads” alert, because it is a different type of alert.
5. A tech at your organization reviews the “Too Many Downloads” ticket, determines that it is not an issue, adjusts the file alert limits for this particular user up, and they close the ticket.
6. 15 minutes later, the same user uploads a larger set of files and triggers another “Too Many Uploads” alert.
7. Because the “Too Many Uploads” ticket is still open, and the alert is identical, we add the “Too Many Uploads” alert as a note to the “Too Many Uploads” ticket.

Contract Mapping

SaaS Alerts supports contract mapping for two reasons:

• Adding a Contract Service line item to each mapped contract, and updating the user quantity for billing purposes.
• Adding the Contract to each ticket that is created.

In order to utilize this feature, a Default Contract Service will need to be created. You can do it through the Kaseya BMS GUI, or via a button within our integration wizard.

If you plan to use the wizard to create the Default Contract Service, you will need to decide on, and document, a name, cost, and price for the Contract Service.

Kaseya BMS Integration Wizard

Start the Wizard to Add a New Connection

1. Go to the Settings screen inside the SaaS Alerts app.
2. Scroll down to PSA & Email, and click the “+” button.
3. Choose Kaseya.

Set Credentials

1. Choose the URL documented earlier, and enter the Tenant name.
2. Input the BMS Username and the BMS Password.
3. Choose Next.
4. If the information entered is correct, the Customer Mapping Screen will be displayed.

Customer Mapping

1. In the Catch-All PSA Customer dropdown, choose the Customer you want to assign unmapped Organizations to.
2. Choose the Catch-All PSA Ticket Contact in the dropdown that appears after choosing the PSA Customer.
3. To reduce the size of the list of PSA Customers, choose an Account Type and set the Parent/Child dropdown to the appropriate setting.
4. For each PSA Customer you need to map to a SaaS Alerts Organization, find the PSA Customer on the left, and then match the SaaS Alerts Organization in the dropdown.
5. Once a SaaS Alerts Organization is selected in the dropdown, choose the appropriate PSA Ticket Contact in the dropdown list that is displayed next to it.
6. In the event that you have a PSA Customer that you would like to add/import to SaaS Alerts, and have it automatically mapped for you you can choose “+Add to SaaS Alerts” from the SaaS Alerts Organizations dropdown and it will be left in a pending state in the SaaS Alerts Manage application.
7. Once all mappings are complete, scroll down and choose Next.

Note: You can edit the Kaseya BMS connection once the wizard is complete to adjust mappings or to add new ones.

Service Parameters

1. Use the Ticket parameters you documented in the prerequisite/foundational steps to set each of the Ticket defaults.
2. Set the Group alerts by dropdown to User or User+Alert based on your earlier decision.
3. OPTIONAL: Utilize the Issue Type / Sub-Issue Type default mappings as well as adding specific alert mappings in the optional section.
4. Once complete, scroll down and choose Next.

Contract Mapping

1. If you chose to create the Default Contract Service within the Kaseya BMS GUI, select that Contract Service In the Default Contract Service dropdown. Otherwise, click the Create Service button.

2. When creating a service, we have provided default parameters for you. Make any changes necessary, and then click Create Service. The Cost and Price will be used as the defaults but can be overridden for each Customer mapping.

3. For each Customer you would like to have the Contract mapped during ticket generation, select the Contract in the dropdown next to that Customer.

4. For each Customer you would like to have a Contract Service added and the user counts updated, choose Add Service to Contract, and then set the appropriate Cost and Price for that Customer.

5. Once complete, scroll down and choose Finish.