Building Calendars Using Event Categories or Resources

There are two primary approaches for building major calendars, each with a process for vetting events prior to their publication on live web calendars:

1. Using Event Categories and Calendar Event Requirements
2. Using Calendar Resources

Each approach is expanded below, along with a list of data preparation steps that must be completed prior to use. Both require access to the 25Live System Settings and Series25 Group Administration.

Using Event Categories and Calendar Event Requirements

This is the most popular method for ensuring that events are properly vetted prior to publication. The workflow is as follows:

1. A requestor selects a "Publish to Web" Event Requirement (Calendar) in the Event Form to indicate that they want to publish their event. 
2. This Event Requirement triggers a notification task for a calendar approver to review. 
3. The calendar approver reviews the event and tags it with the appropriate calendar category.
4. The category is part of a 25Live event search that gets pushed to Publisher.

This method requires several steps of data preparation, which will be expanded upon in the subsections of this article. They are:

1. Creating Event Categories for each major calendar
2. Restricting general user access to Calendar Event Categories
3. Creating at least one Event Requirement (Calendar) and applying Notification Policy to that Event Requirement
4. Updating Event Forms:
   1. Adding a "Publish to Calendar" editor to the requestor and scheduler forms
   2. Adding a "Category" editor to the calendar approver form

Event Categories for Major Calendars

Institutions using this approach often build an event category for each major campus calendar. These categories are attached to events and are used to build the event searches that are later pushed to Publisher as Feeds. These feeds are live, perpetually updated connections that keep your 25Live published calendars current with the data in 25Live. 

Event categories are defined in the Master Definitions → Categories → Events tab of the 25Live System Settings. Calendar categories are typically limited to a small number of major named calendars that face a large internal or external office (e.g., Academic Calendars, Athletics Calendars, Major Events, Student Life, etc).

• The Cabinet where the event is saved (to differentiate courses from special events)
• An event state of "Confirmed" (to ensure that tentative events are excluded from calendars)
• A section including the category of any calendar the event will populate (select "Include Any")
• A section excluding the category of "Do Not Display on Web Calendars" (select "Do Not Include")

Restricting general user access to Calendar Event Categories

It is important to ensure that only calendar approvers and administrators have access to tether Calendar Event Categories to reservations. Giving this access to general users would sidestep the approval process and allow them to add their reservations directly to published calendars. 

There are two ways to restrict general user access to Calendar Event Categories –

1. You can choose to hide the Event Categories editor from Requestors entirely by turning it off in the Event Wizard Custom Configuration in the 25Live System Settings (see Event Categories and 25Live Publisher).  
2. You can instead utilize functionality that allows administrators to provide an abridged list of event categories to requestors.  This approach gives requestors access to the Event Categories editor in their Event Form but limits the categories they can see to a pre-configured abridged list of options (with calendar selections hidden from view).  
   
   For this option to work appropriately, you must adjust the functional level security settings for requestors.
   
   
   1. Navigate to the Group Administration tool.
   2. Select the security group(s) you wish to restrict and click Basic Options tab and locate Rule #13.0 and make sure the answer is No.

The "Publish to Calendar" Event Requirement

The "Publish to Calendar" Event Requirement gives requestors the opportunity to indicate whether their events should be considered for publication while maintaining the data integrity of the calendar event categories. When requestors select the "Publish to Calendar" Event Requirement within the Event Form and save their events in a tentative or confirmed state, a notification task is sent to an approver to review. 

The following steps outline the process of building a Publish to Calendar Event Requirement in 25Live Pro:

1. Log in to 25Live Pro and in the More menu select System Settings → Master Definitions.
2.   Click the Requirements (Calendar) link in the Events section of the landing page.
   
3. In the Event Requirements (Calendar) sub-tab, click the Create New button.
   
4. Enter the text for the new Event Requirement you are building and click Save.
   
5.  The new requirement has now been created and a Notification Policy must be built to alert calendar gatekeepers when the requirement has been selected.  Click the Show button on the event requirements.
   
6. In the Notification Policy Approval Type drop-down list, select By at least one.
   
7. To add an approval time period from the Event Creation Date, add a number to the Days, Hours, or Minutes of the Approval required within text boxes.  Enter a name of a contact in the Search for Contacts text box and click the Search button.
   
8. Click the name of the contact to add them to the Selected Contacts list for the Notification Policy you are building.
   

9. Click the Notification Policy type drop-down box to view the options for this Notification Policy for this Selected Contact.  For requirements, it is typical to select the option Approval Required.
   
   

   It is important to remember that Notification Policy does not function the same as Assignment Policy. Please read 25Live Pro Help - Viewing Tasks for more information.

10. Once you have added the contact(s) you want applied to the Notification Policy for this Event Requirement (Calendar), click the Save button.
11. Click OK once you are notified that the notification policy changes have been successfully saved.
12. Next, you will need to add this Calendar Event Requirement to relevant event types. Click Event Types → List from the left menu of options.
    

13. Make sure that the Event Types List toggle is set to Event List and click the name of the first event type you would like to modify.
    

    Selecting Multiple Event Types

    You can select multiple event types and apply the same Publish to Calendar event requirement(s) to all of them at once. However, if certain event types are only sent to one type of calendar, you can add the event requirements to each event type separately.

14. The Edit Event Type editing window contains all of the customizable fields for the selected event type(s). Scroll down the editor until you find the Requirements (Publish to Calendar) section.  Click the Select Requirements button to add new requirements to the list.
    
