Skip to main content

Get Support
Have a question? Let's get you an answer!

How Do I...? Troubleshooting Code & Webhooks Developer Zone

Other Help Resources
Wait, there's more! Check out these Community sourced spaces for additional resources.

Zapier Help Center Hire an Expert

Learning Resources
All of our best learning resources can be found here.

Featured Articles Show & Tell Zapier's products AI Hub Zapier Tools Hub

Share your knowledge
Give back to the Community by sharing your automation wins and helping to answer questions.

Share your success See unanswered questions User Groups

Other Learning Resources
Some of our favorite additional ways to upskill your Zapier knowledge.

Zapier Learn Zapier Blog Zapier Webinars

Product Updates
Check out what is new and upcoming with Zapier with our regular product updates.

Product Updates

Early Access Program
Want to join Early Access? Learn more here.

I’m curious of other people’s experience with the Microsoft Dynamics 365 CRM Zapier app and mainly around custom lookup fields on certain entities, I have found several issues with the app which looks like it’s not usable at all (as in will always be broken based on the payload data it sends). It doesn’t appear to confirm to the Dynamics 365 API requirements in some areas for fields like lookups.

Here’s an example payload Zapier is sending when testing a Contact and lead creation zap. The contact record is created just fine, and then the ID of the contact is passed to the lead step. I suspect the contact is created because it’s just standard fields and no lookups. 

When getting to the lead entity, it gets more complicated with custom fields and lookups and I think where things start going bad.

Example payload values being sent by Zapier on a zap test.

campaignid: /campaigns(c5b08212-bfa8-ed11-aad1-6045bdd28837)
ccl1000_acknowledged: true
ccl1000_closeenquiry: true
ccl1000_enquiryautocompleted: true
ccl1000_enquiryclassification: 100000000
ccl1000_enquirytypeid: /ccl1000_enquirytypes(d79ac383-f455-e511-93f4-0050569e3c1b) ccl1000_originatingactivitytype: 940220002
ccl3016_enquirysubmittedby: 999200003
ccl3016_enquirytype: 999200002
leadsourcecode: 100000003
parentcontactid: 5023e4bd-3efc-e511-80df-c4346bac29f8

