Transition D365 Customer Service module to PowerApps

Having worked with Customer Service Modules extensively it becomes noticeably visible that most of the necessary functionalities can easily be supplemented.    Why should we utilize a Case table with 200 OOB fields who are never to be used? Mindless SLA configurations, “locked up” case categories requiring administration.

In one example, a government-funded organization we have implemented Power Pages as an internal Service Desk site, with PowerApps as a Dataverse.  With Power Pages an evolution of legacy ADX/Microsoft Portals, we would set up an enterprise Portal for +5000 users to sign in and submit any 1 out of 50 different Case types using easily configurable system forms.

With each Service Request being unique i.e., Allocating Assets, Software, Privileges or Feature Requests, our Customer Service module in PowerApps was entirely configurable with necessary features such as SLAs that were more advanced that Microsoft’s OOB, custom Case Ownership Tracker to gain a trail of owning Representative (when, how long etc.,).  That Ownership Tracker is offered for our clients at no added costs, it can produce valuable logs to make better sense of your operations with beautiful PowerBi reports – but that’s for another topic.

 

Essentially yes, D365 for Customer Service module, whether external or internal facing, can easily enough be supplemented not only to reduce Licenses costs significantly, but also to obtain a sleeker Service module for your CSRs altogether.   Let us show you the PowerApps way.