Dynamics 365 Customer Service Portal: Challenges and Solutions – Part 2

To optimize the resolution of the cases we receive on the Support Portal, our team had to redesign the “Open a New Case” page. Instead of the general query box we just mentioned, we created a form that expands as customers fill in the information about their cases.

When logged in, this is what a user initially sees:

After filling out the “Title” and “Subject” fields, the form keeps expanding. For demonstration purposes, we will simulate the scenario of a customer experiencing a login error when attempting to access their SaaS account for CB Dynamics 365 to SharePoint Permissions Replicator.

Once the form is completed, you can see the information is split throughout different fields rather than on one big text box. The system can now read these different fields and correctly direct the case to the appropriate queue, via pre-defined process workflows.

Each time a case is directed, the receiving team is alerted with an automated email informing them they have received a new case on the Support Portal. Then, that team must go to the CRM to check the case to either leave a Portal comment, which is a simple comment on the Dynamics 365 Customer Service Portal to the query that was placed, or to send out a calendar appointment, also through the CRM, to arrange a call if need be. The customer is then notified of these occurrences via email, and the same happens for the team members that are assigned to the queues every time there is an update to a support case (e.g., a reply from the user to a portal comment).

Solving cases exclusively using the Microsoft Dynamics 365 CRM is something our team had to get used to (which will be addressed further down) but is extremely beneficial since all communication and processes are now tracked. This gives us the ability to generate data we can trust in, to analyze it and derive initiatives to increase customer satisfaction and keep improving our product line.

As you likely know, attachments are extremely useful whenever creating a support case, as they facilitate the exchange of information between the user and the professional conducting the assistance. However, depending on the complexity of the case in hand, the total size of the attachments may vary, and there are usually limitations on this.

The Dynamics 365 Customer Service Portal has a limit of 5MB for the total size of attachments customers can send together with their cases. For customers attaching a simple screenshot this is more than enough, but for cases that need a screen recording or a larger number of images for example, this becomes an issue.

      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);
        }
    }

Although our development team is brilliant, there is not a lot we can do about this attachment limitation. The best workaround for this issue is to provide the user with an alternative repository for uploading files, which are analyzed by the team handling the case. For this purpose, the platform we use is ownCloud.

Besides the previous four, there were other situations that proved we were willing and able to modify the initial rollout of the project should there be a need. As an example, we:

• Adapted the Microsoft Dynamics 365 Views and the searchability of the Portal comment descriptions
• Improved the readability of the Portal comments for the Customer and Support Team by removing the HTML code and including Rich Text
• Added an extra column to compile an external Knowledge Base URL
• Set up a process of automatically resolving cases that go unanswered
• Learned about the ways Microsoft Dynamics 365 renders HTML to ensure our information emails to the customers display as desired (Hint: The HTML must be in a single line of code rather than in a standard format).

Additionally, as part of Microsoft’s journey to make the Power Pages platform more secure, they have introduced a Dataverse Application User concept. In short, all the actions performed within web applications have a type of user behind them, and each type of user has different privileges.

The SYSTEM user was the one being used by the D365 Solution we built, mentioned in Part 1 of this article. The new introduction made it so this SYSTEM user changed to an Application User, which does not carry the same privileges as the previous SYSTEM user. As such, the Solution we built became restricted, and was not working properly.

The only thing that had to be done was to assign the System Administrator permissions (carried by the previous SYSTEM user) to the new Application User that Microsoft implemented. Once this process was done, our plugin resumed 100% efficacy!

Now that we have covered the technical hurdles we faced while building our Support Portal, we would like to briefly touch on the managerial aspects of implementing the Dynamics 365 Customer Service Portal, namely, the Dynamics 365 CRM training our team had to undergo. As any project manager will tell you, commitment from the team to adapt to the new ways of working can be one of the biggest challenges when rolling out an improvement.

You may know that our team previously conducted customer support via email. Now, team members are required to leave Portal comments or send out meeting invites exclusively through our CRM. To ensure the smooth transition to a new process like this, it was important to inform the team about the reasons behind this so that they could see the benefits, be it from a perspective of the time they can save, to company reporting needs to derive continuous improvement initiatives, or streamlining the customer support experience. Even for our customers, we expect they have also had to adjust to using the Support Portal for their queries, rather than emailing the team members with whom they were already familiar with.

Lastly, the maintenance of our Knowledge Base was another opportunity for change. Now that our Microsoft Dynamics 365 Customer Service Portal provides us with a much clearer view of the queries our customers have been placing, besides providing support, the team must also keep adding the recurring cases to the Knowledge Base to ensure this information is readily available to all Support Portal users.

We look back at these occurrences positively because they allowed us to get our Support Portal to the best possible shape for our customers. Although it was a long project that required the efforts and full dedication of our team members, it has undoubtably paid off. Being able to offer more convenience to our customers, and a strong source of information for us means we have gained leverage to continue achieving our goals, and we look forward to seeing how we can keep optimizing our processes using the Microsoft Dynamics 365 Customer Service Portal.

We hope you have enjoyed learning more about our experience of creating our Support Portal. In Part 1 of this article, we included part of a plugin we built specifically for Microsoft Dynamics 365 Customer Service. This was extremely helpful for us, so feel free to have a look and to reach out for the complete version!