Request form creation by filling out the online request form. In your request, please indicate:

1. Audience
2. Purpose
3. Timeline

Of course, more time is better; as a guide, plan to allow a week for gathering and clarifying parameters, one week for creation, and one week for testing.

For Subdomains with webform access, notify us at business.communications@uconn.edu or via the online request form that you are beginning to work on a new form. Please indicate:

1. Audience
2. Purpose
3. Timeline

Form Title
Set these with the idea that an Editor may insert these fields for public viewing.

Description
Set these with the idea that an Editor may insert these fields for public viewing. If your form requires instructions or details, best practices is to place that information on the page where you are placing the form.

Is there a cap on how many people can complete the form?
If yes, set the Limit number of entries. Also set the Entry Limit Reached message to let the user know why the form is no longer available.

Does the form have a start date or end date?
For example, if there is a deadline for submissions or an event date where you need to stop receiving registrations, you may want to set an end date. If yes, set Schedule form for start and end date/times.  Also set the Form Pending and Form Expired messages to let the user know why the form is no longer available.

Should a user only be able to submit the form based on a field value?
For example, if in the form you have a field asking if the user is a School of Business student or not, the submit button can be set to only show to users who reply Yes to this field via the button’s conditional logic.

Is the data you are collecting sensitive (e.g., SSN)?
If yes, then seek an alternative way to collect this data. Do not use the Aurora web forms to collect sensitive PII as it is not meant for secure information.

For each piece of data you are collecting, what is the best way to collect that information?
Explore single line text, drop downs (single- or multi-select), radio buttons (single select), checkboxes (multi-select), etc. It is recommended that you do not use text boxes for fields which you will be reporting on, as assigning values to choose from will be easier for sorting and creating reports.

What is required?
Require any piece of data that is essential, such as email address. Set the “Required” setting for each field as appropriate.

Should all fields be shown to all people?
For example, if you have an “Other” value, you may want to show a single line field for indicating the Other only to those who selected Other.  If field should be shown conditionally (e.g., based on a value previously selected), address the Advanced setting for Enabling Conditional Logic.

Is there a logical grouping of the types of data you are collecting?
If so, you may want to separate it into multiple sections, for example “Contact Information” vs. “Course Information.”  Conditional logic can be set for sections.

Is your form really long?
If so, you may want to separate it into multiple pages. It is recommended that each page be thematically grouped.  This will show a “Next” button and a progress bar at the top of the form. Conditional logic can be set for pages.

Confirmations

It is best practice to send a message to a user after they submit the form.

• By default this is a confirmation text. Please revise this message as appropriate to let the user know the form was submitted and possible next steps.
• You could also choose to redirect the user to a new page to thank them for submitting the form and providing more information.  You will first need to create this page; then a redirection to that page can be set.

User Notification (email)

It is best practice to send an email receipt to the user who submitted the form. This allows the user to have a record that they filled out the form and allows the form administrator to give more information to the user. More information could be the event date/time, next steps of a process, or who to contact for more information. The following fields should be addressed:

• Send to: In your form you should have collected the user’s email address. Select that field here.
• From Name: This should be the name of your office or the person of contact. Do not use the Office of Communications.
• From Email: This should be the email of the office or person of contact. Do not use the Admin Email or business.communications@uconn.edu.
• Reply to: This generally should be the same as the From Email.
• Subject: Set the subject line to something the user will understand. This is what will show up in their email. For example, the form title “Event Registration” may not work well in the email subject line, so you may want to change to something more descriptive like “Registration confirmation for ABC event”
• Message: Compose the email message being sent to the user. You can also include all fields that the user filled out, or insert field data, such as the user’s name.

Conditional logic is available. For example, if a user indicates that they are on a regional campus, the user notification email could be sent from that regional campus representative. If so, you may need to set user notification emails for each possible value of the field being used for conditional logic.

Administrator Notification (email)

You may want to have an email notified of each form submission. This is particularly useful if you would like to send one-off follow-up emails, or if you want to monitor the form submissions in real time. If so, the following fields should be addressed:

• Send to: Enter the email address of the office or person of contact. Do not use the Admin Email or  business.communications@uconn.edu.
• From Name: You could use a generic name, such as your office of person of contact, or include a value from your form, such as Name. If using a field, that field must be required. Do not use the Office of Communications.
• From Email: You could use a generic email address, such as your office of person of contact, or include a value from your form, such as Email Address. If using Email Address, this field must be required. Do not use the Admin Email or  business.communications@uconn.edu.
• Reply to: This generally should be the same as the From Email.
• Subject: Set the subject line to something the user will understand. This is what will show up in their email. For example, the form title “Event Registration” may not work well in the email subject line, so you may want to change to something more descriptive like “Registration confirmation for ABC event”
• Message: Compose the email message being sent to the user. You can also include all fields that the user filled out, or insert field data, such as the user’s name.

Conditional logic is available. For example, if a user indicates that they are on a regional campus, the administrative notification email could be sent to that regional campus representative.  If so, you may need to set administrative notification emails for each possible value of the field being used for conditional logic.

The Office of Communications can export an Excel spreadsheet of the form results on a weekly or monthly basis. This export will be of all fields and can be emailed to the form administrator.

Editors of subdomains with editor-level form access may export their data at any time.

Data collected on webforms should routinely be cleared out when the data is no longer needed.

Build

The Office of Communications will build webforms based on the identified parameters.

Editors of subdomains with form access may build part or all of their webform. The Office of Communications is able to offer assistance.

Testing and Review

• Webform must be tested before going live. Even if the Office of Communications builds the webform, the customer is required to test it themselves before go live to confirm it displays expected behavior.
• Forms should not be tested live. It is recommended that testing happen on a password-protected page.
• When testing, pay attention to the form fields and the notifications.

The Office of Communications is available to assist in this testing and review process.