Event requests
- Andrew Gates
The following guide is adapted from ASIMUT Support’s article on event requests.
Some article content has been removed from this guide.
For the full article content see the original article linked to below.
In this guide you will learn:
STATUS: As at October 2024. event request functionality is available in its first version in ASIMUT v3.4, a so-called release candidate, and is being tested by select schools.
Use cases / What to use it for
The event request functionality has been developed to handle specific scenarios that are an exception to the self-service bookings made by, for example, students to book practice spaces.
We highly encourage you to allow Common Users to make their regular bookings themselves by self-service enabled by the comprehensive booking rules enforced in the Common Interface. You always have full control of bookings and spaces and can always reschedule or remove any booking from the Advanced Interface. This approach inverts the workload for you in the administration, so you only have to manage the exceptions instead of every single booking, which saves you a lot of time.
The event request functionality, on the other hand, will allow administrators to maintain control over special case situations, because Common Users must file a request, which Advanced Users can approve or reject.
We therefore recommend thinking carefully about which scenarios you want to use it for, and if it instead can be handled with a good set of booking rules.
Some examples where event requests could be relevant are: high demand spaces (e.g. performance/exhibition spaces); events that require more organization and planning (recitals, performances, recordings, exhibitions, etc.); or events where users must fulfil certain requirements.
If you’re in doubt whether to handle a scenario via booking rules or via event requests, we are happy to discuss it with you to find the best solution taking all aspects into account.
How does the functionality work
Event requests enable a workflow where Common Users are assigned a category for event requests, and any events they create in this category show as pending requests until an administrator approves or rejects them.
Event request category
Event requests are first of all configured to a specific category in ASIMUT. You can allow (some of) Common Users to have more than one category option when booking, so by assigning them the event request category, along with their other booking category/-ies, you enable them to create event requests.
From version 3.4, you can now also limit in which categories Common Users can book a location, which enables you to restrict a location to for example only be booked as an event request and not in a normal category. You can read more about this in the "What's new in version 3.4" article.
Common User: Make event requests
Common Users can create an event request like any other booking, but using the category configured for this purpose:
Like in this case above, the common user can use the category to Request a recital in the Recital Hall location, but cannot book a normal practice.
When Common Users are in the process of creating an event request, they will see an informative message, where you can inform them about the terms on which they can make the request and what they need to know before saving it.
The request cannot be edited by the Common User once it’s been submitted and it will not show in the user’s agenda, nor will it show in the agenda of the location. A new menu item will instead display an agenda of all event requests made by the Common User. This menu item appears only if there are event requests made by the user:
Common Users will be able to follow the status of each request thanks to the label on the top right of each request, which in this screenshot says “Pending”.
Advanced User: Managing event requests
Event requests are managed in the Advanced Interface. Event requests are bookings that don’t appear in the main workspace - all event requests end up in a draft workspace dedicated to the event requests, in this example a workspace called "Recital requests".
The request workspace is an independent scheduling area that allows you to draft the events and do the puzzling before publishing them to the main workspace – with or without clash checking against the main workspace. You can read more about workspaces in the article "Workspaces". We recommend you to read it if you are not that familiar with workspaces in ASIMUT, as it is essential for using the event request functionality.
We recommend having two workspaces: one for all event requests, and one for the event requests you reject.
The Advanced Users that you allow to work with the event request workspaces can use the visual charts and the textual agendas to gain an overview of the pending requests. “Global agenda” provides a complete list of all pending requests.
Approving or rejecting event requests
Approving event requests is like publishing events from any other draft workspace, i.e. moving the event(s) to the main workspace, for which you can use the “Publish events” feature.
Event requests can also be processed individually, which gives you more options. Click on an event request from one of the overviews, so you get to the edit event interface. In the dropdown menu “Workspaces” you will find two options: Publishing to main workspace (this action is irreversible) or rejecting the request.
By ticking the checkbox “Process related events when approving” you will be presented with a second step to manage related event requests: These are divided in two sections:
Event requests in the same location that would clash with the one you are about to approve.
Other event requests made by the same user. By setting a date range you get an overview of this users’ other event requests, so you can determine if and how many of the users’ requests you might consider approving or rejecting.
From this popup you can simply select the checkboxes next to the event requests you would like to reject when approving the event you wanted to approve to begin with.
Approving a requested event will have four effects:
The event will be published to the main workspace.
The category of the event will change to the category configured for approved requests.
The label of the event in the Common Interface will change from “Pending” to “Approved”.
The event will appear in the requester’s agenda and in the location’s agenda like all other events in the main workspace.
Rejected requests
When rejecting an event request, the event will move to the workspace for rejected event requests, which clears up the workspace for pending event requests.
With the workspace for rejected event requests you have full control and can still change your mind by either moving the rejected event request into the workspace for pending event requests or approving the event request by publishing it directly to the main workspace.
In the Common Interface only the requesting user will be able to see the rejected event request. It will appear greyed out and with the label “Rejected”:
Changes to event requests before approving
As always, the Advanced Interface gives you full control of all events and you can therefore also modify the event request before approving or rejecting it.
In the meantime, the requester will only see the original details of the event request. In other words, the Advanced User can reschedule the event request as much as needed to solve the puzzle of events before approving and without any Common Users seeing the steps in between.
If a modified event request is approved and published to the main workspace, the user will see the event with the changes and a label saying “Approved with changes”:
Information ASIMUT Support need to configure event requests for you
Required configuration:
Two categories: Request category and approved category
The approved category can be an existing category you already use for e.g. “Recital”
If so, please let us know which category to use.
If not, please create the category and let us know the name of it.
The request category is usually a new category and needs to be configured for use in the Common Interface like other bookable categories, so please create it and let us know:
What did you name the new category you created? E.g. “Recital request”
Arrangement name: What should the name of the event be? E.g. “Recital”
Menu label: What should the label be in the menu that appears, when a Common User is asked which type of event they want to create? E.g. “Request a recital”
Should it use quotas?
Should it use horizons?
Free horizon? If yes, how long?
Primary role: In what role should the requester be participating? E.g. “Performer”
Should the requester be able to add additional participants? If yes, in which role(s) and for each role should there be any minimum/maximum requirements?
Are the event requests allowed to conflict with existing events in the main workspace?
What should the menu item in the Common Interface be, e.g. “My recital requests”
If you would like the menu item to match the Common User’s language setting, please provide additional language version(s) and an English “fallback” version for the menu item.
What should the names of the workspaces be, and which Advanced Users should have access to them? E.g. “Recital requests” and “Rejected recital requests”.
Optional configuration:
Should a message appear to the Common User while creating the event request?
If yes, please let us know the message, e.g. “This is a request for a recital, which will be pending approval from the administration”.
If you would like the message to match the Common User’s language setting, please provide additional language versions and an English “fallback” version of the message.
The labels for the status of each request will normally be the following, but you may customize them to labels of similar length:
“Pending”
“Approved”
“Approved with changes”
“Rejected”
“Cancelled”
If you would like the labels to match the Common User’s language setting, please provide additional language version(s) and an English “fallback” version for each label.
Deadline for event requests
It is also possible to require Common Users to make their requests prior to a deadline, after which you will process the requests by approving/rejecting them.
Common Users may both create and modify their requests until the deadline. After the deadline all requests are locked in and can only be modified by Advanced Users. The deadline does not affect the horizon in which the requested events may take place – the normal booking rules with booking horizons for persons and/or locations apply.
For this more advanced configuration, please contact the ASIMUT support to discuss the best possible solution in your context.
Original article
The original version of this article can be found here