This site requires JavaScript to be enabled

Changes to Indico events initiated in the Event Approval System

39 views

4.0 - Updated on 2022-08-30 by Marcia Teckenbrock

3.0 - Updated on 2022-08-29 by Marcia Teckenbrock

2.0 - Updated on 2022-08-29 by Aaron Zinsmeister

1.0 - Authored on 2022-08-29 by Aaron Zinsmeister

Changes to Indico events initiated in the Event Approval System



Intended for:

Indico event managers and organizers



Scenario/Use case:

Understand the changes to Indico events that occur when an Event initiates in the Event Approval System



Details:

            New events submitted through the Fermilab Event Approval System (EAS) will require changes to procedures to streamline the registrant experience. 


Changes from basic Indico behavior:

  1. Required form fields

            Event managers will notice that events with this integration applied now have a registration form (if they previously did not), a new section at the end of the registration form and new fields These fields do not show up in the form editor.

In addition, an extra form section, ”Attendance Requirements,” now appears in the form editor.  This contains the extra form fields not present in the editor (because they are not user configurable).  It is possible for a user to delete this section; however, the extra fields will then show up in the last defined section of the form. Data collection will still work, but the form will not look great.

            If a user has an event created for them or has the integration applied to an existing event with a form already defined, no action is necessary on their part.  However, they should be aware there may be duplicate fields, which are often defined on previous events used as templates. Many current events request some of the same information (e.g., citizenship, institution) which is now collected through a different process than the normal Indico form editor.

            Since there are a wide variety of input possibilities, , event managers who are creating events from old templates must remove unneeded fields from the new event the first time they clone the old event and then use the newly adjusted event as the new template. 

Note that cloning an event with the integration applied will not clone the alterations made by the integration.  The integration will be applied when the cloned event is submitted to either the Event Approval System or the ServiceNow task (whichever is required based on the creation options selected on the Event Request form.)


  1. Auto-created event categories

Events auto generated by the system will fall under two groups.  Those created for the EPE group will follow current category auto-generation methods and be created under the /EPE Events/<Program Name> category.  These events will use the visibility setting defined in the EPE program form (“Public”, “Public but unlisted”, “Private).

Unfortunately, there is no current system to map generic events in the Event Approval System to Indico Categories, so these new events will be created in the Indico Root category.  Once the correct category is known, the event can be moved to the appropriate location. 

The default permissions are Private, requiring management access to view or edit the event.  This can be changed when the event reaches its desired category.  This will likely be revisited in a future enhancement.


  1. External Registration Approvals

Events created automatically or submitted through the Event Approval System require all registrations to be approved through a process external to Indico.  Therefore, when a user first submits their registration, they will be put in a ”pending” state. 

The user or manager will be able to modify this registration until the external system has begun processing their registration fully, at which time the modification feature will be disabled.  If a user withdraws their registration, this process is terminated; if the user changes their mind, the approval process will have to begin anew.

Once the registration has been approved or rejected by the external system, it will communicate this with Indico, which will then unblock the registration process and allow it to continue normally.  This means that if a registration form does not use payment or moderation, the registration will be marked complete and will attempt to enroll in the event. If these features are enabled, the system will then proceed as normal for Indico, putting the registration into the “awaiting payment” for payment-enabled events or remaining in “pending” for manually moderated events. 


  1. Enhanced Registration Settings

            If an event was created by the Event Approval System,  a new settings menu will be visible under the registration form management screen.  Currently, the only new option available is “Waitlist Limit,” which allows for registrations beyond a certain number to be added to a waitlist. 


  1. Waitlist          

If an event has a limited attendance requirement, individuals can register for an event, even if it is full, and be “automatically” enrolled if they meet the preconditions (already paid or have been manually approved if these features are enabled.)  A user will be notified if they are attempting to enroll in an event that is already full and will receive email either if they are automatically enrolled or if a slot opens up in an event with the aforementioned preconditions (that they will then have to fulfill to be enrolled).

A setting of “0,” the default waitlist limit for new events, will disable this functionality.