When a step fails, the retry choice matters more than the retry itself. Running it again blind can repeat the same action twice. So which rule do you set first? Retry only after checking the last state? Wait, then retry once, then park it? Or park it straight away for a human look? I set the state check first. A retry without that check is just hoping the second run behaves better. Which rule would you pick first?

Hey everyone! 👋 I've been working on an offer targeting roofing contractors in the US, and I'd love to get some honest feedback before I start outreach. 💡 Here's my offer: "I help roofing contractors stop losing estimate requests to slow follow-up with instant text-backs for missed calls and automated follow-ups on open estimates, all live in 7 days, without hiring office staff. If the system doesn't help you book at least one additional qualified estimate appointment or job within 30 days of launch, you don't pay." 🎯 I'd love your thoughts on a few things: 1. Is the problem I'm solving painful enough for roofing contractors to pay for? 2. Is the offer clear and compelling, or does it sound too technical? 3. Does the guarantee make the offer stronger, or should I rethink it? 4. What would you improve before taking this to potential clients? I'm trying to build something that solves a real business problem rather than just selling automation for the sake of it. 🔥 Don't sugarcoat it. I'd genuinely appreciate honest, constructive criticism. Thanks in advance! 🙌

Been thinking about something Ali mentioned in a conversation here: false positives in lead qualification. Honestly, this is where things can get messy. A lead matches the ICP, the company looks right, and the job title fits, so the system scores it highly. But none of that tells you whether they actually need the service. I think the tricky part is knowing when the system has enough evidence and when it’s just making a good guess. For those who've built lead qualification workflows, how do you handle that line?

Here’s a scenario. You build a workflow, it works in testing, you hand it over, and a week later an API changes or a login expires. The workflow quietly stops, and nobody notices until a client asks why no leads came through. n8n has a built-in fix that takes about five minutes. 1. Create a new, separate workflow and start it with an Error Trigger node. This node fires whenever another workflow fails. 2. Connect it to something that tells you, like an email, Telegram or Slack message. Include the workflow name, the error message, and the link to the failed execution. The Error Trigger gives you all of those. 3. Open your main workflow, go to its settings, and choose that workflow as the Error Workflow. Now any time your main workflow breaks, you get a message with exactly what failed and where, and you can fix it before anyone else notices. One thing that trips people up: this only fires on live, automatic runs, not when you click “Test workflow”. So don’t panic if your test failures don’t trigger an alert. You can use a single error workflow for all your automations, so you only build it once. If you ever do client work, this is one of the easiest ways to look reliable. My personal experience : At the start, I intended to implement all workflows of a project in a single canvas but faced difficulty in finding where it went wrong and later I created different workflows. When something failed, I knew which stage it was in straight away, instead of searching through one huge canvas for the broken node and created a small error workflow to log/monitor and alert when something failed. Smaller workflows are also easier to test, update and hand over. Do you currently have any way of knowing when your workflows fail? Tell me in the comments, and if you don’t, set this up today.

When I started in automation, I kept seeing “build AI agents!” everywhere, and I thought that was where everyone should begin. After building real projects, I think beginners should start with workflows. Here’s the difference in plain words. A workflow is a fixed path that you design: when X happens, do A, then B, then C. You decide every step. An agent is different because you give an AI a goal and some tools, and it decides which steps to take, in what order, and when it’s done. Agents sound more exciting, but they’re harder for a beginner to learn from, for three reasons : 1. They’re unpredictable. A workflow does the same thing every time. An agent might take a different route each run, so when something breaks, it’s hard to know why. 2. They hide the basics. Triggers, APIs, passing data between apps, handling errors, and retries are the skills that make any automation reliable. A workflow forces you to learn them. An agent lets you skip them until they bite you later. 3. They cost more and can go wrong. Agents can loop, make wrong decisions, and burn through API credits. A mistake in a workflow is usually easy to spot. A path I’d suggest : - Step 1: Build simple workflows. For example, a form submission goes to a Google Sheet, then triggers an email alert. - Step 2: Add one AI step inside a workflow. For example, AI reads an incoming enquiry, classifies it, and your workflow routes it. You still control the path, but AI handles the messy part. - Step 3: Once you’re comfortable, try an agent for tasks where the steps really can’t be known in advance, like an assistant that decides whether to search, reply, or escalate. Most real client work I see is a solid workflow with a few AI steps inside it, not a fully autonomous agent. Agents are great, but a lot of people reach for them when a simple workflow would be faster, cheaper, and more reliable. So the answer isn’t “workflows are better.” It’s that workflows are the best foundation, and agents are much easier to build well once you have it.