Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      


Updated on January 14, 2022

A message is dynamic text that communicates errors, warnings, or other types of information to users. By using messages instead of static text in your user interface, you can provide contextual assistance to users that supports localization.

> Message format

Each message has a definition that contains text and references to input parameters. In the following message definition, references to input parameters are in braces. The numbers correspond to the order in which you define the input parameters on the Message form.

The {1} must be later than {2} and at least 30 days before {3}.

When you call a message, you pass a tab-delimited string that starts with the message name and provides run-time values for the input parameters. You can pass literal values or property references to a message.

The following strings are example inputs to the DateRange message above:

  • DateRange\tstart date\ttoday\tthe end date

  • "DateRange\tstartdate " + .StartDate + " \tJanuary 1, 2006\ttoday"

  • Creating a message

    You can create a message to display text with run-time values to users. By using messages instead of static text, you can avoid maintaining a set of strings for each possible context and user locale in your application.

  • Finding messages in your application

    You can use the Records Explorer to find the messages that your application defines. By understanding which messages exist and when they are called, you can quickly decide whether you need to create a new message.

  • Creating a custom message category

    You can extend the standard categories for messages. By defining custom categories, you can create and classify messages in a way that is specific to your business.

  • Displaying a warning message in a rule

    You can display a warning message in a rule based on criteria that you define. By calling attention to configurations that do not follow best practices at design time, you can help users improve their compliance score before they take their application to production.

  • Standard functions for messages

    You can use standard functions to evaluate messages in your application. By understanding the errors and warnings that are associated with your application, you can debug issues quickly and improve your guardrail compliance score.

  • Updating legacy messages and related rules

    You can update your legacy messages so that they are compatible with the latest definition of the Rule-Message class. By providing values for the new properties that all messages must support, you can ensure that your legacy messages and the rules that rely on them continue to function as expected.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us