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
1 Like
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.
Hi Sri,
Iād be interested in handling this as a small paid debugging task rather than rebuilding the scenario.
My strongest current automation work is around routing, structured data, webhooks, status handling and basic JavaScript. I primarily work in n8n, and Iām gradually adding Make, so I wonāt claim to be a Make expert. For this issue I would start with the exact failed execution, compare one card from each Trello list, and check the route filters and WhatsApp field mapping.
If the problem fits that narrow scope, I can review one redacted failed run and fix the smallest failing path for $60 fixed, with a short written change note. No work starts until scope and payment are agreed.
Could you share the failed module, exact error text, whether cards are created or moved into those lists, and the WhatsApp provider/module you use?
Written async communication works best for me.
Best,
Yaroslav
The trickiest part of your setup is the bidirectional Airtable and Mailchimp sync without creating infinite update loops. The standard fix: add a ālast modified byā field in Airtable that flags Make-originated changes, so inbound updates donāt re-trigger outbound syncs. For the baseline reset, batch Mailchimp API calls in groups of 500 to avoid rate limits. Worth flagging too: Make has no native Squarespace module, so that leg will need custom HTTP modules or webhooks. Full disclosure: my company Nucleus AI builds automation systems like this for teams without in-house expertise. Iāll send our qualifications and rate to [email protected] as requested. Have you thought through how to handle tag conflicts when a contact exists in Mailchimp but not yet in Airtable?
Hi @sri_shanmugapriya_me ā if this is still open, I can handle it as a focused repair of the existing Make scenario rather than rebuilding it.
Iād start from the failed execution in Scenario History and verify:
- the exact module and error causing the run to fail
- the routing/filter logic for each of the three Trello lists
- missing or inconsistent card fields
- WhatsApp field/template mapping
- duplicate-send protection
- error handling so failed runs remain visible and recoverable
I can do this as a fixed $95 repair, delivered within 24 hours after receiving the Make scenario blueprint and one redacted failed-run example.
The acceptance test would be simple: one controlled card from each Trello list follows the correct path and reaches the intended WhatsApp destination exactly once.
If the blocker is outside Make, such as the WhatsApp provider/API itself, Iāll identify and document the exact external blocker rather than charging you to rebuild working parts.
Hi @sri_shanmugapriya_me ā is this still unresolved?
I can review the existing scenario as a small $49 fixed diagnostic. Iād trace one failed Trello-to-WhatsApp path, identify the exact module, filter, or field mapping causing the error, and return the smallest required change plus a simple verification checklist.
Iād only need the exported Make blueprint, the full error text, one redacted failed-run example, and the WhatsApp provider/module youāre using. No production credentials or real lead data are needed.
If the issue is outside Make, Iāll identify the external blocker clearly rather than recommending unnecessary workflow changes.
Best,
Xionghuan
Just adding my direct contact details in case itās easier to reach me outside the thread:
Volodymyr Pasko
Email: [email protected]
WhatsApp: +66 98 440 7304
Feel free to message me there if the project is still open.
Hi Sri ā is the error in your three-list Trello scenario still unresolved?
If so, please share the failing module, exact error text, and one redacted example of a card. I would first check what each list is meant to trigger, so a fix does not send the wrong WhatsApp message.
The initial fit check is free. If it is a bounded repair, Iāll quote it before making changes; repairs start at $129. We would test the agreed route and a repeat event in a test setup before enabling real messages. Everything can be handled in writing.
Corelia Bots
Email: [email protected] | https://coreliabots.com
Bot: Telegram: Launch @CoreliaBot | Direct: Telegram: Contact @sssenshiii