It is often forgotten, but the screen error messages are often the only visible client-facing part of a BRMS, so this is a way to really add value.
[Consider a change of perspective: merely calling them “error messages” under-sells what are the best efforts of the subject matter experts and the business analysts to give the best service to the client.]
To analyze this correctly consider, for each error message:
- Does the message clearly explain the problem, and how to fix it.
- Are the terms used familiar to the user.
- Are the names used the same as on the wireframes/screen
- Should any data items be included in the error message to help the user locate and correct the error.
- Does the error message constitute data leakage (security).
Example:
BAD: warning product code – product code combination.
GOOD: on line 6 of your order, product code 12312314 (“widgets lh thread”) is incompatible with line 7 product code 987878393 (“bolts rh thread”). Press OK to accept the order anyway, or CHANGE to modify your order.
For users with sensitive data and rules care needs to be taken to specify the messages with a level of ambiguity suited to the sensitivity of the rule. For example a business may accept applications for refunds online, but not want its refund policy made public.
Here, RETE algorithm rule engines (DROOLS, ILOG) have one great advantage over other BRMS systems: the data is automatically marshalled to the RHS as tuples. This means that error messages coming from the engine can be very rich, and include all the relevant data, with almost no effort on the part of the developer: the right data for the right entities is automatically prepared.
.