The essential information about the submitted question is included in a confirmation screen that displays immediately after submission (Question number, Question text, any attachments to the question, Received date and time, Target date and time if the forms design allows for it, and Answer if one has been provided in the form but not if the Response method is “No response required”).

The screen starts with an Alert bar that clearly indicates that the client’s request has been submitted, and that they can now close the screen o choose to use another function.

This screen can be printed using the browser print button as a printed confirmation, should the client wish to do that, but it is generally not necessary as most libraries will configure the Request form in use to also send a confirmation by email. 

If the client has provided an email address as their contact details, it will be shown in this screen with a note that, if necessary, the user can correct it by “clicking here” which takes them to the “Check on existing question” functions where they can use the “Make changes to this question” function to correct the email address.  Note that a popup about checking the email address is designed to ensure clients double check their email address (it only appears if Parameter 6.6 is set to Update).  Users can make the popup go away, by clicking anywhere else in the screen.

The Target date shown here is determined by a parameter set by your System administrator for questions submitted using this Request form. Note that your System administrator can remove the Target response date from this screen (and from the confirmation email to the client) if a Target date is not appropriate to this type of request (set using the Request form’s Edit options Other tab).

If a confirmation email has been sent to the client (this is optional according to the way that the Request form in use has been designed by your system administrator), an additional paragraph appears that advises the client to check that they are allowing emails from your RefTracker email address, and that they should check their junk email box if the confirmation email does not arrive.

The “Other options” section at the bottom of this screen, provides helpful links for those wanting to submit another question, or go back to your organisation’s web pages.
Make changes to this Question allows the client to make changes to their question or its attachments, via a screen that shows all the data submitted in the question, and a note field for any explanatory text.  This function might have been renamed to “Review this question” if your organisation does not allow clients to change questions after they have been submitted (Parameter 6.6).
Submit another question like this redisplays the same form that the client just used, ready for them to submit another question.  It will only include their client contact details if they have used “Remember me”.
Submit a different type of question appears if you have more than one form available for General client use, and takes the client to your Ask a new question list of available request forms.
Return to. . . . appears if your System administrator has a return to URL entered in parameters 1.5 and 6.

The text associated with this new “Other options” section can be amended using the Literals editor, but most customers will have no need to do that as the “We will contact you soon.” sentence is automatically excluded if the question just submitted has response method of “No response required”.

So at this point the system has:

• entered the question into the ongoing work database
• collected and saved in the Question details, information about the browser used by this client and their IP address, the device type being used (phone, tablet or computer) and the URL of the page from which the form was selected (if there was one), as this information is often helpful in resolving questions submitted
• allocated the question to a staff member according to systems administrator set parameters (allocation can be to anyone in the system, by the location from which the question came, or by the request type of the question; or allocation can be simply to a “Pool” that is monitored by staff for questions that they want to work on, or triaged by a staff member who manually allocates to the most appropriate librarian)
• sent the allocated staff member an email asking them to work on the question (if allocated to a librarian rather than being sent to the “Pool”)
• and sent the client (all email addresses in the client email, cc:All, cc:Conf/Ans, bcc:All, and bcc:Conf/Ans fields) an email confirming receipt of the question (if this was designed in the Request form used). If the confirmation email cannot be sent (for example, the email address was formatted well enough to pass RefTracker’s email address validation routine, but was not actually correct), a staff Alert will also be created to ensure that the fact that the email was not delivered is noticed and addressed if appropriate. The email address display in the confirmation screen shown to the client, together with the message in that screen that a confirmation email was sent, should alert the client to a problem and provide them with the tools to be able to correct their email address if it was wrong.

Submission of HTML in client Request forms

The Question field (which may have other names in other Request forms) allows HTML formatted text to be entered – so clients can cut and paste formatted information from web pages into this field and any formatting (such as dot points and hyperlinks) will be retained.

Security concerns in relation to allowing HTML in this field have been addressed by encoding all text received into that field so that any HTML received can never be executed. 

By default all systems now also allow HTML in ongoing correspondence screens such as answers to Query to client.  The client has been identified for ongoing correspondence so there is minimal risk of a hacker attacking these screens.  Importantly this means that the client interface can now be used to update questions received as imported HTML formatted emails.

Parameter 2.41 allows HTML to be entered in more or less fields according to your IT departments desired level of security.

If a client (or hacker) tries to submit HTML (or HTML like characters such as < and >) in a part of the form where it is not allowed, or in any client interface screen where it is not allowed they will be shown the following error message.

New Question Submission Confirmation function – Submit another like this

If, after submitting a request form, you want to submit a similar request, “Submit another question like this” and “Submit a different question” may be offered at the bottom of the confirmation screen.  Some browsers also allow the use of the back button to re-display the form with the values you previously submitted.