I take leads and store it trello business board. i have three lists there. i tried to create a scenario for these three lists but i get error while trying to run it. i need support to fix the error
Hi @sri_shanmugapriya_me, welcome to the community, I can help with this, syncing Trello lists through a Make.com scenario and fixing run errors.Let’s connect
Upwork: https://www.upwork.com/freelancers/~01446d60f782215efa
Website: https://www.pathfinderautomationsolutions.com
Calendly: Calendly
Email: [email protected]
Taiwo
Could you open the failed run in Scenario History and share the exact error message, the failed module, and its input/output bundles? The screenshot only shows the scenario structure, so without the execution details we would just be guessing.
Hey, can you share the exact error you’re getting and which module it happens on?
A screenshot of the scenario would help too.
Also, are the 3 Trello lists supposed to trigger different WhatsApp messages, or basically the same flow?
Hard to tell what’s breaking without seeing that part, but it might be something simple in the routing/filter setup.
Hi Sri — I can handle this as a bounded workflow-rescue engagement.
Before changing the scenario, I’ll review the failed execution in Scenario History, identify the failed module and data contract, and preserve a backup of the current workflow.
Fixed scope: USD 175, delivered within one business day after access and failure evidence
- Diagnose one Make scenario of up to 12 modules.
- Repair the Trello-to-WhatsApp critical path for the three lists.
- Add explicit error handling and duplicate-send protection.
- Test six synthetic cards (two per list).
- Provide a concise change log and handoff walkthrough.
Acceptance: one new card in each list produces exactly one intended WhatsApp action—or one clear logged failure—with no duplicate sends.
Excludes: WhatsApp number/provider/template approval, unsupported browser automation, platform/subscription charges, new scenarios outside this path, and ongoing support.
Three details will let me confirm the repair immediately:
- Are the three Trello lists intended to send different messages?
- Which WhatsApp Business/provider module is used?
- What exact error, failed module, and redacted input/output bundle appear in Scenario History?
I lead AI Firm, an engineer-led AI and automation deployment practice: https://aifirm.app
Best,
Arda
I can take this as a bounded written fix rather than guessing from the scenario screenshot.
For USD 150 fixed, delivered within one business day after one sanitized failed run, I would:
• isolate the failing module and read the exact Make error plus request/response bundles;
• verify the three Trello-list routes and the WhatsApp message mapping;
• repair the smallest failing path or return the exact API/permission blocker;
• replay one sandbox case, add a duplicate-safe key and make rejected runs visible;
• leave a short repair and maintenance note.
Done means one redacted Trello lead reaches the intended route or the blocker is evidenced precisely, with no silent failure. No credentials, customer data or live WhatsApp sends are needed for the first pass; production access and outbound messaging stay behind written acceptance and protected payment. If this is still open, send the failed module name, exact error text and a redacted input/output bundle. Written async is fine.
Hi Sri,
Three lists feeding one scenario is where this usually breaks, and in my experience it is almost never the module the error points at.
The two most common causes in this exact setup:
- The trigger only watches one list. Trello’s watch module is bound to a single list ID. With three lists you need either three triggers or one polling module over the board with a filter. Mixing the two silently drops cards from the other lists without raising an error.
- The card fields differ between lists. If a card in one list has no description or no due date, the WhatsApp module receives an empty value where it expects text and fails at the send step, even though the real problem happened upstream.
So rather than guess from the screenshot, the first thing I would read is the input bundle of the failing module, not the error message. The error tells you where it stopped; the bundle tells you what actually arrived. In my own pipeline I documented a defect where every test passed and the bug lived in a branch no test ever exercised. It was found by reading the data, not the error.
USD 90 fixed, delivered within one business day of getting access to the scenario, paid on acceptance after it runs clean across all three lists.
Honest note: my documented automation work is in n8n, not Make. This is a debugging job rather than a platform-specific build, and the transferable part (webhooks, bundles, error branches) is real. Full write-up and workflow JSON: GitHub - davidbertorello82-boop/enterprise-content-ingestion-pipeline · GitHub
David
I’d be happy to help troubleshoot this.
From the setup you’ve shared, the overall approach makes sense: pulling the leads from the relevant Trello lists, routing them based on the list, and sending the appropriate WhatsApp message while keeping the records synchronized.
Since you already have the scenario built, I’d first review the failing module and the data coming from each Trello list rather than rebuilding the workflow from scratch.
A couple of things would help me understand the issue:
• What error does Make show when you run the scenario?
• Are the three Trello lists using the same lead structure, or are there differences between them?
If you share the error screenshot or a screenshot of the module where the scenario stops, I can take a closer look.
I’ve also sent you a DM with my details.
Hi Sri — since the scenario already exists, I wouldn’t rebuild it. I’d start from the failed execution and compare the input/output of the failing module for one card from each Trello list. That should show whether the break is in the list routing, uneven card fields, or the WhatsApp step itself.
Once it’s reproduced, I can fix the smallest failing path and test the same scenario against all three lists so it doesn’t only work for one card shape. I work with webhooks, APIs and data flow, so I’m comfortable treating this as a bounded debugging task rather than a new build.
If it’s still open, send the exact Make error plus a screenshot or redacted input/output bundle from the failed module, and I’ll tell you what I’d check first.
Sri, before changing the filters, confirm what event should trigger the message: a card created in a list, or an existing card moved into that list. Those are different Trello events, and a scenario that watches new cards can miss list moves even when the routes look correct.
Then open the failed execution in Scenario History and compare the exact failed module and its redacted input bundle for one card from each list. A field that is present in two lists but empty in the third can make the WhatsApp step fail only on that route.
If the issue is still open, I can review one redacted failed run, map the trigger-to-message path, and return the smallest repair plus a short test record. No credentials or live customer data are needed to confirm scope. My written workflow process is here: Process | Brief Factory
Thanks for the screenshot — the scenario structure looks fine, so the issue is likely a mapping or filter problem rather than the setup itself.
Could you send me the exact error? When you hit “Run once,” Make highlights the failing module in red — click it and screenshot the error message. That’ll tell me right away what’s breaking.
Most likely it’s one of these:
- Trello list name in the filter not matching your board exactly
- Router filter conditions not matching the data coming through
- WhatsApp template variables mapped to the wrong fields
Once I see the error I can fix it quickly. Happy to jump into the scenario directly if you’d like to share access.
Best,
Milos
Sri, the fastest way to fix this is to inspect the first failed run in Scenario History before changing the router. The screenshot shows the structure, but the failed module and its input bundle will reveal whether the break is Trello list routing, a missing card field, or the WhatsApp connection.
TinyOps Studio can handle this as a fixed $99 written repair: diagnose the failing module, check the three list IDs and message mappings, repair the smallest failing path, add a duplicate-send guard, replay one synthetic card per list, and leave a short change note. If the issue is a WhatsApp provider or template approval rather than the Make scenario, I will identify that clearly instead of guessing.
Which WhatsApp provider or Make module are you using, should the three Trello lists send different messages, and what exact error plus redacted input/output bundle appears in the failed run? Please keep credentials and live lead data out of the thread.
I can help diagnose the existing Trello-to-WhatsApp scenario rather than rebuilding it blindly. I would inspect the failing module and bundle, verify the card-to-message mapping and route conditions, then test with controlled cards and add a duplicate-send guard. I build API/webhook automations, though I am not claiming years as a Make-only consultant. If you can share the scenario blueprint and the current error output, I can confirm fit first; proposed price is $125 fixed with one-business-day delivery after access.