My goal is to understand why my webhook-triggered scenario intermittently fails on the Microsoft 365 Excel List Table Rows module during the initial execution, while re-running the same execution succeeds without any changes.
What is the problem & what have you tried?
The scenario is triggered by a custom webhook. Immediately after the webhook, it runs Microsoft 365 Excel List Table Rows against a fixed workbook/table.
The problem is that the initial webhook-triggered execution sometimes fails on the Excel module, but when I re-run the same execution in Make, it completes successfully without changing the scenario, connection, workbook, or input data.
The webhook is used only as a trigger. None of the webhook payload is mapped or used by the Excel module or later modules. The Excel module has its site, drive, workbook, worksheet, and table configured directly.
I tried to reconnect the modules and adding a sleep in between them, but it still does not help.
Can you post a screenshot of the error thrown by the Excel module?
Most likely a timeout or an exceeded quota – that would explain why the scenario works again after a moment, but that’s just a guess without seeing the actual error.
What you can do right away: add a Break error handler so Make can auto-retry the failed run automatically.
I’ve run into something similar with the MS365 Excel modules, and one thing I’d test here is the Excel call itself rather than the webhook.
Since the webhook data isn’t being used at all, there’s probably no reason for the webhook payload to be causing this. The fact that the exact same execution works when you rerun it makes me think this could be a timing/API state issue with Excel rather than the table or connection being wrong.
One thing I’d try is putting a small retry path around the Excel module rather than just adding a fixed sleep. For example, if List Table Rows returns 0 bundles, wait a few seconds and make the Excel request again. That should tell you pretty quickly whether it’s an intermittent Excel/Graph response.
Also worth checking whether the workbook/table is being opened or modified by another process around the same time. Excel can be a little weird with concurrent access.
If you try the retry approach, I’d be curious whether it makes the failures disappear.
This looks more like an intermittent Microsoft 365 Excel/API response issue than a webhook mapping problem, especially since the same execution succeeds when re-run without changing the data or configuration.
I’d check whether the Excel module is sometimes receiving an empty response from Microsoft Graph during the first request. You could also test with a short delay before the Excel module and add logging around the workbook/table identifiers to confirm they are consistently resolved.
If the table itself is stable and the issue only happens intermittently on the first execution, I’d also test a retry/fallback approach around the Excel lookup rather than rebuilding the webhook.
The re-run succeeding without touching data is the Graph tell. List table rows on a cold token sometimes comes back empty or 202, then the same payload works 20 seconds later. Break plus retry is the right handle; a fixed Sleep only hides the first case.
I have also seen this when two scenarios share the same Excel connection and one is refreshing the token as the other starts. Do the empty first-runs cluster after the scenario sat idle overnight, or also in the middle of a busy hour?
thanks for the reaction and sharing your experience! Its very valuable. So do I understand correctly that you would recommend using the Make an API call module for Excel rather than the list table rows? My experience is that the module returns a number of bundles, but they are all empty.
Thanks again!
Looking at the scenario, I’d focus on the Microsoft 365 Excel module rather than the webhook itself. Since the webhook payload isn’t being mapped into the Excel module and the same execution works when re-run, the intermittent empty response could be related to how the Excel table is being resolved or queried on the initial request.
I’d test the Excel module independently with the same workbook, worksheet, and table, and compare the output between a failed webhook-triggered run and a successful manual re-run. Also check whether the table has any recent changes or if Microsoft 365 is returning an empty response temporarily.
If the Excel module consistently returns empty bundles only on the first request, adding a controlled retry around the Excel lookup could be more reliable than adding a fixed Sleep.
No — I would not swap List table rows for Make an API call. Same Graph call, same cold-token flake. Break plus retry on the Excel module is the bit that actually helps.
Empty bundles with columns but no values is the usual shape of that first response, not a mapping miss. When you open a failed execution, is the row count 0, or are the columns there and just blank?
What is your goal?
What is the problem & what have you tried?
Error messages or input/output bundles
Screenshots (scenario flow, module settings, errors)