Microsoft Dynamics 365 Customer Service provides a suite of tools that allow organizations to optimize their customer service management. In addition to enhancing customer experience, this platform can also assist in tracking communication and internal support processes, benefiting companies as well as their customers.
However, while a Microsoft Dynamics 365 Customer Service Portal can be useful, configuring it to meet a unique set of requirements can be a challenging task.
At Connecting Software, we used Microsoft Dynamics 365 Customer Service to build our Support Portal. Since we had a specific vision of what we wanted to achieve with our Support Portal, through this article we will detail the process of building it through the Dynamics 365 Customer Service implementation, while showcasing the obstacles we encountered along the way and the solutions we found to best go about them.
Dynamics 365 Customer Service Portal Features
In the instances where our customers are unable to find an answer to what they are looking for in the Knowledge Base, the Dynamics 365 Customer Service Portal allows customers to create support cases. From a customer’s point of view, these are the two main features of our Support Portal.
For us, however, the main advantage is being able to generate information regarding the use of the Support Portal and our software solutions. E.g., if we notice several cases about a specific problem on a specific product are being submitted, we can redirect our resources to quickly solve the issue. If it is just a FAQ, we can add it to the Knowledge Base of our Support Portal to make the information available to any customer sharing the same concern.
As such, the Dynamics 365 Customer Service Portal acts as a centralized tool for evaluating the quality of our products, improving customer satisfaction, tracking customer interactions, guaranteeing we have access to information that allows us to keep improving, adapting our resource planning, and even to generate valuable internal reporting, e.g., the cost of support per product.
Now, let’s have a look at the obstacles we faced while implementing our Support Portal.
Occurrence #1 – Existing Customer Base
Having an existing customer base when we started to work on the Support Portal turned out to be troublesome.
Whenever a customer first registers for our Portal, a duplicate contact is created in Microsoft Dynamics 365 (CRM), that is, our customer database. Microsoft Dynamics 365 for Customer Service does not natively link the duplicate contact to the real customer contact in our customer database, thus, the information is not centralized into just one record. This meant that our support cases were also not linked to the contact associated with the account we have an established relationship with. Instead, they were linked to the empty duplicate contacts created as a result of the Support Portal registration.
This issue could have been solved by automatically sending an invitation that would successfully link the duplicated contacts to the real customer contacts in our CRM, but this is something that would have had to be done from the very beginning of starting the customer base. Besides, despite this working in theory, it is not a realistic solution due to poor email opening rates. Just to put things into perspective, according to Mailchimp, the average email open rate across all industries was a mere 21.33% in 2021.
You may also be thinking that a default merger of the records would have sufficed, but this is not the case, as merging the information of the records into one contact would result in the loss of access to our Support Portal.
Solution – A Dynamics 365 Plugin
The other way to solve this would be to create a custom Microsoft Dynamics 365 plugin (referred to as a Solution in the Power Apps world), and this is what we did. The plugin we built scans if the user already exists in our CRM during the Support Portal registration.
There are two possible outcomes: if the user does exist in our database, the plugin recognizes this match and merges the information on both records into a single contact without the user losing access to the Dynamics 365 Customer Service Portal, that is, our Support Portal. The second contact, containing no information at this point, is automatically deleted by the plugin we built, which runs a separate Bulk Delete job weekly to purge the records.
In case the user signing up for the Portal does not exist in our CRM, the plugin does something different. Being a B2B company, the emails of customers on our database have a domain that is specific to the organizations they work for. So, if a user that is not in our CRM wishes to register for our Portal, the plugin searches our CRM for the email domain of this new user. In case there is a match, a new contact is automatically created in the CRM because this user belongs to a company we are already familiar with. Contrarily, if there is no match in our database to the email domain of the customer signing up for the Support Portal, we are informed internally of the attempted registration and reach out to get further information should it be required.
You can find part of the code for our Microsoft Dynamics 365 plugin through this link. Feel free to reach out to us if you want the complete version!
public void Execute(IServiceProvider serviceProvider)
{
var tracingService = (ITracingService) serviceProvider.GetService(typeof(ITracingService));
var context = (IPluginExecutionContext) serviceProvider.GetService(typeof(IPluginExecutionContext));
var serviceFactory = (IOrganizationServiceFactory) serviceProvider.GetService(typeof(IOrganizationServiceFactory));
var service = serviceFactory.CreateOrganizationService(context.UserId);
if (!context.InputParameters.Contains("Target") || !(context.InputParameters["Target"] is Entity))
{
return;
}
var entity = (Entity) context.InputParameters["Target"];
var isLoginEnabled = HasLoginEnabled(entity);
if (isLoginEnabled == false)
{
return;
}
try
{
var emailAddress = (string) entity["emailaddress1"];
var contactsWithSameEmailAddress = GetContactsByEmailAddress(service, entity.Id, emailAddress);
if (contactsWithSameEmailAddress.Entities.Count > 0)
{
var hasLoginEnabled = HasLoginEnabled(contactsWithSameEmailAddress.Entities[0]);
if (hasLoginEnabled)
{
throw new InvalidPluginExecutionException(OperationStatus.Failed,
"User already exists. Try a different email address to register, or login to your existing account.");
}
var mergeRequest = new MergeRequest
{
SubordinateId = entity.Id,
Target = new EntityReference("contact", contactsWithSameEmailAddress.Entities[0].Id),
UpdateContent = GetUpdateContent(entity)
};
var _ = (MergeResponse) service.Execute(mergeRequest);
entity[CustomAttributeName] = true;
service.Update(entity);
}
else
{
var domain = emailAddress.Split('@')[1];
if (_publicDomains.Contains(domain))
{
SendEmailAndDeactivateContact(service, tracingService, entity);
}
else
{
var contactsWithSameDomain = GetContactsByDomain(service, entity.Id, domain);
if (contactsWithSameDomain.Entities.Count > 0)
{
entity["parentcustomerid"] = contactsWithSameDomain.Entities[0]["parentcustomerid"];
service.Update(entity);
}
else
{
SendEmailAndDeactivateContact(service, tracingService, entity);
}
}
}
}
catch (FaultException ex)
{
throw new InvalidPluginExecutionException("An error occurred in ContactPostOperationPlugin.", ex);
}
}
Close codeOur Web Shop
Occurrence #2 – Error Message on D365 Customer Service
Users who were not yet registered to our Dynamics 365 Customer Service Portal received a misleading error message whenever they attempted to login. This message stated their password was incorrect, as opposed to informing them their email was not registered on the Support Portal.
Going back to our previous occurrence, whenever a user registers for the Support Portal, a duplicated record is created in our CRM. Customers who are not registered for the Portal do not have this duplicated record, thus, there is no record for the system to read that contains information about their login. What the system does is update the field “username input” in the CRM, which does not contain any information. This then triggers Microsoft Dynamics 365 Customer Service into assuming the user already has a login, showing the message informing their password is incorrect.
Solution – The Dynamics 365 Plugin
Just like the solution to the issue we had with having an existing customer database, the best approach to battle this error message was to use a Microsoft Dynamics 365 Plugin/Solution.
In fact, we used the same Dynamics 365 plugin we already had, only with a slight alteration. Our development team registered one more plugin step, which is essentially a command that identifies and stops the error the system makes by updating the “username input” field when it does not have any information in it. The plugin step then corrects the error message that is shown to the user attempting to access the Portal, stating they do not have a login for the Support Portal instead of saying their password is incorrect.
About the Author
By Diogo Gouveia
“After completing my studies in the United Kingdom, I joined the Marketing team at Connecting Software to create content on software integration and a variety of other IT topics. If you have any observations or suggestions, please reach out."