Testing in no-code

The last issue had broken links due to an oversight on my part. I deeply apologize for that and will try my best to double check from here on out.

A note on timing, I’m going to commit to publishing this newsletter and host livestreams every 2 weeks! Both will drop on Wednesdays with the newsletter coming in the morning and the livestream at 5PM EST.

Today, I’ll be showing off 5 cool things you can do with the new Airtable button field including searching the web using, sending Zapier webhook’s, sending email reminders and create receipts.

On to the update:

Heyo!

I’d like to posit a new law that is as you include more no-code tools in your tweet, the odds of me receiving it increase proportionally. Case in point, someone shared this fantastic tweet with me from the founder of Actiondesk (note: haven’t used the tool) and it sparked all kinds of thinking

This is absolutely an issue.

I’ve found myself in so many workflows thinking, am I going to break something if I click here? Or is this stitch of tools going to output what I expect it to? How do I ‘test’ whether it does without risking a run?

More personally, if you’ve been an Automate All the Things subscriber for long enough, you may remember the time where I sent you and everyone on the mailing list a ‘test’ email. Every day. For a week. I still cringe thinking about it.

As no-code tools multiply, the problem is only getting worst.

Here’s folks showing off their ‘complex’ Integromat workflows, most with 100+ steps.

Testing in no-code seems to mean broadly three things:

1- Can these tools support the desired workflow? Can I do what I want to do?

2- How will the workflow handle errors?

3- How do we provide visibility to folks in our tools that they may be triggering workflows?

When it comes to whether something is possible without code, we have to check whether our glue – Zapier, Integromat etc. – supports the different actions & triggers we need. Zapier probably does the best job of this with their app directory.

There really is no other way than being intimately familiar with the tools you’re using to know whether a workflow is possible using no-code.

I’d love for an entrepreneur to create a draw.io type diagram creator that depending on the tools you want to connect and the expected workflow, tells you whether it’s possible. That said, like many of you I’m sure, my workflows are rarely so complex from the get go that I can’t just give it a try.

Out of the three, I think mainstream no-code tools perform best here. Zapier will automatically notify you when Zap breaks and offers granular settings for when to be notified.

Beyond that, Integromat has error handling built in so you can fork your workflow based on the error itself.

Parabola isn’t great and breaks when any API it’s working with throws an error. They’re aware that it’s an issue and I’ll definitely keep annoying them until they have better error handling!

Just like #1, handling errors more gracefully is an opportunity for entrepreneurs! Take Chris Spags from Jetboost which builds add-on features (Boosts) to Webflow. Their next Boost will replicate something you could do with Zapier (with a lot of difficulty) but at a much cheaper price point (why pay for Zapier if all you need is one flow?). And his Boost will handle Webflow specific errors gracefully! The effort for Zapier to handle Webflow errors gracefully in every case isn’t important enough for them to prioritize which means an opportunity for folks like Chris.

Personally, I think this is the biggest issue!

I’ve become more and more reliant on multiple tools working together to get my workflow done. For me, it’s usually a change in Airtable being synced with multiple 3rd party. As I update information in my Airtable base, Zapier’s new record in view trigger will cascade that change into multiple third parties automatically (set to publish in Airtable -> send to Webflow).

If a new collaborator comes into my Airtable base, they have absolutely no visibility into what workflows are triggered when. Hell, I sometimes inadvertently trigger workflows from my own base without realizing it!

The only available remedy is good documentation. It could be emojis in view descriptions or field descriptions letting collaborators know that changing information could trigger a workflow. There is no visibility of tools into each other. Every no-code today stands on its own.

I’m no developer but I would love to see folks build tools that increase visibility across no-code tools. A few ideas to get you started:

In all cases, although we’ve integrated many tools, we’re not quite at the point where we can understand what’s going on outside of the tool we’re in.

That said, the only thing stopping us from being better at testing is building the tools we need!

Best

Aron

PS if you’re interested in building on top of Airtable, we’ve just released our beta SDK so you can build your own block. We’ve also hosted a Blocks contest with 100K in prizes and will release the winners shortly :)