6 – Client interface parameters

Client parameters affect the way in which your RefTracker client interface operates.

In addition to the parameters below, you also need to know about Parameters 0.15 and 0.16.  The client interface KB and FAQ pages will not display in the client interface unless these parameters are set to “Public”.

6.1 Prompt for location:  No longer in use

6.5 Other resources URL: If your library has a page of reference resources that you would like clients to have easy access to from the RefTracker client interface, entering the URL of that page in this parameter will result in an “Other Resources” link appearing in the client interface header bar, and on the client interface home page, and that link will open the URL that you specify in this parameter, in a separate window.

6.6 Requester access to existing requests: Options are None; No; and Yes (default);

Setting this parameter to “Yes” makes all of the “Check on existing question” functionality available to the client, so they can use it to look up their question and correspond with your service about it. Yes is the default setting for this parameter. When this parameter is yet to Yes, further control of what requesters can see in the client interface is provided by the “Requester manage request option” in each request form. Set “Requester manage request option” in each request form to “Update” (default) if they should be allowed to see the fields in that request form and be able to change them. Set it to “Review only” if you want requesters to be able to see the data that has been submitted in relation to their request but not change it, or “Summary only” if you only want Requesters to see the most basic of overviews of their request (also with no ability to change it).

By setting this parameter to “None” or “No” the “Check on existing question” links will all be removed from the client interface, and from emails sent to clients (as long as they are surrounded by RefTracker variable begin and end statements as per the standard templates). This will prevent clients from actively changing or updating submitted questions by removing all of the “Check existing question” client interface functions, but it will not stop them from responding to Query to client emails that you might send.  If they wish to respond to any other email sent from RefTracker they would need to use their email Reply function.  Also please note that the operation of this option is system wide – in other words, clients will not be able to change ANY question submitted on ANY form in your system.  It is rare that this option would be used.

6.7 Home URL: When blank this parameter results in the Home entry in the RefTracker client interface linking back to the RefTracker client interface Welcome screen (which will use your separate client web URL defined in parameter 6.8 if you have defined one). However, some libraries want the Home link to take clients back to a page that lists all of the different ways in which clients can submit questions to the library (not just by email). If you would prefer clients to be taken to this sort of a library defined page that shows the various ways to submit a question, enter the URL of the page that you want them to be taken to, in this parameter.
Enter with http:// or https:// as appropriate, or if the URL is entered without either of these it will use http or https as being used by your RefTracker system.   

6.8 Client website public URL: When this parameter is “none” (default) the web under which RefTracker is installed is the web used for all client access links. “None” is the default value for this parameter and the one that will be used by most customers. Only in-house customers will set this parameter to other values, and ONLY when they have set their RefTracker system up behind a firewall for security reasons, and have a separate client web running on a machine outside the firewall that points to the system behind the firewall. For this reason, you need to contact your RefTracker support representative for a Support password to be able to change this parameter. Further information about how your IT department would set up such a client web is provided in the Support manual.

Without this parameter links, in RefTracker emails would utilise the staff web which would result in clients being unable to access that functionality in this particular scenario where RefTracker is installed behind the firewall.

