Update on the retirement of Application Webhooks UI and QB Actions

Will there be a migration tool provided like Automations migration to Pipelines?

Webhooks are faster and easier to setup than Pipelines 

When writing a Webhook, the process looks like this. Open the Webhook, write the Webhook, test the Webhook. Takes no time and little effort.

With Pipelines users have to log on to a service account in incognito mode. Then go through an arduous process of waiting for drop down lists to load and dragging little images around on a screen, etc etc... it's too many layers of abstraction for anyone who knows how to write a Webhook. 

Until the Pipelines process is as fast or faster than the Webhooks process, there is little to no value in using Pipelines.

Webhooks still have great value and it is a mistake to remove them from the rich feature set Quickbase has to offer.

Completely agree with all the comments. Getting rid of Webhooks would set Quickbase back, not move them forward. 

Like Jim said, webhooks are SO much easier to create, especially for quick, simple needs.

As all others mentioned, their 'instantaneous' nature is what sets them apart from Pipelines. Based on the nature of Pipelines, I don't foresee them ever catching up and functioning in the manner of of Webhooks. For my use cases, this is the most striking difference, and most necessary need for webhooks.

Not mentioned yet is simple organization. It is quite often that I need a very very simple automated feature. 'If a new record is created, create a record over here.' Or perhaps 'when a record is saved, copy this formula field to this scalar field.' While Pipelines could obviously handle these, having an extra 100+ Pipelines to accomplish this, is a organizational mess.

I don't use it yet, but for more advanced development, as other mentioned (integrating from Workato etc), this crushes that functionality.

I cannot come up with a single positive to removing Webhooks, so I would be curious to hear from QB Development team, what advantages they see to removing Webhooks as an option? Perhaps if we had more context we would be able to better understand.

I just want to applaud Jim's comment (everything is SPOT on) and add one more thing.

One thing he didn't mention with Pipelines is: Once you finally get it built, you refresh the page only to find out, 'Surprise! Half your work did not save.' Alternately, you know the darn thing won't save so you check your work halfway through by pushing 'Refresh' to see if it gives you the 'Are you sure you want to navigate away dialogue box' (indicating it has not been saved). Then you sit there, not knowing what to do because your Pipeline is clearly not saved, but you have no way of forcing the issue. Then, suddenly it tells you 'oops, looks like you are offline!', and you lose your work anyways.

Please listen to Jim, because his experience is all of our experience. And I really want to highlight and reiterate 'New Style Forms aren't working, New Style Reports aren't working'.....'Pipelines is half working'.

The one thing Developers have been shouting over and over is: 'We love the advances you are trying to make. We support and encourage innovation. We love Quickbase. But please, please, please don't remove working and beloved features until you can confidently say the replacement is as good or better.' There may be no more striking example than Pipelines and New Forms to say 'These things have a lot of potential, but are a long ways away from being able to eliminate Webhooks and Legacy Forms' (Thankfully, nothing has been said about eliminating Legacy forms).

The one big missing feature of Pipelines is the ability for developers collaborate.  Will that be addressed prior to June? Actions and Webhooks are maintainable by all Admins in an App.  Not so Pipelines.

I agree with Mark and would add that the in-table Webhooks run MUCH faster than using a Pipeline which leads to a much nicer user experience. In most situations, the Webhook has already run by the time the single-record is re-displayed. This often means an embedded report shows updated data without having to do an extra refresh. It would be really nice to keep the in-table Webhooks feature.

The main use case of webhooks is the consolidated triggers that help to handle bulk operations better. In Pipeline, I don't see any option to have one single trigger when bulk insert of update happens. 

I sometimes call the pipeline after creating a bulk upsert log through a webhook. I'd like to know if there's any pipeline alternative that exists.

I’m not so concerned about Quickbase Actions, I think I have two, but we use a lot of webhooks. To get rid of webhooks would be a HUGE downgrade, as webhooks are immediate and good for completing simple, instant actions. Pipelines can still take a while to trigger and cannot do immediate actions. This will cause workflows to pause, and users to have to keep reloading a page to see if an action has occurred. Lately we have even increased our usage of webhooks for adding templated items such as tasks on a project, invoicing headers and line items, and change logs/audit logs. With pipelines a user won’t be able to add a project and immediately see the tasks when the page reloads. They’ll have to sit and wait for pipelines. This will also cause issue with Quickbase released apps in the exchange, such as Ryan Pflederer’s App Library, which uses webhooks to manage schema changes.

Agree 1000% with what has been said here thus far.

Brian - If you take 1 thing away from what we are saying here, it's that rather than spending development effort is taking away functionality, your customers are screaming for the replacement solution (pipelines, new forms, new reports, etc.) to work how we know they can and should.

I'm not sure how development resources are allocated, but for things as important as pipelines and forms, there is no use in creating them, leaving them 50% functional, and moving onto something else.

There are "nice to haves", like a New Exchange, AI Smart Builder, ACC tables, and there are "ABSOLUTELY NEED TO HAVE YESTERDAY" like pipelines and new forms working 100%.

Each month we see release notes for items that don't address the REAL needs that the hardcore users have. The ones who create the applications, who answer questions for the community, who drive this thing forward.

I'm sure I speak for everyone in saying that we really appreciate the outreach to the user base, but we'd like to see more response to the biggest issues we are facing.

I second everything that's been said here. The decision to phase out actions and webhooks seems to entirely disregard the user experience of building pipelines on a large scale and the massive level of frustration that comes with it.

I use pipelines for one and only one reason; when there is absolutely no other way to accomplish my goal. If it can be achieved via actions, webhooks, code pages, or even a third-party tool, I'll utilize those features over pipelines without hesitation. Why? Because, in actions and webhooks, my work will be reliably saved and my changes won't unexpectedly revert. I will not have to wait 10-20 seconds each time I want to add a new field. My action/webhook won't unexpectedly crash after spending hours perfecting it, and when there is a failure, I will be reliably notified. I don't need to worry about my action failing when I change a field name. I can easily access my actions and webhooks within my app rather than opening pipelines in the shared developer account and searching through hundreds to find the one I'm looking for. If I'm lucky, I remembered to tag it.

While the new pipeline builder does improve on some of these issues, it is far from where it needs to be, and it's shocking that those involved in this decision believe that we are anywhere close to ready for this change. The autosave feature is still unreliable, and it is just as likely to fail/crash for no discernable reason. The loading time to retrieve apps, tables and fields has not noticeably improved, as and many others have mentioned, neither has the trigger time. I'm also finding field usage reporting to be inaccurate even after the long-awaited improvements were made.

I sincerely hope our shared experiences and frustrations are taken into account, and either the decision to phase out actions and webhooks is rolled back, or the necessary improvements are made to pipelines well before the end of sale date.