Message lifecylce
This article describes the lifecycle of a message, from creation to completion.
Creation
When creating a message, consider the following points:
- When and for how long should the message be valid?
→ General - How should the message be displayed to the user?
→ Appearance - Should the users be pre-warned?
→ Early warning (avaliable only in message groups for desktop clients) - Which users should be informed?
→ Restrictions for desktop clients
→ Restrictions for mobile clients
Example
A user reports that an application can not establish a database connection. To ensure that the support is not overloaded with calls, users should be informed that the problem is known.
- When and for how long should the message be valid?
→ Start time: Now
→ End time: In 2-3 hours - How should the message be displayed to the user?
→ Appearance: Insertion
→ Check Hide end time as it is not exactly foreseeable when the problem will be solved - Should the users be pre-warned?
→ No, because the message should be displayed immediately - Which users should be informed?
→ Restrict the message to the affected application
Update
When updating a message, consider the following points:
- Should properties be adapted?
→ Adjust the corresponding properties - Should the user be informed?
→ Add status update
Example
Solving the database connection problem takes more time than previously estimated. The message must therefore be updated and the users informed accordingly.
- Should properties be adapted?
→ Shift the end time one hour in the future - Should the user be informed?
→ Yes, add a new status update "We are still working on solving the problem, further information in 30 minutes" as an insertion
Completion
When completing a message, consider the following points:
- Should the user be informed about the completion?
→ Add a resolve message or Resolve now
Example
- Should the user be informed about the completion?
→ Yes, complete the message using Resolve now so the resolve message will appear as an insertion