How do you connect a Webflow form to your CRM now that Logic is gone?
A lot of the advice still ranking for this recommends a Webflow feature that was switched off. Here are the routes that still exist.
This is a question where a good proportion of the ranking advice is simply out of date, and the failure mode is quiet: you follow a guide, look for a feature in the Designer, and cannot find it. The feature is not hidden. It was switched off. Knowing that saves an afternoon, and the routes that remain are straightforward once you know which ones they are and what each one costs you.
What happened to Webflow Logic?
It was disabled on all Webflow sites on 27 June 2025, having stopped accepting new activations on 31 January 2025. Logic was the built-in automation feature: you could trigger a flow from a form submission and have it perform actions, including calling an external service, without a third-party tool. Webflow retired it alongside User Accounts. Forms that had been connected to a Logic flow reverted to ordinary Webflow forms, which is the detail worth pausing on, because an ordinary form still accepts submissions and still stores them. It simply stops doing anything with them afterwards, and nothing about the front end changes to say so.
How do you tell whether this affected you?
Submit your own form and then check whether anything downstream received it, because the front end will look correct either way. A visitor filling in the form still sees the success message, since that is produced by the form itself and not by whatever was supposed to happen next. Send a test through every form on the site and confirm it arrives wherever it is meant to arrive: the customer system, the notification inbox, the spreadsheet. Do this quarterly regardless of any platform change, because integrations break for many reasons and none of them announce themselves on the page.
What are the routes that still work?
Three, and they differ mainly in who you depend on. An automation platform sits between the form and the customer system, catches the submission and passes it on, which is the fastest to set up and adds a monthly cost and a third party. A custom endpoint means the form posts to a small service you control, which then does whatever you need, giving you full control and requiring a developer. A form provider that speaks to your customer system directly replaces Webflow's form handling entirely, which removes a hop but moves your form data to another vendor. There is no wrong answer; there is a choice about where the dependency sits.
Which one should a small team pick?
An automation platform, in most cases, because the thing you are optimising for is not elegance but the ability to fix it yourself at eleven at night. These tools show you every submission that passed through, let you replay a failed one, and can be repaired by a marketer without opening a code editor. That operational quality is worth more to a small team than the monthly fee it costs. Move to a custom endpoint when the volume makes per-task pricing uncomfortable, when the logic outgrows what a visual builder handles, or when the data should not sit with an extra vendor.
What happens when the connection fails?
By default, nothing visible, and that is the part worth designing deliberately rather than discovering. If the customer system is down or a credential expires, the visitor still sees a success message, because the form succeeded even though the delivery did not. Decide in advance what the fallback is: at minimum, an email notification on a separate path so a human still learns a lead arrived, and ideally an alert when a delivery fails rather than a silence that looks identical to a quiet week. Ask about this specifically when anyone quotes you an integration, because a quote for the working path is a quote for half the job.
Does any of this change how the form should be built?
Yes, in one respect that saves trouble later: name your fields for the system that will receive them, not for the layout. A field called Field 3 is fine until somebody maps it into a customer record and has to guess what it holds. Consistent, descriptive field names make every downstream integration simpler and make the eventual migration to a different tool a mapping exercise rather than an archaeology one. It costs nothing at build time. It is also worth keeping the number of fields to what you will actually use, because every field is one more thing to map and one more reason for someone to abandon the form.
