I previously blogged here about how you can configure S2S, Server-to-Server, authentication to allow third party applications to query and update data in Dynamics 365 using the Web API.  As the Dynamics 365 Web API is built on open http standards with libraries for a variety of languages the integration possibilities are endless. You can use Web API calls to integrate Dynamics 365 with internal applications and also allow external partners to make API calls directly to your instance of Dynamics. A downside however of allowing third parties to create and update entities using the Web API endpoints is that you have no control on the quality of the data they submit as there is no validation done when you do an Web API call.

So you might decide configure S2S authentication with rights to create leads and provide these details to a marketing company to push new leads into your instance of Dynamics using Web Api calls. If you think about it you are giving an external organization the ability to create as many lead records in your production environment as they like without any data validation or duplicate record checks. It is therefore possible for a bug in their code to cause havoc in your instance of Dynamics by creating rubbish lead records endlessly.

In this first post covering this subject I suggest that rather than give third parties direct access to addor update entities that you use custom actions to wrap access to entities and add validation to the custom action.  In this example I am going to create a custom action for adding Leads with some basic nocode validation for required parameters. I will do some follow on posts covering how to do more complicated validation using custom code. Create a custom action with the input parameters you want your action to accept and mark the arguments as required and add a step to create a lead.

In the properties of the Create Lead step set the fields to the input parameters.

Now when you use code like the following and you do not pass any required parameters the call will fail and you get an error message indicating which parameters are required. Note: This basic technique does not check if the parameter is populated and passing an empty string does not throw a validation error.

using (HttpClient httpClient = new HttpClient())
{
string token = await AdalAuthAsync();
httpClient.BaseAddress = new Uri(organizationUrl);
httpClient.Timeout = new TimeSpan(0, 2, 0);
httpClient.DefaultRequestHeaders.Add(“OData-MaxVersion”, “4.0”);
httpClient.DefaultRequestHeaders.Add(“OData-Version”, “4.0”);
httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue(“application/json”));
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(“Bearer”, token);    JObject jo= new JObject
{
{“firstname”, “Joe”},
{“lastname”, “Bloggs”}
};