As seen ealier, some workflow use cases are made of a sequence of activities, e.g. PREPARE consists in profiling the schedule followed by computing the potential overlaps.
Besides, we also need to know when a view state is blank or complete.

The current view state allows for determining the workflow use case that the view realises at the moment, but not for determining the current step in the current workflow use case realisation.

Because the front-end needs to indicate to the actor the current activity in the current view state, and whether it is blank, complete or none of these, view sub-states are needed: they are indicted in the top right corner of the

1. INITIAL view state:
   1. INITIAL_BLANK: view sub-state after the view was created or cleared
   2. UNDER_BUILD: view sub-state after any schedule modification, after initialisation and after quality check when the result of quality check does not lead to a complete view state
   3. BUILD_COMPLETE: view sub-state after quality check when the result of quality check leads to a complete view state
2. BUILT view state:
   1. BUILT_BLANK: view sub-state after the INITIAL view state was stepped forward
      Note that there is also an internal sub state BUILT_BLANK_WITH_TEMP_DATA which is always shown to the user as BUILT_BLANK and all logic depending on sub states also uses it as a BUILT_BLANK substate.
      This BUILT_BLANK_WITH_TEMP_DATA view sub-state exists during profiling or after a profiling operation has been interrupted.
   2. PROFILED: view sub-state after the schedule was profiled
   3. OVERLAPS_COMPUTED: view sub-state after the potential overlaps were computed
3. PREPARED view state:
   1. PREPARED_BLANK: view sub-state after the BUILT view state was stepped forward, or after the detection setups were modified by the view user in DECONFLICT.
      Note that there is also an internal sub state PREPARED_BLANK_WITH_TEMP_DATA and SETTINGS_CHANGED_BUT_CONFLICTS_NEED_REDETECTING which are  always shown to the user as PREPARED_BLANK.
      All logic depending on sub states also uses it as a PREPARED_BLANK sub-state.
   2. CONFLICTS_DETECTED: view sub-state after the first conflict detection and as long as the detection setups were not modified by the view user in DECONFLICT