Latest Blogs

Responsibility for timetabling at educational institutions is often distributed across different departments or business units, or between several people in a central timetabling team. As such, it can sometimes be difficult for a timetabling manager to keep track of what different users are doing within the system and, possibly, creating clashes that are not resolved.

A quick word on terminology here. CELCAT classifies a variety of problems as “clashes”, but the term can be interpreted as meaning “clashes with the institution’s rules or policy” rather than double-booking (double-booking being just one kind of clash that CELCAT can detect and report, albeit the most important). Where this terminology can cause confusion, many users employ the custom terminology feature to rename the word “clash” within the system to something more generic, such as “problem” or “conflict”.

CELCAT provides a wealth of clash-checking tools, and the first step in ensuring the system can accurately guide users and report on problems is to decide (at a relatively high organisational level) what kind of clash checks are critical. These should be switched on by an administrator and enforced (so that non-admin users can’t disable them within their own accounts). At the very least, these should be the “deal-breaker” problems for all timetabling, such as the double-booking of a physical resource (i.e., a room, staff member, student, or group of students).

The next step would be to ensure all users have Dynamic Clash Checking turned on (which can be found in the General section of the General Tab of the Global Preferences page). Dynamic clash checking provides an immediate warning to users whenever they create a clash. The types of checks that can be reported on dynamically are indicated by a lightning bolt on the Clash Checks preference screens. This feature can’t be enforced, but it is a good idea to inform users to only disable this in unusual circumstances where they will be making many intermediate changes that create temporary clashes and would be constantly interrupted by clash warnings. Even in this case, they should remember to turn the checking back on afterwards.

Making sure all users have Dynamic Clash Checking enabled is a good first step in ensuring they resolve any clashes they create, but warnings can still be dismissed, ignored or forgotten about. For instance, a user could create a double-booking for a room, then get distracted, or called away from their desk, or simply opt to close the warning with every intention of coming back to it later- but forget.

The same goes for the Clash Checking Wizard, which can be manually invoked either for a specific event, all the events on a visible timetable grid, or a manual selection of resources, weeks, times and users. While this wizard is a powerful tool, its output can still be dismissed or ignored.

This is where Clash Logging comes in. If (as in the screen above) some clash types are marked as ‘Log when found’, then every such clash is logged in a list as it is discovered. For instance, if a user creates a room clash by dragging an event somewhere, then dismisses the dynamic clash warning and forgets about it, the clash is still logged in the background. Likewise, if a timetabler runs the Clash Checking Wizard on a timetable and dismisses the output, or fails to resolve them all, the remaining clashes are still visible in the Clash Log.

Any user can access the Clash Log from the View -> Logged Clashes menu option. From here, a timetable manager can see all the currently unresolved clashes in the system, as well as the username that generated, or discovered, the clash. They can assign clashes to specific users, filter the clashes by their currently assigned users, double-click to access the events involved in a clash and try to resolve it, or accept clashes (with optional notes) to remove them from the Clash Log. The ability to accept clashes is governed by Role Access, so ordinary timetablers can be prevented from accepting a clash and will have to escalate it to an admin user- along with a justification as to why the clash should be removed from the log.

However, this remains a voluntary action that a user can simply choose not to do. For this, CELCAT provides a very powerful, and often overlooked, setting. Under Global Preferences -> General, there is an enforceable option to display Logged Clashes:

• On demand (the default) where users must actively seek out the report.
• On login, which makes a user’s list of clashes the first thing they see after logging in.
• Always, which is as the previous setting but hides the close button making it permanently open in the background to constantly remind users of any unresolved clashes they caused, or discovered, in the system.

This last option (along with enforced clash checks) is the ultimate option for making sure no clash falls through the cracks and all users are always aware of the outstanding clashes they are responsible for. Users may dismiss the dynamic clash warnings, or close the results from the Clash Check Wizard, but, if any of those tools report a clash the user never resolves, it remains in the Clash Log. If the Clash Log is enforced to always be displayed, it will be the first thing they see on logging in and remains an open tab (or window) in their workspace that can’t be closed or hidden. A policy that all users ensure their Clash Logs are clear at the end of each working day is one good way to maintain timetable quality across a team, or even where timetabling is distributed among many users across different departments.