Event Type Hierarchy Guidelines
Guidelines
In creating your Event Type Hierarchy:
• Make sure each portion of your Hierarchy is complete and accurate to minimize the need to change it later.
• Build your Hierarchy to take maximum advantage of the default event routing rule used to route newly imported classes into the Series25 database. See
“The default routing rule” • Start small and add complexity later, if necessary; for example, create one cabinet type with academic and special events folder types. Add additional folder types later if needed.
• Create as many event types as you need, but don’t define so many that users find it difficult to know which to select for an event. If you define too few, events may be harder to sort, and you’ll have less opportunity to take advantage of the feature that allows you to associate data properties for different event types.
• Don’t organize your Hierarchy based on where events occur. Security and location assignment policies handle locations.
Examples
Starting below are examples of Event Type Hierarchies for scheduling environments that require maximum simplicity, a little more complexity, or maximum complexity. None require a complicated Event Type Hierarchy. The type names used are only examples. You should name your types appropriately for your scheduling environment.
| Maximum simplicity If your institution is small with mostly centralized scheduling, you need only a very simple Event Type Hierarchy like the one described in this example. • An “All Events” cabinet type • Within the cabinet type, two folder types—one for grouping sections imported from your SIS (“Imported Sections”) and one for grouping non-academic events (“Events Group”). • Within the Imported Sections folder type, a “Class Section” event type, and within the Events Group folder type, an “Event” event type. This hierarchy identifies all events in the system as either imported sections or manually scheduled events.  |
| A little more complexity If your institution is mid-sized with fairly centralized scheduling, you might consider a slightly more complex Event Type Hierarchy such as the one described in this example. • An “Imported Sections” cabinet type and an “Events” cabinet type • Within the “Imported Sections” cabinet type, a “Section Group” folder type • Within the “Events” cabinet type, an “Event Group” folder type • Within the “Section Group” folder type, a “Class Section” event type • Within the “Event Group” folder type, as many event types as you need (Meeting/Gathering, Student Activity, Conference Event, and so on)—a collectively agreed upon list for use by all schedulers  |
| Maximum complexity If your institution is large with mostly decentralized scheduling and multiple campuses, you will probably need a more complex Event Type Hierarchy such as the one described in this example. • An “All Events” cabinet type • Within the cabinet type, a folder type for each campus (“Downtown Campus,” “Main Campus,” and so on) to group imported academic sections by campus and a folder type for grouping non-academic events (“Event Groups”) • Within each campus folder type, a single event type that represents sections for each campus code in your SIS (Section-DC, Section-MC, and so on). • Within the “Event Groups” folder type, as many event types as you need (Meeting/Gathering, Student Activity, Conference Event, and so on)—a collectively agreed upon list for use by all schedulers  |
