HaloCRM Guides

In this guide we will cover: 

- Setting up the Suppliers Module

- Configuring the API Access

Following v2.184+ this functionality as been enhanced. If you are on a version on or above this see our guide Syncing Tickets Between Instances. 

It is possible to send requests across two instances when the HaloCRM -> HaloITSM integration is not being used. You will be able to log tickets from one instance to another, and then the instance the ticket was logged to will be able to email back (Not an actual email as the connection is via API) to the ticket within the instance it was sent from.

This functionality uses the API to send data between instances, by-passing all of the processes that get carried out when an email comes in, such as ID: tag matching, therefore the system will not try to incorrectly match onto tickets in either system, as this matching only occurs at email level and not API level.

Setting up the Suppliers Module

To do this, you will need to first, ensure that the suppliers module is enabled in both Halo instances. This is achieved by going to the configuration area and clicking the "+" sign on the suppliers module:

Fig 1. Enable suppliers module

Once enabled, you will need to create a supplier record for the instance you want to connect. So in this example, Instance A will be the Halo instance we need to send tickets to via the "Log to supplier" action. When correctly connected, the tickets will go to Instance A from Instance B, meaning that a new ticket is created in Instance A.

Fig 2. Supplier for instance A

The functionality will allow you to log supplier tickets from Instance B to Instance A, and then Instance A can communicate back to the Instance B ticket by using the standard email user action. The reason that the standard email action can be used is because the end-user of the ticket will be under the customer created for Instance B, meaning that the email user functionality is actually using the API, indicated by the URL displayed in the Email User action:

Fig 3. Email user action sending update to instance B

If the customer of the ticket is changed, the API functionality will no longer apply, and emails will be directed to the end-user of the ticket as emails. If your email config is setup with this setting off, Configuration > Email (or Configuration > Email > General Settings if on v2.190.1+).

Fig 4. Remove previous user from email lists when changing user

Then if you update the end-user of the ticket, it will contain both the old user (Instance B user) and the new user of the ticket. Emails will go out using the standard format:

Fig 5. Users that will be emailed once you update end user of the ticket 

It is important to see this URL before emailing back to the original ticket on Instance B, the reason why it is important, is that if you just send a standard email to that instance and both Instance A and B use the default email tags "ID:" then the system may match these emails onto the wrong ticket, causing high impact issues.

Configuring the API Access

In the example, the use case is logging to the supplier (Instance A) from Instance B, hence why you need to creating a supplier in Instance B called "Instance A". 

After creating this Supplier, go to the API Access tab and then check ‘Allow Access’ to your Halo API. it will present you with credentials that you should copy into a notepad:

Fig 6. API access tab under supplier

Save this and do the same on the customer of the other instance you would like to connect to:

Fig 7. API Access tab under customer in other instance 

Creating a client record for the second instance ensures the integration is 2-way, meaning you can send messages back to the ticket.

Again, go to the ‘API Access’ tab, check the box and copy the API credentials into a notepad and save. The way to connect is by adding the API credentials from one instance to the other via the supplier and customer. As shown in the screenshot below, the API credentials on the customer, found under the dropdown "Allow Access to your Halo API" should be the credential inputs to the dropdown "Access to the Suppliers Halo API" found on the supplier of the other instance:

Fig 8. Allowing API access between customer and supplier

After inputting these credentials, you will need to do the opposite for the input boxes on the customer in Instance A. Input the credentials that were created from the supplier found under the dropdown "Allow Access to your Halo API" and then input these credentials to the dropdown "Access to the Customers Halo API" which is found under the customer within Instance A:

Fig 9. Allowing API access between customer and supplier in other instance

Naturally, once you turn on ‘allow access’ in the ‘API access’ tabs, an application will be created in your API applications found in Configuration > Integrations > Halo API > Applications. You should have a Supplier Access application in the instance you are logging tickets to the supplier from (In this case that would be Instance B) and a Client Access application in the instance that you are emailing back into the original ticket from (Instance A):

Within the API Applications of "Instance B":

Fig 10. Supplier access in API application

Then in "Instance" A API Applications:

Fig 11. Supplier access in API applications of instance A

These have the same credentials as the ones you copied earlier into the notepad. Automatically, they will have applied the correct log in type to the applications as well.

Fig 12. Login type of supplier

You can add the supplier and customer functionality both ways, so that logging to supplier can be from either instance. This allows requests to be sent two-ways with seamless interactions.

Add to both the client and supplier records you created on both instances, and make sure to save.

Finally, you’ll need to create an action to send the requests across instances. You can name this what you’d like, for example ‘Send to Instance A’. You will want to set the system use as ‘Log to Supplier’.

Fig 13. system use 'Log to supplier'

Then, in the ‘Defaults’ tab, you can set the default supplier to the one you have created.

Fig 14. Default supplier

The log to supplier action is in the HaloPSA trials out of the box, meaning you do not have to configure an action for this, but if you wish to have a default supplier on the action, you can.

This means, when you use this action button, it will by default, apply the API details to send the communication to the other instance.

Fig 15. Default supplier on action

You will want to add a notes field as a minimum to the action in order to add any messages to send to the other instance. Other fields added, such as status etc, will not populate unless added using $ variables to the note.

When the ticket is logged to the supplier, the supplier details on the ticket type (make sure the supplier field is added to the field list of the ticket types on both Halo's) will be populated automatically with the Ticket ID on the other instance (Instance A):

Fig 16. supplier details on ticket

After the ticket comes into instance A, it will have the end-user as someone from Instance B, and the customer will be the customer created for Instance B. The default "Email User" action can be used to email back into the ticket in Instance B (Instance B being the instance the ticket was logged to supplier from):

Fig 17. Update into ticket from other instance

When the supplier update comes into the ticket, the supplier status is updated to "Supplier Responded".