When a base URL (e.g. http://xyz.libraryresearch.info/ or http://askalibrarian.xyz.com/ ) is entered in this parameter, that URL will be used as the base URL for all links used by client interface pages, and by links to RefTracker in emails to clients. The link to the client interface in the staff home page will also use this base URL (if no other client home page is defined by parameter 6.7), and the URL for forms, that is provided by the Preview mode of the Request forms design screen, will also correctly present the URL for clients to use, utilising this client web URL.

This parameter goes with parameter 1.7 that provides similar functionality for the staff interface.

6.9 Contact details cookie: This parameter allows you to control whether the “Remember me” function will be provided for your client interface form users that have cookies enabled. The Remember me function stores the client contact details provided by a client in the RefTracker forms provided by your system, in a persistent RefTracker cookie, and automatically displays them in any future forms that the same user (using the same browser on the computer where the cookie was saved) might use in your RefTracker system. RefTracker automatically detects whether cookies are allowed by the client’s browser and only offers the functionality that can be supported by that configuration.  Persistent cookie based functionality like this is only prevented from use if the browser has been set to reject all cookie activity.

Options for this parameter are:

• Disabled – the remember me option will not be offered to any users of your client interface Request forms and their contact details will not be saved in the encrypted cookie. (default) 
• Automatic – The first time a client uses one of your forms, their contact details will be stored in the encrypted cookie on that client’s computer, for all clients whose systems allow cookies to be stored. This is a good option for Special libraries/corporations that do not have clients using public computers. 
• Prompt – When a user’s computer allows use of cookies, a “Remember me on this computer” tick box will appear at the end of the form. Their contact details will be saved to the cookie, or updated if the cookie already exists, ONLY if they tick that box. The “Remember me” tick box will appear on all forms they use so they can change their mind at any time. This is the option you should use if you have any clients that are likely to use public computers.  If you offer public computers within your organisation we would recommend that, if you choose Prompt here, you also ensure that the browsers on your public computers are set to “Keep cookie data only until I quit my browser” so that if a user ignores the warnings, the cookie is automatically removed as soon as the browser is closed.

Many customers serving staff of their own organisation will want to implement this feature, by setting this parameter to Optional or Automatic, as it makes your RefTracker forms easier for clients to fill out. many customers serving the general public will want to choose “Prompt”.

When you design request forms for use with the “Remember me” function, any client contact fields that have been defined as hidden will retain their default values. Only fields defined as Optional or Mandatory can be filled from the cookie. Having fields filled by the cookie as visible fields ensures that the client has the opportunity to change any of this automatically inserted information. Ideally, your forms should also all ask for the same contact information, as the cookie will be re-written each time a form is used, and so will always contain the latest set of client contact information provided by the client in the last form that they used.

If Single Sign On (SSO) is in use for the client interface, this cookie will be checked if the Single Sign on lookup is unsuccessful.

When a form that contains RefTracker Dynamic Lookups is displayed by a client with a stored RefTracker cookie, the contact information in the cookie will be filled into the form on display, but any lookups associated with the fields that the data is automatically inserted into, will not be performed. The cookie information would need to be inserted using a pre-population lookup to trigger any associated Dynamic lookup, on display of the form. Ask your RefTracker support representative for assistance if you need to use the cookie with your Dynamic lookups.

The Remember me cookie function saves the information that clients provide about themselves (data that would be stored in the RefTracker client table only) and displays that information in future Request forms that they use. If you want any of the following, you will need to purchase the more richly featured RefTracker Dynamic Lookups Module (your Altarama sales representative can provide more information about the Dynamic Lookups Module):

• if your clients cannot use cookies, or you do not want your clients to have to enter their contact details on the first time that they complete a form using a computer that they have not used before (one that does not already have a cookie saved for them), such as if they use public computers to submit requests;
• if you want your staff to be able to retrieve client contact information when they enter a request on behalf of the client;
• if the client contact information that is automatically inserted in a form is to be as defined for that client in a separate computer system (like your Human resources system or library management system);
• if you want the client contact information hidden in the form;
• if you want to automatically insert information into a form that will not be stored in the RefTracker client table;
• or if you want contact information automatically brought in about the client when emails are imported.

6.11 Allow client ‘Send me an existing questions email’ option: This parameter controls whether the “Send me an existing questions email” option will be offered in the “Check on existing question” screen.  When set to Yes, the “Check on existing question” screen will offer a “Send me a list of my existing questions” option that, when clicked, will send an email listing all that user’s previously submitted questions (for their email address for the period defined by Parameter 6.10). 
Set this parameter 6.30 to No if you do not want clients to be able to see a list of questions they have previously asked.

Parameters 6.12 and 6.13 work in unison to control your contact data retention and deletion policies. For full details about implementing contact data retention and deletion see the Contact data retention and deletion help page.

6.12 Requester data retention model: Your contact data retention policies are set using this parameter 6.12, where the possible values are Presumed, Requester discretion and Requester specified.  Parameter 6.12 works in association with the ”Remove client details after close” field that can be optionally included in Request forms.
Make your selection at Parameter 6.12 based on the following information.
Presumed:  This option presumes that the client/requester does not have to give permission to retain their data – such as where only in-house requesters are being serviced by a corporate library.
This option means that Requester data is never to be deleted (except that you can still choose to use the Delete requester data background process to have it deleted in bulk, for all closed requests, after a specific period has elapsed from when the request was closed). 
The requester does NOT have an option in the requester interface to ask for their requester contact details to be removed, as that “Delete my details from this request. . .” option is removed from the client interface by this parameter choice.
The value for “Remove client details after close” will be set to “No”.  However, it is possible to include the “Remove client details after close” field in your Request form/s, so that the end user has an opportunity to specify that their contact details should be removed, but this would be highly unusual.
Requester discretion:  When you choose this option, permission to retain the Contact data is implied by the requester completing the form.  You can have them specifically confirm this via a general conditions agreement in the form (you might like to use the Privacy acceptance Request form field to do that). 
When you choose this option the Client interface will provide an option that allows the requester to select deletion of their requester contact details.  This functionality is the same as was previously provided by parameter 6.12, and if you had it selected previously, this upgrade will have set this option for you. 
The value for “Remove client details after close” will be set to “No”.  However, it is possible to include the “Remove client details after close” field in your Request form/s, so that the end user has an opportunity to specify that their contact details should be removed.  Using the “Retain request data” field in your form/s is still optional, but more likely when using this option, so that users can choose, as they enter their request, how their Contact details should be handled.
Requester specified: If you choose this option, Requester contact details will be deleted by the next run of the “Erase client data” background process, parameter 6.13 days after the request is closed, if the requester has not given their permission to have their data kept via the “Remove client details after close” field. 
The ”Remove client details after close” field must be included in all your request forms.
This option makes it obvious to the requester that they control what happens to their data.  The value for “Remove client details after close” will be set according to the requester’s choice for it in the Request form they completed – “Retain for future” or “Remove on close” (where “On close” means parameter 6.13 days after close of the request).
The ”Erase client data” background process that runs automatically will remove the client contact details from all records that are set for deletion according to your setting of parameter 6.12 and 6.13 and the clients choice at “Remove client details after close” if that is in use for the request. 

6.13 Erase requester data after: This is where you set how long after a request is closed, before it should be marked for requester data removal, if the requester data is not to be retained for this request (which means that this parameter is only applicable, and you only have to set it, if you set parameter 6.12 to “Requester specified”).  Default is 60 days but you can choose however long you think is appropriate in your organisation to provide a balance between removing the data promptly, and retaining it so the request can be reopened if the requester wants to do that.
The ”Erase requester data” background process that runs automatically will remove the client contact details from all records that are set for deletion according to your setting of parameter 6.12 and 6.13 and the clients choice at “Remove client details after close” if that is in use for the request. 
If client contact data is removed in this way, it is no longer available for use by the Contact lookups function so be sure to consider this when you set this parameter (select a longer period before deletion if you want the data to be available for Contacts lookups). Similarly, removing contact details means that the request will no longer show in the client interface “My requests” function, so this parameter should be set to at least as long as parameter 6.30 if you use the My requests function.

Parameters 6.15 and 6.16 work in unison and control the end user availability of the RefTracker SubjectGuide functionality that allows you to create and maintain informational web pages using a simple to WP style editor, and without any assistance from your IT department. Click here for information about using SubjectGuides to make information available to your staff and/or clients in pages that automatically maintain a two level table of contents.  Click here for information about implementing or modifying your SubjectGuides (free for full RefTracker customers and available at a small additional price for Express customers).  Please note that the SubjectGuides Capability provided in RefTracker is NOT indexed by search engines and so is best used for internal documentation.  Parameter 6.16 allows you to link whatever Subject guide or Informational pages that you already have accessible in your web pages, into the RefTracker client interface.

6.15 Display SubjectGuides link: This parameter determines whether or not the “Subject Guide” link displays in the header bar of your RefTracker client interface.

Yes = “Subject Guides” link appears in the Client interface header bar

No -= “Subject Guides” link does NOT appear in the client interface header bar.

Note that even with this parameter set to No, you can still make the SubjectGuides that you maintain in RefTracker, available to your client base.  Just insert the individual SubjectGuides page URL’s, or insert http://<YourRefTrackerDomain>/refs000.aspx to make the full set of RefTracker maintained SubjectGuides available anywhere in your web pages.  

6.16 SubjectGuides location: This parameter determines the URL that the “Subject Guides” client interface header bar link will go to. 
The default entry is http://<YourRefTrackerDomain>/refs000.aspx, and this link points to the SubjectGuides pages that you can maintain within RefTracker.
However, if you maintain SubjectGuides elsewhere, and you want to link them into the “Subject Guides” link in the RefTracker client interface, enter the URL of your already existing SubjectGuides into parameter 6.16.

6.20 Allow client to view correspondence: This parameter allows your organization to remove the “I want to view the correspondence history” link from the Client interface Check on existing question function.  The link highlighted in yellow below (that appears for both open and closed questions) will be removed for all types of questions handled by your system.

The “I want to view the correspondence history” option will ONLY show the things that have been sent to the client, so there are no issues with this function providing anything that the client should not see, but some customers feel that it presents a “big brother is watching image” that they would prefer not to portray.

6.30 Period for which client can view previous questions: Select the period for which you would like clients to be able to see questions they have previously submitted in the “View all my questions” screen (if parameter 6.11 allows use of this feature).  Clients will be able to see all questions submitted for the period specified here so that means they will be able to see both open and closed questions submitted in that period.

If your organisation is subject to privacy considerations the period you allow here might be as short as three months.  But other organisations such as corporate libraries you may be comfortable with their clients knowing that their questions and answers are kept for 7 years or more.  The default period is 1 year, so please be sure to set this value to meet your requirements.

Clients will only be able to see questions that have their email address in the Client email address field.  If they see a question in the “View all my questions” screen that they no longer want to be associated with them they will be able to delete their client contacts details using the “Delete my details” option that appears in the “Manage this question” screen for closed questions (if parameter 6.12 is set to Yes).
Staff can delete client contact details on the client’s behalf by using the Client options link in the Details tab for that question (it brings up the “Manage this question” screen).
Further, client contact details can be automatically deleted by the Erase client data background process accessible at System>Batch process menu>Background processing>Erase client data.  For this reason the period you specify here should be no longer than the period specified for the Erase client data background process, if you are using it.

If you DO NOT want clients to be able to “View all my questions”, set this parameter to zero.  When this parameter 6.10 is set to zero the “View all my questions” link will not appear anywhere in the client interface.  Because the “View all my questions” function is not available, this means that the “Send me an existing questions email” option in the “Check on existing question” screen cannot be provided (which means that Parameter 6.11 will act as if it is set to No). 

6.31 Show allocated staff in search results: Select “No” (default) if you do not want clients to see what staff member is allocated their request, when using the “View all my requests” screen in the client interface.
Select “Yes” to add the “Allocated staff” column to the “View all my requests” screen in the client interface. You will want to do this if you want clients to know who to contact about their request.

Exercise:

Consider the effect of these parameters on your library’s requirements. Make any desirable changes, and if you make any, click on Save. Then in Select parameter group choose 7 – Answering customisation.