Smarter webhooks: precise subscriptions, Test and Live mode, and richer messages
working on it
Kamal Saran
We're reworking how Enate webhooks work, so your integrations get only the events they need, with enough information to act on each one without calling back.
What we're planning:
- Subscribe to exactly what you need. Narrow a subscription by Customer, Contract, Service, Service Line, Case or Ticket Type, Process, work item type and Action Type. All the filters must match. You can also subscribe to a single work item.
- Subscribe by Action Type. Get notified when a specific Action Type is created, with subscriptions that keep working when a new process version goes live.
- A closed event. Be notified when a work item is resolved and closed, as well as when it's created, updated or receives a new communication.
- Test and Live kept apart. Each subscription belongs to either Test Mode or Live Mode, and every message says which mode it came from, so test work never reaches a live integration by mistake.
- Richer messages. Each message says what happened, where the work item sits (customer, contract, service, process, state, due date, RAG status) and, for an update, which fields changed. Messages never include custom data values, email bodies or files.
- Configuration events. Webhooks for configuration changes, not only work items.
- Safe for existing integrations. The new behaviour comes through new subscriptions that name a message version. Your existing subscriptions keep working exactly as they do today.
Good to know: Enate doesn't guarantee the order in which messages arrive. Each message carries the work item's last-updated time, so you can put them in order.
Tell us in the comments how you use webhooks today, and which events and filters matter most to you.
Kamal Saran
Merged in a post:
Webhook messages for categorizing packets
S
Sarvesh babu
As a end users, we would like to have Webhook messages for categorizing packets. This helps us to ignore few of irrelevant notifications.
As Enate triggers webhook notifications for overdue work items for first seven days and need to ignore the same by knowing category of webhook notification.
Kamal Saran
Merged in a post:
Extend Webhook Notifications - specifically for Closed Processes
Hi Team,
Can you please advise if we can quickly get an update implemented to the Enate Webhook notifications so that we can subscribe specifically to get notifications of when a process is Closed.
Currently it’s only on Created and Updates but no specific option to subscribe to get closed notifications.
Current functionality explanation as per Enate help: How to work with Enate's Webhooks | Enate Help
"FilterObjectGUID"
Mandatory field, identifying GUID for whatever object type (FilterObjectType) is required.
• For PacketCreated the FilterObjectType can be either Company, Contract or Service.
• For BusinessObjectCreated it can be either Schedule or Company
• For PacketUpdated or NewCommunication it can only be a Packet (Case/Ticket Process)
Can I ask that this be implemented if not already available
Thanks
Paddy
Kamal Saran
Merged in a post:
Subscription based on Action Type
A
Ankit
Currently, we can subscribe to notifications at a case attribute level (packet create and packet update), meaning any action triggered within a case generates a notification.
We'd like to request an enhancement to introduce subscriptions based on action type as well. Within a case/process, if I subscribe to a specific action type (not an action attribute, as it changes everytime process is updated), I should get notified whenever that particular action is created/triggered. This would be a much better use of system resources, since I'd only need to specify the action type I care about within the case, rather than getting notified for every action and filtering through to the correct action.
It would also be useful to subscribe to an action type independent of any specific case so that wherever that action is used across different processes, I'd receive a notification whenever it occurs, regardless of which case or process it belongs to.
Kamal Saran
updated the status to
working on it
Andrew Teece
The Packet related webhook messages are as you point out for created and updated. The status field is in reality a piece of metadata, a field that is updated, as such the event that occurs is PacketUpdated.
So it does not fit within the design to have a separate event for the Status field of a Packet changing.
The contents of the message sent to consumers of the PacketUpdated event includes the Status, so they can quickly disregard messages that are not for the Closed status.
While allowing filtering of the PacketUpdated event to limit the raising of web hook messages to only trigger when particular fields are updated, or more specifically if particular field is updated with a particular value this is not currently planned. Our view is that this would make integration more efficient, however that efficiency would not result in a resource/cost saving in most consumption-billed consumers and wouldn't result in any cost saving if the receiver billed simply by available uptime. As such the consumer wouldn't benefit from a meaningful cost saving, so it does not justify development - it would be an efficiency for efficiency sake.
C
Claudine Richardson
Hi
Thank you for taking the time to post this — it’s really helpful. We understand the need to be able to subscribe to a specific webhook notification for when a process is Closed (in addition to the current Created/Updated events).
We’ll review this internally and come back to you with an update. If you can share which webhook event/object type you’re using today (e.g. PacketUpdated for Packet/Case) and the specific “Closed” status you’re looking to trigger on, that would help us investigate.
Thanks again for flagging this.