15. All of the event requirements (calendar) will be displayed for selection. The ones you check will populate in the Event Form when this Event Type is chosen.  Click the checkbox next to the event requirement(s) that you want to enable and click Done.
    

16. Save your changes.

Updating Event Forms

1. Logged in as a system administrator, click the System Settings option in the menu.
   
2. In System Settings, look for the Event Form Settings tab and click on Config Settings to select a custom configuration to edit.
   

   
   

   Multiple Event Wizards

   The majority of campuses have set up at least two custom event wizards, normally one for requestors and one for schedulers. Some campuses have more than two custom event wizards. You will need to edit each event wizard to include the Publish to Calendar Requirement Editor in order for users to send a notification to a calendar gatekeeper concerning their event. Neglecting to complete this step blocks users from seeing the option to notify calendar gatekeepers of event publication needs.

3. The Custom Configuration for your selected Event Wizard will load below. Scroll down the page until you locate the Publish to Calendar editor.
   
4. On the selected card, select Visibility Level: Editable to make the Publish to Calendar editor available.
5. Click the Save button to save the new wizard configuration.

With these elements built, requestors will now have the ability to check a calendar requirement when they are building their events in the event wizard and trigger the processes for notifying a scheduler to tag the event with the appropriate event category.

Using Calendar Resources

One of the chief complaints with the Publish to Calendar requirement and the associated use of a Notification Policy is that notification policies inherently lack teeth.  If the individuals or group of individuals set to "approve" or "deny" a Publish to Calendar requirement deny the request but a Scheduler with access to the Event Categories attaches a Calendar category to an event that event will show up on the public calendars regardless of the denial being logged on the notification policy.  An alternative approach to vetting events for publication to 25Live Publisher live web calendars uses Resources.  The greatest advantage to using calendar resources to build the major calendar feeds is that you are able to use Assignment Policy to enforce denials by individuals in the functional security group(s) you have designated as official vetting agencies. Approaching the process in this fashion requires a number of preparatory steps in order to be successful including the following:

1. Determining how many different approvers you will need for each of your major calendar resources (some users might approve Student Life events while a different group of users would approve Main Calendar events),
2. Determining which individual users will be responsible for approving calendar resources,
3. Building functional security groups for each of these different service provider groups,
4. Attaching the appropriate contact records to each of the new service provider functional security groups,
5. Building the calendar resource records for each of the appropriate calendars,
6. Setting appropriate object level security and assignment policy on each of the calendar resource records, and
7. Building appropriate event searches for publication as 25Live Publisher feeds.

The first four steps using this approach are standard administrative tasks in 25Live and are covered in other documentation to 25Live.  However, it would be beneficial to use the Service Providers functional security group template in building this security group.

But note, if you use the Template to build the security group, you will need to set object security and assignment policy on all objects in the database.  Also, if you use the default template, be sure to review the default security settings to ensure that the users in this group have appropriate functional rights to request events as well.  Another approach would be to copy an already existing service provider security group and then modify its object security and assignment policy settings.  The latter approach is the less time-consuming of the two approaches.

You will also want to name these security groups so that it is clear that they are calendar approvers.  This step makes it easier for administration of your functional security groups over the long term.

The Calendar Resource records may be named just like you would name Calendar Event Categories.  Using the calendar event categories illustrated in the approach discussed earlier, our calendar resources would look something like the following records:

1. Calendar - Academic,
2. Calendar - Athletics,
3. Calendar - Intramurals,
4. Calendar - Main Events, and
5. Calendar - Student Life.

Obviously, the calendars you choose to use resources for vetting events will likely be a small subset of all the eventual calendars you may build with Publisher.  But, when building these resources, be sure that you do not set a stock total on these resources as they are an unlimited resources and may be used over and over again.  Setting a stock total would limit the number of events that could have each resource record applied on a single day.

To make finding all of your calendar resources easier, you will want to add a Resource Category to your database.  Adding a Calendars resource category will give you a way to group all of the calendar resources together easily in a public resource search making it easier for Requestors to find all of the calendar resources.

To prepare resource records for 25Live Publisher live calendars, add a resource in 25. See Creating Resources. Then, view the resource details and use inline editing to choose the Calendars category.

In the Series25 Group Administration tool, set Object Security so that the majority of functional security groups can view and assign. The System Administrator and Functional Administrator will be able to edit, delete, and copy the resources and have assign/request rights.  The Publisher User Account and the public search user account should also be able to view event availability.

Repeat copying and adding until you have added all of the Calendar resources you need to add.

You are now ready to begin using Resources as part of your searches for major published calendars in 25Live Publisher.

Using Resources as the method for routing events to major published calendars relies on the Calendar resource being assigned to an event.  It requires a slightly different search for these major calendar.  Until an approver actually approves the use of the Calendar resource on an event, an event will not appear on the calendar using that resource in its searches.

The two approaches most commonly used for building major public-facing calendars both work effectively to accomplish the end goal of vetting events for publication to 25Live Publisher web calendars.  Both approaches use an intermediary to review the event and make a determination of whether the event merits being added to a requested calendar.  The key difference between these two approaches is the actual authority that gets vested in a calendar resource owner in the resource-based approach.  By utilizing resources, you gain the teeth of Assignment Policy which then enforces a denial since Publisher searches for the major calendars identified by Resources depending on the resource's actual assignment to the event, which can only happen if a member of the functional security group set as the approver approves the request.  In the end, both approaches work but if you want to ensure that the people vetting events for calendars do indeed have final say over what proceeds to published web calendars, using resources is currently the superior option.