This article guides you on applying actionable errors to offer users recommended actions for more effective error resolution. It covers the key questions that error dialogs and validation errors should address, along with recommended voice guidelines for writing impactful error messages.

Improving error handling and error messages reduces friction for the users and highly impacts the user experience. Clear, informative error messages help users understand what went wrong and how to correct it, reducing frustration, and improving user satisfaction.

For guidance on how to formulate good error messages, see Error message best practices - what to say? in the following section.

With Business Central 2023 release wave 2, the error handling framework has been enhanced to include promoted actions in both error dialogs and validation errors. These promoted actions are designed to assist users in resolving errors more effectively. There are currently two main scenarios to keep in mind when deciding how to use recommended actions:

• Fix-it actions are recommended for scenarios where the system knows the correct value that should be used to resolve the error.
• Show-it actions are recommended for scenarios when the system can identify the location where the error may be fixed by the user.

Here are some quick guidelines on when to use each type of error message and its accompanying recommended actions. However, it's essential to begin by considering whether the error could have been avoided in the first place.

Fix-it actions are for when the correct value is known. If all the following four statements are true for your error case, then consider adding a recommended Fix-it action in your error message to enable users to easily unblock themselves from the error.

1. Is the solution to the error known?
2. Is the error location on the current page?
3. Can the error (value) be corrected with one action?
4. Does the user have permission to make the required correction?

Example of an error message with a Fix-it action:

Example of a validation error dialog with a Fix-it action:

For more information, see Error messages with Fix-it actions

Show-it actions are for when the error location is known. A shortcut can then be provided to show the related page to enable users to easily unblock themselves from the error. If all the following four statements are true for your error case, then consider adding a recommended Show-it action in your error message.

1. Is the solution to the error known?
2. Is the error correction location known and is it on a related table?
3. Can you show the related table with one action?
4. Does the user have permission to make the required correction?

Example of an error dialog with a Show-it action:

Example of a validation dialog with a Show-it action:

For more information, see Error messages with Show-it actions

Error messages are meant to unblock users. The primary purpose of the error dialog is to alert users to the fact that something has gone wrong and that they need to take action to continue. In the following, you find best practices for what to say in an error dialog versus in an in-line validation error situation.

Error dialogs should answer the following questions:

Title: [What went wrong]
Body content: [Why, if relevant] + [How to fix it]
Button label: [Clear action]

Validation errors should answer the following questions:

Title (if needed): [What went wrong]
Body content: [How to fix it]
Button label: [Clear action]

Use the following guidelines to remove friction for the users and positively affect the user experience, even when an error occurs.

The title of an error dialog is the first thing the user sees. Use the title to describe what’s wrong and enable the user to quickly scan the meaning.

• Be concise and describe the issue, not the action to take.
• Be brief. Just one sentence.
• Titles shouldn't end in punctuation.
• Not all validation errors need a title.
• Keep in mind the relation between the title and the recommended actions. Actions should always respond to the title if there's one.

In the body of the error dialog, use positive cases (telling what the user can do) where possible. Sometimes you need to tell what you can’t do, but for validation errors space is limited, so focus on the solution.

When you need to use error dialogs, where possible use a Fix-it action or a Show-it action. To achieve consistency in the user experience of such error dialogs, consider following these guidelines for button labels.

For Fix-it actions, consider

• Fix-it actions are often phrased: “Set value to...”.
  • Such as: “Set value to 10”, “Set Status to Open”, or “Set value to HOME”.
• Fix-it action tooltips are often phrased: “Sets the value...”.
• Value states are capitalized such as: Yes, Open, Released. Avoid signs for values such as = ,“”, ().

For Show-it actions, consider

• Show-it actions are phrased: “Show...”.
  • Such as: “Show User Setup”, “Show Items list” or “Show Item 70062”.
• Show-it action tooltips are often phrased: “Opens page:..”.
  • Note: Avoid using “Open” for the button label, as it can be confused with opening the status of the document. Instead use “Show” and use the tooltip to write out “Opens Page:...”.
• Captions are capitalized, such as: Item, Direct Posting and G/L Account.

When writing error messages, consider using these overall rules of thumb:

• Use the word problem instead of error, issue, or technical problem.
• Refer to the error message as a message and not an error or error message.
• It’s OK to write "please" when asking the user to resolve a problem that isn’t their fault.
• Only use "sorry" (and similar wording) in error messages that notify the customer about a serious problem or one that they might find frustrating. For example:
  • Data is lost.
  • The user can't continue to use the device, service, or application.
  • The user must get help from a support representative.
  • A product or service fails.

To write error messages that are simple and feel human, consider using contractions:

• Use common contractions, such as it’s, you’re, that's, and don’t, to create a friendly, informal tone.
• Don't mix contractions and their spelled-out equivalents in UI text. For example, don’t use can’t and cannot in the same UI.
• Never form a contraction from a noun and a verb, such as Microsoft’s developing many new cloud services.
• Avoid ambiguous or awkward contractions, such as there’d, it’ll, and they’d.

In error situations, it's crucial to show users we’re on their side. Utilize plain language and steer clear of the following words and phrases:

• “There was an error” or “An error has occurred”
• “Error,” “Failed,” “Denied,” or “Invalid”
• "Hmmm ..." or "Oops ..." or "Whoops"
• Developer error codes like “WDGeneralNetworkError Error 500”. If you need to include a code, hide it under “details”

Remember these rules of thumb:

• Don't overwhelm the user with technical terms
• Avoid robotic language and characters such as =, ", and ()
• Avoid long how-to or instructional guidance in errors. That content lives on docs.microsoft.com or in your documentation.

For more guidelines on how to communicate to the user in a way they understand, see Microsoft's brand voice: Above all, simple and human.

Microsoft’s voice guidelines
Actionable errors
Understanding the error dialog
Dialog.Error(ErrorInfo) Method
AL error handling