Problems:

  1. campaignid, ccl1000_enquirytypeid and parentcontactid do not have @odata.bind in the property name. This should be added at the end to work and is required for relational/lookup fields
  2. ccl1000_enquirytypeid is a custom field and I think where possibly Zapier will start to struggle. Technically you can determine custom fields via EntityDefintions, but this is a custom lookup to a custom entity. It does however appear to know this given the value uses the plural entity name (ccl1000_enquirytypes), so there’s at least some handling.
  3. The contact value for parentcontactid needs to be /contacts(5023e4bd-3efc-e511-80df-c4346bac29f8) (I could technically, implement a formatter to adjust this value, but I cannot modify the property names being used highlighted above.

Taking the original payload data, converting to JSON and sending directly through the Dynamics 365 Web API allows this data to work (assuming the campaign and contact ID are valid).

{
    "campaignid@odata.bind": "/campaigns(c5b08212-bfa8-ed11-aad1-6045bdd28837)",
    "ccl1000_acknowledged": true,
    "ccl1000_closeenquiry": true,
    "ccl1000_enquiryautocompleted": true,
    "ccl1000_enquiryclassification": 100000000,
    "ccl1000_enquirytypeid@odata.bind": "/ccl1000_enquirytypes(d79ac383-f455-e511-93f4-0050569e3c1b)",
    "ccl1000_originatingactivitytype": 940220002, 
    "ccl3016_enquirysubmittedby": 999200003,
    "ccl3016_enquirytype": 999200002,
    "leadsourcecode": 100000003,
    "parentcontactid@odata.bind": "/contacts(5023e4bd-3efc-e511-80df-c4346bac29f8)"
}

However in it’s current state it appears the Zapier app is quite broken and won’t work for custom fields or more advanced uses.

Given you don’t seem to be able to modify the payload data with the app, has anyone had success with custom POST requests using the Dynamics 365 API. I know how to use the API without Zapier, the issue is having a client that is authenticated with OAuth, the Microsoft Dynamics 365 CRM app takes care of all of that and ideally it would be great to be able to use it, just currently it doesn’t appear to handle lookups well.

For reference I have also sent these findings through a support ticket, I’m more curious on any other users who happen to use the Microsoft Dynamics 365 CRM app with Zapier and if there’s any customisations or workarounds I’m not aware of?

Thanks,

James

The error also indicates that Zapier is sending the custom field with the wrong name based on the error. In this case it looks like Zapier is sending the value as the SchemaName when it should be the LogicalName i.e. all lowercase.

Failed to create a lead in Microsoft Dynamics 365 CRM
The app returned "Error identified in Payload provided by the user for Entity :'leads', For more information on this error please follow this help link https://go.microsoft.com/fwlink/?linkid=2195293 ----> InnerExcep...". Error identified in Payload provided by the user for Entity :'leads', For more information on this error please follow this help link https://go.microsoft.com/fwlink/?linkid=2195293 ----> InnerException : Microsoft.OData.ODataException: An undeclared property 'ccl1000_EnquiryTypeId' which only has property annotations in the payload but no property value was found in the payload. In OData, only declared navigation properties and declared named streams can be represented as properties without values.

Only ccl1000_enquirytypeid@odata.bind works as per testing the Dynamics 365 API directly.

Speaking with Zapier support I was given access to the older 1.8.5 version of the Dynamics 365 app and this works much better, so the new version has some issues and would recommend anyone having issues specifically with custom fields or 400 bad request errors due to LogicalName vs SchemaName handles to be asked to provide a zap with access to the old version, you can then clone/duplicate for re-use if needed.

The older 1.8.5 app appears as a custom integration rather than being under the main list, as that’s for the newer app.

The issue with the two different versions of the field names isn’t the end of the world, however I can’t get that far.

Can anyone tell me how to pass query parameters in Zapier to Dynamics 365? I can’t figure out how to use the query parameter form fields for this specific app and when I put the web query together in the API URL it strips off the select parameters and returns the entire tables data.

How do I pass query parameters in Zapier for this specific app?

The issue with the two different versions of the field names isn’t the end of the world, however I can’t get that far.

Can anyone tell me how to pass query parameters in Zapier to Dynamics 365? I can’t figure out how to use the query parameter form fields for this specific app and when I put the web query together in the API URL it strips off the select parameters and returns the entire tables data.

How do I pass query parameters in Zapier for this specific app?

The field name casing is actually very important with the Microsoft Dynamics 365 API, because depending on your environment only one casing variant will work while the other will lead to a 400 error as above.

I’m not sure I follow on your query parameters question, but if the built Dynamics 365 app steps don’t work you can use the Custom Actions/API requests to customize and have more control over the requests e.g. you can query custom entities.

Thanks JamesMacWhite.

I’m just trying to send queries. Selects, inserts and updates using the Zapier Dynamics 365 API Request.

For example: https://oururlhere/api/data/v9.2/lx_candidates?$filter=ID eq 1005

To retrieve this specific record.

However when I put that full url in the Zapier URL field, Zapier strips off everything after the table name when it sends the query and therefore returns the entire table. I haven’t been able to figure out how to use the Zapier “Query String Paramater” form fields in this case. That’s the ideal solution if someone can give me an example based on the above example.

My alternative step is to try to send JSON in the Zapier body field if that’s possible, however I’d really rather not. Is that even possible with these OData web queries? If so can someone please give a basic example?

Thanks.

Andrew

Update:

So I’ve figured out how to select a specific row (GET) using the OData filter parameter like this:

and I can POST a new record, however neither PATCH nor PUT seem to be happy:

and

There must be a way to update rows.

Can anyone help please?

Found the answer:

 

https://timhanewich.medium.com/dataverse-web-api-101-97e4099ff10b

 

 

Looks you figured it out! Query string parameters must be used to passed in the builder like that to ensure any query parameters are properly sanitised and placed into the HTTP request correctly.

To get a slightly better response than 204 on PATCH requests, you can pass in the HTTP header:

Prefer: return=representation

This should give you a 201 response and will return the data of the record if you needed to examine or inspect the PATCH response.

JamesMacWhite

”…Query string parameters must be used to passed in the builder like that to ensure any query parameters are properly sanitised and placed into the HTTP request correctly.…”

I haven’t been able to use the Zapier Query String Parameter form field to do the post and the patch. I’ve had to build JSON in the Body field. Any tips on this?

URL Query parameters are only going to be for GET requests e.g. querying records or selecting data. E.g. lets say you wanted to get a custom entity with a subset of values:

{{webapiurl}}ccl1000_contacttypes?$select=ccl1000_contacttypeid,ccl1000_name

The $select query parameter allows you to limit the returned fields. This would only be GET requests.

PATCH/POST requests will require a JSON payload, given you need to upload data to the Dataverse API targeting your CRM instance. So what you are doing currently would be correct.

Any news on this issue? I have just noticed that all the old functioning versions have been deprecated and the newer ones have this issue...

Any news on this issue? I have just noticed that all the old functioning versions have been deprecated and the newer ones have this issue...

We still use the 1.17 version of the app. Zapier support provided access to this, it is still linked and active in Zaps under our account.

I would speak to Zapier support about access to it. It appears as a Private app under “Other apps”.

Any news on this issue? I have just noticed that all the old functioning versions have been deprecated and the newer ones have this issue...

We still use the 1.17 version of the app. Zapier support provided access to this, it is still linked and active in Zaps under our account.

I would speak to Zapier support about access to it. It appears as a Private app under “Other apps”.

Thank you a lot you saved my day! I already had access to this so I didn’t have to ask for it. I really hope they are planning to solve the issue before deprecating this version as well though...

From my last conversation, they said they’d keep it active in our account. We can’t use the latest version for some Dynamics 365 actions which use custom fields that aren’t provided in the standard entities due to the casing issue. Certain actions like a find/create that does not use anything custom work fine.

If it is removed, I’ll be soon onto their support to ask to have it back, otherwise all Dynamics 365 Zaps will be broken and I’d imagine other customers will be in the same boat.

Long term the Dynamics 365 app needs to find a way to reliably set the right casing for field names to prevent 400 errors. There is a single source of truth from any CRM environment with a metadata file, which provides all entities and the fields with their correct casing.

The problem is the use of LogicalName vs SchemaName without checking a source can lead to issues.

Reply


Terms & Conditions