Hi Mathias,
we have noticed that the current implementation of deadlines combines two different functions:
- Technical deadlines that are used to manipulate the state of a process. For instance, if deadline is not met, automatically forward a workitem in process.
- User-deadlines, that inform user when a certain activity shall be completed / should have been completed but it was not.
Users would like to see only the deadlines of 2nd type, since only those affect them ("how much time have I left" / "is activity already late"), while technical deadlines are not of their interest.
The current implementation is always showing the first-incoming deadline of the process, which is confusing to users in certain scenarios.
To make it more understandable, let us observe a simple use case: "Proofread document" that shall be completed in 14 days.
If not, it is forwarded to manager of the department without further deadlines.
In order to limit the number of documents escalated to management, process participants are reminded that they have a document that should be checked, by an email that is sent 7 days after the process is started.
This can be modeled with a simple model that contains a single activity, and this activity has two deadlines:
- duration 7 days, after it expires, an email is sent by script
- duration 14 days, after it expires, process is escalated to manager (manager is set as process-responsible per script, there is no deadline for manager)
The problem with this approach is that user sees in client that first deadline is about to expire in 7 days (which is "wrong" from the use-case perspective, since user still has 14 days) and once it expires, user will see that a deadline is again in 7 days.
User should not see a warning that the first deadline is coming/broken (since it is send-email deadline). But user should see the second deadline ticking and manager who gets it after escalation the task should see that activity is already late (however, the manager should not see that 2 deadlines are expired, since first one was purely technical...). So, currently, whatever we do, there are cases where deadlines will be shown in a wrong way. Either we show one late deadline too much (email-deadline) or one too few (escalation deadline).
To resolve this, we have decided to
- remove red markings after deadline expiration (reduce false alarms
and confusion with users)
- separate the technical deadlines from activity-related deadlines in one of future releases. Only the later will be prominently shown in client (including visual cue that they expired).
To make long story short - yes, the current behavior is not optimal, and yes, we plan to improve this to make it more usable.
If you have further ideas or feedback, please let me know.
Best regards
Bratislav
