Actionable Error Messages in Business Central

Introduction

Error handling is an important concept in every technical field. 
It helps programs deal with unexpected problems and mistakes smoothly. 
It makes sure software works reliably and doesn't crash unexpectedly. 
Error handling also helps developers find and fix issues quickly, making the software better for users. Plus, it gives users clear messages when something goes wrong, making their experience smoother.
It shows that the team has considered the scenario and has measures in place for it indicating a well designed solution.

Microsoft has an amazing document which lists the things to keep in mind for writing resilient code.
In Business Central, we have try functions to handle errors and error function to show those errors to the Users. 

In this blog, we'll learn how we can enhance the error messages so that the Users can resolve the errors themselves or at the very least we can point them towards where the error is.

Pre-requisites

Business Central OnPrem/Cloud

References

Explanation

Before we get to the code, let's set a little context.
For Error Handling, Microsoft has two categories in Business Central,
  1. Fix-it errors occur when the error location is on the current page, and the correct value to resolve the error is known. 
  2. Show-it errors happen when the error location is known, but the correct value to resolve the error isn't known.
ErrorInfo is a data type used for error handling and reporting. 
It can be used to hold information about errors that occur during the execution of code.
It has additional properties and actions that can be used to define it's behavior to the end-user.
The ones that are most useful as -
  1. Title - Describes the title of the error.
  2. Message - Show a message to the user.
  3. Detailed Message - Include additional information to the error, hidden from the user, for the person troubleshooting the error.
  4. Add Action - Adds an action to the error message, generally of Fix-It type.
  5. Add Navigation Action - Adds an action to the error message, which can be used to navigate from one page to another, used for Show-it type errors.
The "Add Action" procedure takes a codeunit and a method name as input.
To pass input into this procedure, we add an "ErrorInfo" object as a parameter to the function and if we want to specify some details of the record where the error is happening or where the fix is to happen, we can use the following procedures.
  1. RecordId - We can use this to pass the record id from the error origin to the procedure which handles the error.
  2. Custom Dimensions - We can use this to pass key value pairs of data from the error origin to the procedure which handles the error.
  3. Table Id - We can use this to pass the table id from the error origin to the procedure which handles the error.
  4. Field No. - We can use this to pass the Field No. from the error origin to the procedure which handles the error.
The "Add Navigation Action" only takes a method name as an input.
So, to tell the action which page and which record to open we have the following procedures.
  1. Page No. - Specifies the Page No. to be opened by the navigation action.
  2. System Id - Specifies the SystemId of the record to be opened on the Page No. specified.
If you are passing the Page No. and System Id to the procedure which handles the error then the same can be accessed there as well.

Code

Here, I've taken a sample scenario where the value of one field depends on the value of another field on the Sales Order.
Basically ;-  
  1. "Some Mandatory Type" must have a value.
  2. If "Some Mandatory Type" is set to "Blank" then the "Some Mandatory Field" should be empty.
  3. If "Some Mandatory Type" is set to "Not Blank" then the "Some Mandatory Field" should have a value.  
I've set it up so that these validations are triggered when the Sales Order is posted.



And the same thing goes for the "Not Blank" scenario so I'm not writing it for now.
So, if I try the second scenario where Type is "Blank" and Field has some value then we get the following error message.



If I click on the "Copy Details" I can see the detailed message that I added for this Error Info.


If I click on the "Make Mandatory Field Blank" action then I can make the "Some Important Field" as blank.



The code behind the action - "Make Mandatory Field Blank" is as follows- 


I've used messages to confirm that the values that I passed during the origin of the error are flowing into the procedure.
Here are the messages - 






Now, some of you might be wondering, if this was a error message where one field was dependent on another then it should've been a validation.
And yes! 
That is correct and here is how it would look.


Here, I've used both "Add Action" and "Add Navigation Action" on the ErrorInfo.
For the Parameters, all of the parameters are pointing to the Customer.


This opens the Customer Card for the specified Customer.


Conclusion

You can refer the "Actionable Errors" documentation for the best practises and patterns for which type of actionable error to use and where to use it.
Thus, we learned how to utilize actions within error messages in Business Central to assist users in resolving errors more effectively.

Comments

Popular posts from this blog

Using Notifications in Business Central via AL

Configure Gmail SMTP service in Business Central without "Allow Less Secure" setting