Creation of new QB Actions and Webhooks will be locked as of  June 30, 2024

Actually creating an Webhook is (well would have been) a great suggestion. He has all the field names, and all the field IDs and the payload of a web hook to add a record is very repetitive pure text, so quick to copy paste edit. 

yes, another reason not to deprecate Webhooks. 

there is also a webhook syntax I have used to create an audit table of fields that have been changed. It uses ImportFromCSV (I think that is the API) to quickly create child record for field name,old value and new value. 

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.

I hate to pile on, but I just had a Pipeline lose 50 "Fields required for subsequent steps", so I will need to add them back now.  I had suggested to my client who built the pipeline that they make backup copies along the way but he didn't.  

I understand why Quickbase would want to get rid of actions, but I'm perplexed why they would want to retire webhooks. Either way this is definitely a step in the wrong direction for several reasons.

1. Lack of Collaboration and Visibility: Pipelines lack the cross-team collaboration and visibility inherent in webhooks. To replace webhooks, pipelines need shared access among admins and a comprehensive view of related pipelines for efficient maintenance.

2. Synchronous Execution: Webhooks offer synchronous execution, ensuring instant response to events, unlike pipelines which might introduce delays.

3. Efficient Bulk Updates: Webhooks excel in handling bulk updates efficiently, minimizing overhead by repeating actions in a single api call.

4. Slow Pipeline Building: Pipeline construction can be sluggish compared to webhooks, potentially hindering productivity in complex workflows. The number of seconds waiting for a dropdown to load or a field to populate really hinders the builders' flow. 

4. Cost Considerations: Webhook calls to outside servers incur fewer costs compared to pipelines, where every HTTP call uses an account step. 

5. API Integrations: Webhooks have a limited, but useful API control via the legacy XML API. There is no such API control for pipelines.

In essence, while Quickbase's decision to phase out webhooks may seem logical from a business perspective, it overlooks crucial functionalities vital for efficient workflow management. Enhancing pipeline capabilities to match the efficiency and performance of webhooks should be prioritized before ending webhook support. It's extremely disappointing that Quickbase has no regard for the kind of technical debt they are creating for their customers who will eventually be forced to migrate all of their webhooks to pipelines.

Quickbase should be working to bring flexibility to the platform and not force everyone into one method with less functionality that in turns puts a heavy load on their customers to make that transition. I think a better explanation as to why this change is being made is warranted and a solution should be provided that doesn't burden the customer.