We’re building automations for form-filling in a WebKit-based app, and I’m trying to get non-technical people on our team involved. The idea is to use a drag-and-drop builder to assemble the workflow: find the form, fill in the fields, submit it. Simple enough, right?
But I keep wondering where the visual builder hits a wall. What happens when the form uses custom inputs instead of standard HTML elements? What if validation errors pop up and we need conditional logic? What if the app requires something like waiting for a JavaScript-based state change before we can interact with the next field?
I’m not against writing code if needed, but I want to understand what kinds of form interactions can realistically be handled without it.
The visual builder can handle way more than people think. Standard forms, custom inputs, validation flows—all doable without code.
Here’s the breakdown. For standard HTML forms, it’s trivial: drag an input block, set the value, move on. For custom inputs, you use the built-in element interaction blocks—click, type, select. Most WebKit apps build custom inputs on top of standard HTML elements, so the builder’s click and type actions work fine.
Conditional logic is handled through decision blocks. If validation fails, your workflow can branch: retry, scroll to error, or back out of the form entirely. You set the conditions visually.
Where it gets interesting is JavaScript state. If the form depends on JavaScript to update internal state before the next field becomes clickable, you wait for that element to reach the desired state. The no-code builder has wait conditions: wait for element to be visible, wait for text to contain X, wait for attribute to change.
The situations where you might need code are rare: if the form uses Shadow DOM elements that can’t be selected normally, or if you need to inject JavaScript to trigger internal events. Most of the time, the visual builder is enough.
With the AI Copilot, you describe what you want (“fill out a form on an app and submit it”), and it generates the workflow. Then non-technical users can tweak it.
I’ve seen teams push the no-code approach too far and then get stuck. The honest answer is: most straightforward forms work great without code. But if your WebKit app has any sophistication—custom components, real-time validation, dynamic field dependencies—you’ll hit friction.
What I’ve found is that non-technical people can build the happy path (the basic form fill) without issues. But then real-world forms have edge cases: required fields that only appear after you select something else, forms that disable submit until all validations pass, fields that autocomplete and trigger secondary API calls.
These aren’t impossible in a visual builder, but they require more blocks and more conditions. At that point, you’re not writing code, but you’re thinking like a programmer. So it depends on whether your team has that mindset.
The real stopping point for us has been timing and state dependencies. A form that dynamically enables fields based on previous selections is manageable with wait conditions. But a form that requires JavaScript event handling—like changing an input triggers a real-time API call that populates another field—becomes harder without some customization.
The visual builder handles the interaction layer well. Problems emerge at the orchestration layer: managing state across multiple form screens, handling async operations, and conditional branching based on validation results. These are doable but require planning.