Lesson XVII: Astra Schedule Event Request Forms

Now that you understand the behind the scenes of the workflow, let’s talk through last bit of configuration needed before you can have your users request events: setting up event request forms! We’ll talk through your options to make the form as user friendly as possible, and then we’ll wrap it up with what happens once that form is submitted for both the requester and the approver. Let’s go!

Event Request Form Properties

To setup an event request form, navigate to Events and Event Request Forms in the Admin section. In a new Astra Schedule site, there will be two examples: Internal User Form and Guest User Form. You can create an event request form from scratch, or you can edit the existing forms. After editing them, you can clone the forms.

In the internal user form, you’ll see the options you have when creating a form. You will default to the Edit Properties page.

• Form Name: This is the name of your form for both the Event Request Form list page and the top of the form itself. This is the external facing name, so be aware of that!
• Form Description: This description can only be seen within the settings of the form. It is not public facing.
• Approver Group: Any approver groups that have been assigned to this form can be seen here. You can also assign an approver group to this form by clicking the plus sign in the header bar.
• Required Lead Time (days): Setting a required lead time is global for the entire form and will stop a user from submitting the request form before that time period. While the value is in days – 2 days, 7 days, etc. – it is also by the minute. If you select 2 days, the users will be able to submit an event 48 hours in advance, but not a minute before! You can set this value to zero.
• Max Days in the future for requests: The requests forms do a have a limit of 365 days, so you cannot go past that day range. Users will not be able to submit a request form with includes any meetings that are past the value you select here.
• Dates allowed for meeting requests: This is an optional field that users can setup to allow for meetings to be requested during a certain time frame. For example, if your Max Days in the future is set to 365 days, but you would like to limit your users to only requesting until a certain date, let’s say until the end of a term, you can setup a Start Date and End Date to limit the range of requests. This is a manual update process; therefore, your event administrator will need to update this date range when necessary.
• Introductory Text: The introductory text is the display text that will be at the top of the form when the user accesses. This is the best place to put any information the requester should know about before filling out the form. When editing this text, you have the option to add text, images, and links, very similar to the custom content widget on the homepage.
• Confirmation Text: The confirmation text is the display text that will populate after the user submits the form. This is a great place to put any contact information for questions or expectations on turn around time for the form submission. When editing the text, you will have the same options as the introductory text.
• Customer Filter Settings: If you choose, you can limit requesters to only submit the form with a customer and customer contact attached that are setup in the system. By checking “Use Customer Filtering,” only active customers and customer contacts will display in the customer and contact fields. Additionally, if you select the checkbox, the Customer options will become available, allowing you to select which customers the user can select.

• Event Type Filter Settings: If you allow a user to select the event type on the request form, you can limit which event types the user can select.
• Meeting Type Filter Settings: If you allow a user to select the event meeting type on the request form, you can limit which event meeting types the user can select.

Event Request Form Properties - Filters

Event Request Form - Edit Form

Event Request Email Examples

Emails are sent to the end user during the event request process. There are three trigger times for emails: when the event request is received, when the approver asks for additional information, and when the event is approved or declined. Remember – all elements of the event must be approved before the end user will receive their approval email. Below are examples of all 4 emails!

Event Request Received: This email will send when the user clicks “Submit” on the event request form. They will have a record of the information they filled out on the form, as well as the individual meeting, room, and resource information selected.

Request for Additional Information: This email will send when the approver clicks the "Request Info" button in the notification list, which is the blue icon. The email will include the high level event and meeting information. The question asked in the popup window when clicking the icon will be in bold above the Reservation Number.

Event Approved: This email will send when all elements of the form have been approved or filled out, meaning the event is in a Scheduled status. The end user will see all elements of the event in the email, and the email will reflect any changes the approver may have made.

Event Declined: This email will send if the event is declined. The user will see a reason at the top of the email, which will have to typed in manually by the approver. The high level information about the event – dates and times – will display.

You’ve made it through setting up an event request form and the workflow that occurs afterwards. Congratulations! Before we move on, an important tip for setting up event request forms and workflow is testing! Creating test users for requesting and approving is highly recommended in order to be able to see the process at work.

The last step in our Events course is understanding Equipment and Services, which we’ll get into in our next lesson.