Microsoft Dynamics 365 CRM error: The app did not respond in time. It may or may not have completed successfully.

Hi @SamB,

Thanks for your input. I have previously discussed this issue with support, but because of the use of 1.17 app version, there’s not much official support provided as it needs to be the latest version, unfortunately due to issues with the 1.18 version, I can’t use any functions that attempts to write data i.e. POST with the 1.18 version given the payload data is wrong, although find/lookup requests work fine, so it’s sort of a split use between the older app version for writing data and latest for read actions.

Your suggestion around creating the lead from a find is interesting and something I’ll look into, thank you for the tip. I still have concerns around the timeout error being thrown because even with auto replay, eventually this triggers the threshold for automatically disabling a Zap (given these errors are transient but not really following a pattern). I have implemented another Zap using Zapier Manager to alert me to this event, but all this stems from the timeout being fixed at 30 seconds (I think). I also don’t want the find process to neccersarily block a lead from being created. The purpose of leads is multiple under a contact i.e. one contact might have multiple leads. If you are just matching on properties like First Name, Last Name and Email, this could stop a legitimate lead being created if it’s about two different lines of enquiry from two different processes.

I get that Zapier’s HTTP requests need to complete within a reasonable time, but we have another Microsoft Dynamics 365 CRM intergration that offloads these actions to separate queue worker for this exact reason, so it can run for much longer without blocking front end requests. While I get that Zapier tasks can’t run forever either. The “delay for” action exists and can artificially make a task run longer, I don’t really see why we can’t have the ability to set the HTTP timeout value on public apps, given it’s literally just a single value to pass to the HTTP client as an integer. I’m not talking about a massive increase either, 60 seconds might do it, or possibly 90/120 to be absolutely safe. I think 30 seconds is too low as a default and clearly isn’t working for us with the constant reports of an error occurring randomly, when in fact it’s a timeout and the data was created, but now Zapier sees it as a failure and retries it.

The issue we have with this scenario with the timeout not controllable is no matter what we do, we are going to face an issue. We can do nothing and let auto replay do it’s job, but the problem with that is auto replay is being coecred into replaying tasks which potentially didn’t actually fail in the first place. We can turn off auto replay but then the errors happening will automatically turn the Zap off itself eventually causing further problems and even with auto replay on this will also eventually happen as well. You can see the catch 22 in the scenario.

I believe the Dynamics 365 API actually allows for up to 10 minutes, so the API requests can run for longer periods without issue based on official documentation for the API itself.

Zapier really needs to considering allowing the timeout to be increased on some apps. No two Microsoft Dynamics 365 environments are the same and some are going to be slower to respond than others e.g. if you have bigger schema, fields etc. Please let us raise the timeout or increase it in the public app, begging you on behalf of other Dynamics 365 users who user Zapier who I’ve read have had similar reports.

I implemented the Find action instead of a single create and that should resolve the duplicate data problem with the find step introduced so thanks @SamB for the idea and suggestion. I have further been looking into timeout issue some more.

There’s a possible explanation for timeouts although I can be sure, but I suspect it might be due to workflows/processes running on the CRM environment side during the POST request, triggered by certain values provided in the lead data.

Payload test 1, matching how Zapier has been creating leads with the previous Crete Lead and now Find/Create Lead step amendment.

Time 20.29s. That response time isn’t great, but still under 30 seconds, so should in theory be OK and under the threshold. I did further tests and the times were lower average around 10 seconds instead, but a worst value seemed to be in the 20 seconds areas, but that’s only leaving a buffer of about 10 seconds before Zapier deems the request as timed out.

Payload test 2: This links an existing contact record to the lead, instead of using the ccl1000_createnewcontact field with a true value (this is bespoke functionality within our CRM environment) to essentially create the contact record from the lead without having to create a contact field.

Time: 6.17s. We have a significantly shorter response time, which potentially hints at some form of process or workflow slowing down the first test.

This could suggest that leveraging the workflow that creates a contact upon a lead being created within our CRM system could in fact by slowing down the response overall.

If the timeout total is 30 seconds, the better solution might be to not trigger this process when creating a lead and instead break out the process into two steps.

Step 1: Find/Create Contact (Maximum of 30 seconds):

• Check if Contact exists based on data such as First Name, Last Name, Email
• If a contact is found return the contactid for linking to the lead
• If no contact is found, create a contact with the data provided and return the contactid created

Step 2: Find/Create Lead (Maximum of 30 seconds):

• Check if the Lead exists based on data such as First Name, Last Name, Email and Subject/Topic (prevents tagging other leads unrelated but with the same personal details)
• If a lead is found don’t create the lead as it should have already been created
• If no lead is found, create the lead but link to the contactid provided in the Find/Create contact step.

You should have 2 x 30 seconds to create the contact and lead in two steps instead, currently the contact and lead are being created in Payload test 1 in a single request, which could be where things can be unpredictable.

From API testing with Postman find requests generally seem to be completed under a second, you can further improve the response time by using $select to not return all fields on the record if you get a match, but even without doing this the response was still quick under 100ms in most cases.

It would seem the Create action/creating a contact through a workflow could be slowing down things, so abstracting that out into the Zapier action may be better and more reliable, it adds an extra action and hence task usage, but in an effort to get things in a reliable window with timeouts, it might be the better option.