Sending Webhooks using rules in Jadu CXM
We are pleased to announce the release of an exciting enhancement to our webhooks feature within Jadu CXM, which opens more possibilities for you to use your data, and makes webhooks easier to work with. If you want to know more about webhooks then you might find it useful to read our previous post - ‘What are webhooks?’
Over the past few years, we have seen more customers adopting webhooks to push data into third party systems as a way of achieving two-way integrations and other use cases, such as to capture data to meet reporting needs. Until now it has only been possible to push data for all your case types for a given webhook, for example a ‘case created’ webhook will send data for every case created in your system. This means that you need to handle the webhook externally to discard data not relevant to your use case. In addition, you may not want to send certain data for certain case types to an external source for data security reasons.
To solve these challenges and add new possibilities for integrations, we have introduced the ability to fire a webhook as part of a CXM rule. This gives you more event options for triggering a webhook, the ability to apply conditions and to specify an individual case type to send the webhook for.
What does this mean?
One example is that you can now push data for the ‘case field value changed’ trigger. In addition to a case transition, it makes it easier to keep third party systems or external databases up to date, and reduces the need to poll the CXM API for updates to cases. Another benefit is that you can now push webhook data based on various date triggers when a user is assigned to a case, or when a message is sent by an end-user.
How does it work?
Setting up a new webhook to be sent by a rule is easy! Simply go to Settings > System > Webhooks and create a new webhook selecting ‘Triggered by rule’ as the ‘Event trigger’.
Next go to your case type in Settings > Workflow, open a new or existing rule and select ‘Trigger webhook’ as the action, then select the desired Webhook.
Triggers and context
We have added context data relevant to the trigger that you select which you might find useful. For example, the ‘case field value changed’ payload will contain the original field value and the new field value. The ‘membership added’ (new user assigned) trigger will include all the details of the user or group being assigned to the case.
Using rules-based vs. global webhooks
We believe that in most scenarios you will want to send webhooks for a specific case type and so the rule action rather than the global webhook will be appropriate. You may decide to use the global webhook if you need to send data about ALL case types and do not want to configure the rule action too many times! But please note that this will send data for all case types. This, of course, does not apply to the user-created or updated webhooks which are only global.
Technical note for migrating from global to rules-based webhooks
If you want to set up rule-based webhooks to replace existing global webhooks please bear in mind that there are a few differences in the content of the payloads that you’ll need to account for. The "context" and "trigger" objects in the payload contain extra data that in existing webhook triggers, would be in the root of the payload object.
For example, the existing case transition webhook trigger has "transition", which would now be inside the "trigger" object, "transitioned_by" which is now "initiated_by" and "previous/new_status" objects which are now inside "context". To see the differences you can compare the payload from the existing transition webhook with the new rule-based one webhook payload.
If you're interested in learning more about how to utilise your Jadu CXM platform in a masterclass, receive a CXM usage audit, or have any questions, get in touch and book in time with James Kocherhans, Senior Consultant at Jadu who will be happy to help.