What Dime.Scheduler is designed to do
If you look at the visual diagram below, you'll notice that Dime.Scheduler hinges on the data input of other systems. These systems - typically centralized and mission-critical - provide the necessary data to allow planners to schedule the organization's resources and work.
While Dime.Scheduler is technically able to run without those systems, its power is truly unleashed when it is combined and integrated with the existing technological landscape. As a result, Dime.Scheduler is only concerned with planning, nothing else. The main artifact that is produced are appointments, which merely represent what work will be done (the task), by whom (the resource) and when. However, as simple as that may be, it can be tremendously powerful when that information is used by the connected systems, because it can yet another level of automation in the company, providing heaps of benefits.
Dime.Scheduler is built with performance and scalability in mind. Therefore, it is based on a loosely coupled architecture that separates the main planning application from the connected plugins, which are responsible for interacting with external applications.
As far as the user is concerned, the application consists of nothing more than an application accessible via a web browser. Real-time updates are sent to and from the back office systems, which means users can keep on working on the latest state of the system - eliminating the need to refresh components or pages manually.
As soon as the user has been authenticated, the application will retrieve the profiles and (defaults) layouts and will apply the security filters so the user gets to see a tailored version of Dime.Scheduler. Users and administrators have tremendous amounts of configurable elements at their disposal so it is possible that users will get to see vastly different sets of components and data.
The previous paragraph brings us to a key tenet: it's all up to the users (and administrators for that matter). Dime.Scheduler is used in a wide array of industries where planning processes can vary greatly. Even within an industry it is likely that organizations will have different requirements and planning methods. That is why Dime.Scheduler offers a heap of components - with their own distinct feature set - and lets the users handle the rest by themselves. In that regard Dime.Scheduler is more like a framework than it is an application that defines the way of working.
The story continues when data is synchronized from and to the back office systems: organizations may implement their own business logic and their own (vertical) solutions. Dime.Scheduler ultimately provides the framework and the building blocks for the planning process, it is up to the users to decide how they wish to work.
For the aficionados, this is the schema that represents the overall architecture: