- 11 Minutes to read
- 11 Minutes to read
MainEvent offers you the chance to bring the outside in with Public Requests. Include a request site within your already existing web presence or create a public facing request page all on its own. Let the public or agency users without MainEvent access request when and where they want to see events with Public Requests.
To begin setting up a Public Request site, ask your Account Manager to configure your site to allow for Public Requests. Once the site has been configured, you'll need to head to the Client Admin section to begin setting things up. Click Admin in the navigation menu and select View.
This will bring you to the Global Admin page. In the Global Configuration Menu click Clients under the Global header.
Now you're looking at the Clients section of the Global Admin. Find the correct client (the one that you want to build the request page for) and click Edit.
This will navigate you to the Client Admin page for the client you selected. Under the Events heading in the Configuration Menu select Public Requests.
This will open a new page called Public Event Requests. This index page will list all previously created Public Request pages on the client. To add a new Public Event Request page click Add New Public Link.
You'll now be looking at the Edit Public Event Request Link Details page. This is where the real magic happens. The first section is the Public Request Page Details. This is where you'll begin to build out your public facing request page. First thing needed is the link prefix. You might want to call this 'clientnamerequest' for example. The domain will automatically be set as requestevent.com. The field will automatically run authentication to confirm that the prefix is available for use.
The next field is Public Site Page Title. As you may have guessed, this is where you're going to put the title of the site.
Then you get to select the logo you want to display. Click Choose File and follow your device's file selection process.
Now you'll move to the Event Request Page Instructions which is a text field. This section will display as a subheader below the title of the page.
Select the active status for your request page. Want people to be able to request events right away? Set the active status to Yes. Need to hold off and wait a little? Set the status to No.
If you want to, you can also set up Authentication. You may require requesters to have a password to access the site, or have an email from a specific domain. You can choose to use either of these options or both (or neither, but then just skip this section completely).
Password: Set a password that requesters will be required to input prior to accessing the request site. Passwords are case sensitive.
Selecting email domains for authentication purposes lets you input a comma-separated list of accepted email address domains (ie. client.com; clientsubsidiary.com). Users without email addresses using those domains will not be able to access the site.
The next two fields are optional, Custom Domain and Custom Domain Path. A custom domain would be the web address that your users would input in their browser to navigate to your request site. It could be anything (provided the domain is available of course) but an example might be clienteventrequest.com. Tfdhis allows for easy streamlined access to your request site.
The Custom Domain Path allows you append a segment onto an existing domain at the end of the address. This does not mean you are able to embed your request site in a different site, this path only applies to the domain of the request site. ie. clienteventrequest.com/request
The next field is a Yes/No select to determine if you want to allow event details of confirmed events to display in the public requests calendar. If you choose to enable this, users on the request site will be able to see the date, time, and location of confirmed events. If you do not wish for users to be able to view this information on the request site, you will need to select No for this field.
The next field is again a Yes/No select, this time to determine if you want to show fields that are already answered for the requester. If there is only one option (ie. there’s only one program from which to request events) the system will automatically select that option and will hide the field. If you would like those auto-selected fields to display instead (still uneditable), select No. This field will default to Yes.
Now we're ready to get into the information you want to collect from the requester. The next section on the page is Fields to Display. The first four of these fields are: Requester First Name, Requester Last Name, Requester Email, Requester Phone. These are all simple Yes/No select fields to start with.
Want their full name but not too fussed about their phone number? Select Yes for First and Last Name and No for Phone.
When you select Yes on any of these fields, a secondary Yes/No select field will display to determine if the field is required to submit the request. If you select Yes for this Required field, users will need to include information in these fields in order to submit their requests. The default for the Required fields is Yes. An optional Help Text field will also display. If you wish to input any instructions related to a particular field, you can enter them here.
The next field is Requester Can Pick Event Name. This field will determine if the requester is allowed to name their own event or if you want the system to automatically name the event according the the following format: ProgramName#EventID (ie. ClientSampling#123456).
Moving on you'll need to decide if you want the user to be able to enter an event description. This field will allow the user to enter any details that aren't covered in the standard fields. The Event Description field is an optional field even when you opt in to using it.
Next is the Event Category. If you're receiving requests for a variety of event categories (On-Premise, Off-Premise, Ad-Hoc etc.) you may wish to let the requester make that choice. If you select Yes, users will see a dropdown select (if there is more than one option) or a pre-populated field (if there's only one). If you chose to opt out of allowing requesters to select the category, you'll see a dropdown from which you must select the category for all event requests.
The same parameters will apply to Requester Can Pick Event Program. Select Yes to allow users to choose their own Program from a dropdown select field. Select No if you want to choose the Program for all requested events yourself.
Then we have Requester Can Pick Event Status. Select Yes to allow requesters to choose what status their requested event is created under within the system. Select No if you want to determine the event status for all received requests yourself. If you select No, a dropdown select field will display for you to choose the correct event status for all requested events.
Now we've got to determine if users can select their own Event Type for their requested event or if you want to determine that for yourself. Requester Can Pick Event Type will allow users to assign any active event type to their requested event if you select Yes. If you wish to make the decision on what Event Type is assigned to all requested events, select No and choose the event type from the dropdown list that will display.
Next up we have to decide if the requester is able to select what recap definition to assign to their requested event. To allow the requester to choose from all active recaps on the program assigned to the request, select Yes. If you prefer to assign the recap to all requested events, select No and then chose the recap of your choice from the dropdown that will display.
The Venue field is a non-negotiable required field. The system requires that all events, even event requests, have a location attached to them. The only thing you need to do here is decide if you want to include any Optional Help Text.
The next field is more complicated and will require a bit more thought. We're talking Markets. For Markets you've got options, so we're going to lay them out and discuss the implications of each.
Option 1: Single State for all Requests
This will allow you to assign one Market to apply to every request coming in. So, you choose Market X from the dropdown, that would mean that for every request you receive, the location and event will be placed within Market X regardless of geography.
Option 2: Automatic Market Assignment by State
This option lets you choose which market you want the event to fall within by state. Choosing this option will display each state in alphabetical order with a dropdown select field below. This dropdown will contain each market for the client. Choose which market applies to each state and that market will automatically be assigned.
Now, you might be thinking 'but my markets are just the states and I don't want to have to select each market for each state', and we wouldn't blame you. But not to worry, we've got you covered there. If your markets correspond with the states, just click the Match Markets to Matching State Names button. Now all event requests with an Alabama address will be assigned to the Alabama market with you only having to click a single button.
Back to simpler decisions, now you need to decide if the requester can pick the venue type on the location for their requested event. If you select Yes, the requester will be given the met with a dropdown listing all active Location Types on the Program their requested event falls within. Select No if you want to choose for them. A single-select field will now be visible for you to choose which active venue type you want to have all requested event locations nested within.
After all that, we've reached the last field. If your program has tours (assets), you can decide if the user can select which Tour they want to assign to their requested event. Select Yes if you want the user to be permitted to select from any tour with an open asset activity for the day they are requesting. Tours without open days will not be able to be booked. Select No if you want to select the Tour for all requested events. Choose the tour from the dropdown select field and it will be automatically assigned to requested events if there's an open day activity.
One final item of note. At the bottom of the page, there is a section called Custom Field Rules JSON. If you wish to use a JSON file in your Public Request page, please contact your Account Manager.
Once you have made all the selections, click Save to create your request page.
The field restrictions that you implemented when setting up the site will also be clear when a requester attempts to submit an incomplete form.
Public Request Landing Page
So, we've created a request page, but what if you're running multiple programs and they each have a request site? You might want a landing page that would allow for users to see their options and make a selection from there. We've got you covered.
To begin, click Admin in the navigation menu and select View.
This will bring you to the Global Admin page. In the Configuration Menu on the left side of the page, click Public Request Landing Pages under the Events header.
You'll be redirected to the Public Event Request Landing Pages Index. This page will operate in the same way as all your other MainEvent index pages, listing out previously created Public Event Request Landing Pages, allowing for quick search, filtering, column reordering, etc.
To begin creating a new Public Event Request Landing Page, click the Add New Public Landing Page button.
Now you'll be on the Edit Public Landing Page Details page. This is where you'll build out the specifics for your global request landing page. The first field you'll need to enter is the Event Request Link URL Prefix. For example, you might go with "clientsampling" with the domain automatically set at .requestevent.com. You want a prefix that applies universally across the clients and programs you will be selecting to host on this landing page.
Next, you need to come up with a title for your landing page. You might name this after the client running multiple programs that are all allowing requests, you might name this after the agency using this landing page as a stepping stone for their various requestable event programs. The world is your oyster here.
Then you choose the logo you want to display. Again, this will be the logo for the global landing page, not any specific request site so you'll want a logo that applies across all the request sites that you will be linking to this landing page. For example, you may wish to use the agency logo, while the request sites each display the client logo or the program logo. Click Choose File then follow your device's prompts to select the file.
After that we move on to the Event Request Page Instructions. This section will display as a subheader below the title of the page.
Select the Active Status. If you want users to be able to use the Landing Page right now, select Yes. If you need to hold off and wait a bit, select No.
The next field is the Optional Custom Domain, and as it says right there in the title, it's optional. If you have a custom domain that you wish to use for your Request Landing Page, you would add that here. If not, we'll just use what we already entered up at the top.
And last but not least, you get to decide which of your existing Public Request Pages you want to link to your landing page. This list will include all active request pages across the site. Use the checkboxes to select which sites you wish to include.
Once you've made your selections, click Save. Now go and take a gander at your new Request Landing Page.