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