Exalate & Zendesk Sync: What's it really like?

If you Google 'Sync Zendesk with Jira' you'll quickly discover hundreds of helpful step-by-step guides using a sync tool called Exalate.

Digging deeper you'll notice just about all of them are promotional or affiliate-driven (this is not one of them.)

Take nothing away from Exalate, affiliate marketing is hugely impactful but the problem is that these guides are almost carbon copies of each other and only ever really touch the surface of a basic sync of a handful of standard fields.

Exalate is a powerful and flexible synchronization tool used to integrate various issue trackers, project management, and ITSM systems. It enables bi-directional synchronization between different platforms, facilitating seamless collaboration and data sharing across teams and organizations.

Exalate Modes

Most use cases will require something more complex than the basic mode and Exalate offers this too. At the time of writing, there are 3 modes to choose from (one of which is in beta).

The three different sync modes of Exalate

Basic Mode

This is the one included in the free plan and is highly restricted. It kind of 'just works'. As an example, when setting this up between Zendesk and Jira Exalate will sync basic issue fields. The sync rules cannot be updated. Exalate will sync the following issue data: summary, description, comments, and attachments.

Issue types are mirrored. This means that tasks will be synced as tasks, bugs as bugs, and improvements as improvements. If an issue type is not included in the basic set, it will be synced as a task.

Just about anything beyond basic syncing including the ability to automate the syncing will require a paid upgrade.

Visual Mode

This mode is a nice upgrade from Basic and at first, it seems that it really only works for simple use cases. But, conspicuously tucked away in the connection configuration screen is an 'Add Script' option which basically exposes you to the full Groovy script capabilities of Exalate employees under the hood.

Script Mode

And then there's the mode most of us will end up using, Script Mode. This is where we can connect and control both sides with incoming and outgoing Groovy scripts allowing advanced ETL operations which can also leverage several helpers provided by Exalate for the most complex of sync operations.

It all sounds great, so what's the problem?

Having used Exalate for more than a year now, I see a few challenges:

Basic mode is too rigid and visual mode is in beta still so let's focus on script mode which is what I've been using mostly. In theory, we should be able to do just about anything within the capabilities of Exalate so it's a good yard stick.

I've been using Exalate between Zendesk and Jira so that's what these challenges are based on. I plan to use it with ServiceNow and Salesforce very soon and will update my findings after those integrations.

Challenge #1: Debugging is really difficult

Debugging Errors Like This Are Really Challenging

When building a script-based integration there will naturally be problems.

That's especially true when we need a lot of data transformation using the inbound or outbound scripts on one or both sides. The issue here is that Exalate does not have the ability to output debugging info, errors and exceptions to a console on either the Zendesk or Jira side. This means we're depending on the built-in error information visible from the sync queue or connections screens which essentially point you to the line your script is failing on.

Beyond that, you can generate a zipped exalate_support_zip file which contains the same errors found via the console and a bunch of other info unrelated to the errors.

Here are a few tips to help with managing errors.

Align your field types on both platforms

Ensure your field types and values (in the case of multi-select type fields) are as closely aligned as possible on both sides of the integration before you start. This preparation will save you a lot of hassle and will often save transforming the data during the sync.

Debug into a dedicated field

I created a hidden text field on my Zendesk instance to output debugging information to. I use this field to output as much of the payload as needed (converted to text if necessary) so I can see exactly what's trying to sync in the event of an error with a particular field.

Build exception handling into your Groovy script

Every single mapped field should have exception handling! If it doesn't you are asking for trouble. At a minimum, your script should be handling null values as well as non-existent values at the target.

Challenge #2: Migration is not supported

Our primary use cases for using Exalate were:

1) two-way sync of new tickets from Zendesk to Jira

2) migration of issues from Jira Service Management to Zendesk.

It was only later we discovered that Exalate does not support the migration use case and, in fairness, they don't market the product towards migration at all.

They did however say it's possible and after much effort, we got an acceptable script built to migrate thousands of Jira issues into Zendesk.

It took a long time, a lot of data cleansing, and a LOT of script errors. In hindsight, we may have been better off using other migration services or even doing a manual extract, transform and load using other tools.

Challenge #3: Justifying The Need If Using Script Mode only

We do consider often that if we are writing scripts all day long to sync or migrate data, why do we need Exalate? After all, it's supposed to be easy and that's how it's marketed.

In theory, if we did want to use scripts we could leverage the Zendesk and Jira API, write those scripts in another language (sorry Groovy), host them in our private cloud and get the same or even better results.

If you have competent enough developers with the right skills then it may be a more attractive solution, you'd own the IP, most likely address the challenges above and save on Exalate's fees.