When your Logic Apps are running in production sometimes you will have one which provides more of a support burden than you anticipated. In our case we are using BAM from Serverless360 which allows me to share a business super user/level 1 support operator friendly view of the process but we still sometimes have more support than needed.

In our case the problem interface was generating documents which get displayed in the Power Platform Portals. One of our back office systems triggers an event which then activates a Logic App. This Logic App then pulls in data from a couple of different systems, it then uses the word connector to generate a document from a template, then creates a PDF and saves it in a SharePoint location and creates a record in Dynamics CRM which allows CRM and Portal users to view the document.

At present with BAM we are able to provide a simple interface for our users to show the documents being generated and they can track and trace a document by a number of different properties to see what happened to a document.

When the user opens up the BAM transaction we are giving them a pretty simple view of a much more complex Logic App. They can click on the shapes to see more info about the error and any messages we share with BAM.

When it comes to errors you need to find the balance of which errors are friendly to share to BAM and also with Logic Apps its not that easy to workout what the real error was. We were finding that some of the systems we integrated with arent so reliable so we would have 4 different types of errors which would make the last shape go red. The net result was every time there is an error we are still getting a support ticket to the Integration Team to troubleshoot what happened, we then get the error and tell the user or application teams what needs to be fixed. Usually its some incorrectly setup data or an incorrectly configured SharePoint location.

We made some changes to the BAM transaction to add more checkpoints. The Logic App would then tell BAM each time it hit these checkpoints. We could give the user more granular information about how far through the process we have gotten.

Now when there is a problem the user can see how far we got and from the shape that gets the error (or the last one to execute) the super user can usually check some things in the application and resubmit the document generation themselves. We are able to remove the need to raise a support ticket to the integration team for all 4 of the types of problem and in most cases there is no need to raise a ticket to IT at all.

A small change, a big win, happier users, lower support costs.

 

Buy Me A Coffee