An important concept to understand is that Dime.Scheduler consists of different configuration layers, as depicted in this image:
For the most part, this configuration is cascading. Administrators determine the default behavior of the application. Users have some options to deviate from the default behavior by customizing user profiles and components (layouts). This segregation of duties may seem complex at first but it's the only way to ensure the system is flexible and predictable at the same time.
The highest level of configuration starts even before Dime.Scheduler is running. The static configuration is rather technical with items like logging levels or connection strings, but clearly they are crucial to get the system even started. In fact, they are so fundamental the application needs to be restarted when changes are made.
The next level of configuration is (also) part of the administrator's responsibility. In contrast to the static configuration, the global configuration has consequences on the functioning of Dime.Scheduler's planning capabilities. For example, turning on the "Apply requested dates" switch will have a profound effect on the planning board.
The following two configuration levels are within the realm of the planner. Users can manage their own profiles and layouts. Some buttons and switches override the higher levels (such as the "unit of distance" flag or the "ignore calendars" mode on the planning board or appointment) while others merely extend the application's behavior (like the planning board's start date or snap interval).
The rule of thumb in this multi-layered configuration mechanism can be defined as follows:
ℹ️ The highest level of a given configuration item is applied unless it is overridden by a lower level.
The highest two levels are fairly simple to understand given there are only so many setups to do. However, profiles and layouts have no limits, which can result in very different planning views.