In my experience a feature that goes EoS eventually makes its way to EoL.
Moving away from Webhooks, a fairly simple and expedient way to trigger workflows, and into Pipelines (more complex), does not seem like a lean solution. If the focus is on removing duplication within your own product offering, then this makes sense. If the focus is on offering your clients flexibility to integrate QB into their overall tech stack, this doesn't make sense. Looking for QB to provide the user base more background as to why this is a good thing for users.
Also, will QB be offering a migration tool/automation to move our existing webhooks and QB Actions into Pipelines, similar to what was offered for EoL of QB Automations?
Our team has done some testing with building the same workflow in Pipelines vs Workato, and so far we're sticking with Workato as our primary automation platform.
@Jon - I agree with everything you said.
We're in the same boat. Workato is our primary automation platform. This update means that Workato will completely lose the ability to programmatically create table webhooks for real-time recipe triggers.
This is a huge loss of functionality and convenience that can't be understated. Routing will either have to go through manually created webhooks, a Pipeline message queue, or become timed queries.
I'm interested to know if you have any other ideas on how to work around the loss of webhooks for Workato integrations. Would be happy to compare notes.
Hi Gary, I wanted to clarify that this change will not disrupt workato workflows. I will add that to the community post.
Brian, you've made my day, thank you!
Actually, before I start celebrating, are you saying new Workato recipes created after EoS will work? Or are you referring only to existing recipes prior to EoS?
