Webhooks to Dynamics 365 Serverless Integration using Azure Functions

Recently I needed to create an integration between a cloud platform and Dynamics 365 Customer Engagement Cloud. This Cloud Application (Unbounce) allows you to register Webhooks which you can use to send data across from that platform to any other web application.

Please note that this article already assumes that the reader understands the basics of Webhooks and Azure Functions.

Webhooks sends data when a server event occurs typically to a web application. They are lightweight HTTP pattern with a publish/subscribe model which sends POST requests with JSON payload. This means Webhook POST requests can be consumed by any programming language or web application anywhere.

So when our 3rd party Cloud application (for example Unbounce) sends out the webhook POST message, how can Dynamics 365 receive this POST message? The answer is: Azure Functions.

It’s not the first time that Microsoft Azure Serverless Inegration capabilities, namely Azure Function Apps, come to the rescue. Azure Functions are becoming more and more the default preferred option for many Dynamics 365 related integrations.

So Unbounce sends out the webhook POST message to the Azure Function which in turn sends this data to Dynamics 365. To do this, you need to create an Azure Function that is triggered by Webhook and in your function, you can write the code that sends Data to Dynamics 365. Below are 6 steps that show case the process for adding an Azure Function App triggered by a Webhook POST call. Please comment below if you require the code in the Azure funciton (It’s standard Dynamcis 365 call to create a field so nothing fancy).

1) First, create your Azure Function App:

2) Make sure that the function is triggered by Webhook + API and using C#:

3) Then once created, create a Function within your Function app

4) Following that, we need to reference Dynamics 365 CRM SDK Core Assembly package. To do this, add a file called project.json as below:

5) then input your code inside the run.cx function which will receive JSON POST message and writes it to Dynamics 365:

6) then finally, run a test on your Azure Function App to see a record created in Dynamics 365 (a Lead in our case):

Please note that in step 5 above, you will definitely need to write code to receive the JSON payload that will come in the POST request message. So in our example, if this is coming from Unbounce, we have parse the Unbounce JSON data sent in the POST message so we can then use this data to create our lead (or contact) in Dynamics 365.

Please comment below if you require this code and I’ll be happy to share it.

Note: I’m delivering this session at a number of Dynamics 365 Saturday events starting tomorrow in London (7th July 2018). Hence, I’ll be updating it regularly (and apologies for rushing the post!)

Your feedback via comments below is invaluable and will encourage me to update it and write more about this subject.

Understanding Dynamics 365 Business Process Flow Data Model following changes in December 2016 release (v 8.2)

Microsoft Dynamics 365 December 2016 release (version 8.2) included some significant changes to Dynamics CRM Business Process Flow data model and entities structure.

In the new Model, every time a business process flow is activated, a custom entity is automatically created to store the activated business process flow instances.

Before that, every time you create a business process flow, it is stored in the Workflow entity (https://msdn.microsoft.com/en-gb/library/mt622427.aspx).

The Workflow entity stores the business process flow definition. So once the entity is created, it is always in Draft state and its definition is stored in Workflow entity. XAML property is where the definition is stored and is mandatory/required.

Once you activate a business process flow definition (by changing the state of the corresponding Workflow entity record), a custom entity with the following name is automatically created to store the activated business process flow instances:

<activesolutionprefix>_<uniquename>

More details can be found in this MSDN Article here:

https://msdn.microsoft.com/en-gb/library/dn481586.aspx

There is also the Process Stages Entity which contains: Step metadata for process stage (Client Data). It also contains stage Category (Qualify, Develop, Propose, etc.) as well as the Stage Name.

Properties represent fields of data stored in the entity. Some properties are read-only.

Name Type Details
clientdata Edm.String Description: Step metadata for process stage

Display Name: Client Data

Read-only property

owningbusinessunit Edm.Guid Description: Select the business unit that owns the record.

Display Name: Owning Business Unit

Read-only property

primaryentitytypecode Edm.String Description: Primary entity associated with the stage.

Display Name: Primary Entity

processstageid Edm.Guid Description: Shows the ID of the process stage record.

Display Name: Process Stage

stagecategory Edm.Int32 Description: Select the category of the sales process.

Default Options:

0 : Qualify
1 : Develop
2 : Propose
3 : Close
4 : Identify
5 : Research
6 : Resolve
7 : Approval

Display Name: Stage Category

stagename Edm.String Description: Type a name for the process stage.

Display Name: Process Stage Name

versionnumber Edm.Int64 Description: Version number of the process stage.

Display Name: Version Number

Read-only property

More information on the ProcessStages entity is here:

https://msdn.microsoft.com/en-us/library/mt790421.aspx

Finally, here is a Dynamics Community post with few more information and discussion on this subject:

https://community.dynamics.com/crm/f/117/t/241128

Introducing Microsoft Dynamics 365 Business Edition and its core functionality from the Dynamics Roadmap site

As most of you know, Microsoft has been working hard on releasing the highly anticipated Dynamics 365 Business Edition which targets small and medium businesses who do not require the full functionality of Dynamics 365 Platform.

Personally, I have been really looking forward to this version as quite a few of smaller size clients are eager to opt for this more focused version instead of the full platform. The Dynamics Business Edition will allow Microsoft Partners to target the SMB market more effectively by providing a solution that fits their size and their requirements.

The publicly available Dynamics Roadmap website (http://roadmap.dynamics.com) lists a number of functionalities in the new Dynamics 365 Business Edition. some of the functionalities currently being developed in the Sales Module of the business edition are:

  • Lead to Cash
  • Microsoft Dynamics 365 Connector for LinkedIn Lead Gen Forms
  • Quick Start Wizard
  • Simplified setup of Exchange and SharePoint integration

Over the next few days, I’ll be covering some of these new functionalities in Dynamics 365 Business edition in separate blog posts.

In the meantime, you can get the full details about the Sales module of the Dynamics 365 Business Edition can be found here:

https://roadmap.dynamics.com/#edition=1#application=326f31ea-2992-e611-80dc-c4346bac0910#area=#status=c3ba828c-ae97-e611-80df-c4346baceb68

Hope this helps!