Input Field Rules
Location in standard build: Administration > Security > Input Field Rules.
Users should always start the process of recording a contact with a search for the person in question (usually a Client). This is to make sure that the person in question is not already entered to the system (and remember that because the whole organisation is sharing a data pool, it is quite possible that the person in question has been entered by a different service within the organisation). If the person is already on the system, they can check the History tab, see if the referral is already started, and if so, carry on from there. If the person is not on the system, the user may use the "Create New" button to make a new client. This button is displayed in the top right hand corner of the search results and users often naturally think that this is the right button to use.
At this point, they are taken to a blank record for editing. In the case of a Client, the blank record looks like this.
As you can see, there are a lot of fields available (and there are actually twice as many as shown, because there is a Personal Details tab available too). Seeing this amount of data entry can easily put off an end user. Furthermore, the user has no way of knowing what the organisation's policy is on data capture - so some staff members may take down a lot of details, while others only record a name.
Input Field Rules solves this problem. You can set up a set of rules for a general, organisation-wide minimum data set. This will create a new button on a client search result, "Record a Contact for a New Client".
Rather than go to a full client record for editing, this will take a user to a screen with a data entry form which will be driven by the Standard Input Field Rules. So if the Standard Input Field Rules are set to require a (sur)name, forename(s) and a postcode, the data entry screen you will see will look like this:
This is much more palatable to an end user than a full, blank client record.
The system-wide (Standard) Input Field Rules are set up by clicking the "Input Field Rules" menu item, then the "Edit Rules" link:
This will take you to a screen where you can set any of the data to be stored with one of four options -
- No Rules
- Show on entry screen (but allow to be left empty)
- Warning if not filled in
- Must be filled in
Use "Warning if not filled in" with caution. Setting a field to this option will show the box in yellow on the data entry screen, and if the user tries to save details without entering any data in that box, they will be shown a popup warning for that box. If there are several boxes set as "Warning if not filled in", the user will be shown several warning popups, which can be quite cumbersome.
Contents
Turning off the "Create New" button
There is an option in Operational Rules that allows you to force users to always use the "Record Contact (for a New Client)" button, rather than the "Create New" button. This means that users will always have to enter the data specified by the Standard Input Field Rules.
Project-Specific Input Field Rules
Standard Input Field rules are effective, but they are not enough to deal with the varying data capture needs of a whole organisation. More often than not, the different projects within one organisation will have different requirements, for example -
- As well as standard data, the Information service needs to know clients' telephone number, email address, and preferred method of communication.
- As well as standard data, the Housing Support service needs to know clients' living arrangements, employment status and whether they have a disability.
...and so on. Incorporating all of these requirements into the Standard Input Field Rules would be tiresome, and would mean that each Project has to capture data for the sake of other Projects. This will lead to increased workload and pressure on staff, so must be avoided. Instead, you can use Project-Specific Input Field Rules to deal with these requirements. Click on the "Input Field Rules" menu item. At the bottom of the page are the Input Field Rules for each Project.
Click "Create Rules" next to the Project you want to set the Input Field Rules for. You will see a similar screen to that which is displayed for standard rules.
Shown above is the example scenario for the Information project, requiring "Preferred Method of Communication", "Main Telephone No." and "Email Address (Main)" to be filled in. These Input Field Rules are added to the standard rules, so you do not need to set "Surname", "Forename" and "Postcode" as required in the project specific rules - they will be carried over from the standard rules.
If you now use "Record a Contact for a New Client", and enter the required (Standard) details...
...and click "Save Details", you can then pick the Project to be used, in the usual way. In this case, "Information" is selected. The system then checks the Project specific Input Field Rules, and if there is data not yet stored on this client, you will be prompted for it.
In this way, each Project can require its own data set, without burdening all other Projects with its requirements.
Applying Standard Input Field Rules to the Client Record
There is another place that Input Field Rules appear - in Operational Rules. There is a field which lets you set your system to apply the standard Input Field Rules to the Client Details screen, meaning that when a user views details of a client who has been stored with less than the standard minimum data, they will be prompted to enter the missing data before being allowed to save the page. Use this with caution, as it can slow/frustrate data entry.
Input Field Rules for anonymous contacts
Recording anonymous contacts has a slightly different relationship to Input Field Rules - namely that recording of anonymous contacts will not function until you have set up some Input Field Rules to suit. To create some Input Field Rules, click the "Create Anon. Rules" link as shown:
Even if you don't enter a requirement for the "Name" field, it will appear on anonymous contacts anyway. Although it seems a bit silly to require a name from an anonymous contact, this field is important for two reasons:
- Recording an anonymous contact doesn't just "lose" the person; rather, it does create a client on the system, and that client is named "Anonymous Client". Over time, a lot of anonymous contacts will create a lot of clients with the same name. This isn't ideal, but it does mean that if a client who was previously anonymous comes back to have some work done with your organisation, you at least have some chance of finding the relevant anonymous contacts and merging the client records. Creating a new client each time also means that your reports for "how many client contacts have we had" will have the correct numbers in.
- This field, when used for Recording an Anonymous Contact, allows the end user to look up surnames on the system and check that the client is not, in fact, already on the system. This commonly happens when clients have involvement with one project more than others - they may not realise that everyone is using the same database.
