Setting a customer automatically based on e-mail domain

In this article, we will extend the Using Azure AI for Entity Creation article by setting the Customer field on the Entity form automatically by looking at the domain the incoming e-mail is from.

Specifically, we will:

• Set up our Create Customer process so that the customer's e-mail domain is registered as metadata. We do this so that we can match a customer to an incoming e-mail later.
• Call a Graph endpoint to look into the Customer's list and return a customer given an e-mail domain.
• If there is a match between the domain of the incoming e-mail and an existing customer, we will set that customer in the Customer field on the Entity form for creating new cases based on an e-mail.

Let's first tackle automatically extracting the e-mail domain when creating new customers in our WorkPoint solution:

On our Customers business module, we have set up an Email field, as well as an e-mail domain field:

In our Create customer process, we have hidden the Email Domain field on the Entity form step (we have also made the Email field mandatory):

In the Create customer step, we then set the Email Domain field:

We do so by using the following expression:

We now have an easy way of ensuring that we register the customer's e-mail domain so we can look it up later.

We will now set up a Graph endpoint to look up customers based on an e-mail domain. This section assumes you have already set up the necessary Graph credentials found in the article about using AI to create entities from an e-mail, which you can find here.

We begin by creating a new Http endpoint in the Http endpoint library in the WorkPoint administration:

1. In the Title field, we give the endpoint configuration a fitting title.
2. We then set up a parameter to take en email domain.
3. In the URL field, we need to provide a URL to the Graph endpoint we want to use. For looking into a Sharepoint list (in this case our Customers business module), we can use the following endpoint:

Obviously, we need to replace the tenant, SiteId, and BusinessModuleId placeholders with our actual values. in our case, we have the following values:

• Tenant: m365x31961369
• SiteId: 5ab0c822-f487-4ad0-a6ec-344cade7ae7b. You can find yours by selecting your WorkPoint site in the Sharepoint administration and checking the Url.
• ListId: d28458c1-86e0-4c52-87a2-d8aee162e42a. You can find yours by opening the business module list, opening the list settings and checking the Url.

With our values, our complete Graph endpoint URL becomes:

4. In the Http(s) endpoint action field, we select "Get".
5. In the Header section, we set up a header with the "Prefer" key, and the "HonorNonIndexedQueriesWarningMayFailRandomly" value. This header ensures that we can query non-indexed fields. Note that this is normally discouraged and you should instead ensure that the email domain field (here "ccEmailDomain") is indexed on the target list.
6. In the Query section, we set up the following two queries:

7. In the Credentials field, we select the MSGraph credential we created earlier (as part of the article about using AI to create entities from e-mails).
8. We can now type in an e-mail domain registered on an existing customer in our WorkPoint solution and press the "Test" button to see if we get a response. In our case here, we have a customer with "workpoint.dk" registered in the ccEmailDomain field, and providing "workpoint.dk" in the Test Value field for the emailDomain parameter, we get the following response:

Scrolling down a bit, we can see that our WorkPoint A/S customer metadata is included in the response:

9. We can now click the "Autogenerate from test" button in the Schema section to automatically generate the response schema for the endpoint configuration.

10. Finally, we click the "Add" button to save the new endpoint configuration.

The endpoint should now appear in the Http endpoint library:

In this section, we will extend the process from the previous article by calling the newly created Graph endpoint to get an existing customer based on the incoming e-mail sender, and inserting that customer into the Customer field on the Entity form.

The process from the "Using Azure AI for Entity Creation" article looks like the following:

We will start by adding another Send http request step after the "Analyze e-mail" step:

In the Options tab, we make the following configurations:

11. In the "Endpoint" field, we select the "Get Customer By Email Domain" endpoint we created earlier in this article.
12. Expanding the "emailDomain"parameter, we set the following expression for the value:

This will take the e-mail domain from the "sender" object returned by our "ReadEmail" endpoint and using that as the parameter value for our "Get Customer By Email Domain" endpoint. Effectively this allows us to see if there is a customer with the same e-mail domain as the e-mail sender registered in our Customers business module.

Next, we select the Entity form (here called "Case information"), open the "Fields" tab and expand the "Customer" field:

13. For the Customer value, we set the following expression:

This will ensure that if there is a match between the e-mail sender's domain and a customer in our Customers business module, then that customer will be set in the "Customers" field on the Entity form. If there isn't a match, the Customer field will instead be empty.

We can now save and publish the process and test it.

Here we have an e-mail with some case related information, sent to us from an e-mail address belonging to the "workpoint.dk" domain:

In our Customers business module, we can see that the "WorkPoint A/S" customer has that domain set in the Email Domain field:

When we run our process with the e-mail selected, we see that the WorkPoint A/S customer is automatically detected and inserted into the Customer field of our Entity form (once the AI is done analyzing the e-mail):