Difference between revisions of "Input Field Rules"
| Line 96: | Line 96: | ||
In the screenshot below, the "Alternate Field Name" feature has been used to clarify that the "Name" field in fact means "Surname" in the case of Clients/Dependants, and the "Forename(s)" field has been given the label of "First name(s)". | In the screenshot below, the "Alternate Field Name" feature has been used to clarify that the "Name" field in fact means "Surname" in the case of Clients/Dependants, and the "Forename(s)" field has been given the label of "First name(s)". | ||
| − | [[File: | + | [[File:IFR_4.png|border]] |
Revision as of 15:54, 8 April 2015
Location in standard build: Administration > Security > Input Field Rules.
Input Field Rules provide a way for administrators to control the minimum data that must be entered for a user to create an organisation/person on the system.
Contents
Why Input Field Rules are required
Users should always start the process of recording a contact with a search for the person in question (often a Client). This is to make sure that the person in question is not already on the system. If the person is already on the system, they can check that person's History tab, see if a relevant 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.
Using the Input Field Rules feature 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.
Setting up Input Field Rules
All rules can be viewed by clicking the "Input Field Rules" menu item.
General Settings
At the top of the Input Field Rules page are two settings, as shown:
- Apply "Standard Rules" when saving a client record? - if "Yes" is selected, then the system will check the existing data against the Input Field Rules for the system every time a user clicks the "Save Details" button or the "Save and Close" button at the bottom of the Client Details screen. This means that checks for completeness of data are constantly being carried out, so users cannot blank out a required field and then save the record with the data now missing. If set to "Yes", the relevant fields will be coloured red or yellow on the Client Details screen, just as they are on the initial data entry screen when the user clicks the "Record a Contact (for a New Client)" button. However, bear in mind that this setting applies to historical records as well as new ones, so it can prevent users making changes to records that have been added as part of a data migration from another system, and/or records that were created before Input Field Rules were properly set up.
- Apply "Standard Rules" when making a new referral for an existing client? - if "Yes" is selected here, a check will also be made against existing data when a referral is started for an existing client, and the user will be warned if the standard minimum data is not stored on that client's Details screen. The user will not be allowed to continue with recording their Action until they have filled in the relevant data. As with the above option, this can cause trouble for users on systems where there are historic clients without full data, perhaps from data migration or from before Input Field Rules were set up. This setting is irrelevant for referrals to any Project where there are Project-specific Input Field Rules (see below).
Setting/Editing standard Input Field Rules (system-wide)
From the Input Field Rules page, click the "Edit Rules" link on the "Standard" line. (If this is the first time Input Field Rules have been set, the link will say "Create Rules" rather than "Edit Rules".)
This will take you to a screen where you can set any field 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.
Alternate field names
There is another important feature on the Standard Input Field Rules page - alternate field names. Changing a name will make that field display with the alternate name in the following places:
- The initial data entry screen, seen after clicking the "Record a Contact (for a New Client)" button
- The Client Details Screen
- The Dependant Details screen (if you have the carer version)
At present, this feature does not change the field names on the other org/person Types, just Clients and Dependants, but this will be changed in a future release so that all Type records behave the same way.
In the screenshot below, the "Alternate Field Name" feature has been used to clarify that the "Name" field in fact means "Surname" in the case of Clients/Dependants, and the "Forename(s)" field has been given the label of "First name(s)".
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
Sometimes, 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. At the bottom of the Input Field Rules 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. Input Field Rules are always applied cumulatively, i.e. these project-specific Input Field Rules are added to the standard rules, so you do not need to set "Surname", "Forename" and "Postcode" again if they're already set in the standard rules.
If you now use "Record a Contact for a New Client", and pick a Project, all the relevant Input Field Rules (standard and project specific) will be added together to make a data entry screen which shows all the required fields.
In this way, each Project can require its own data set, without burdening all other Projects with its requirements.
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 strange to require a name to be stored for 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" (unless given another name). Over time, recording 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.
Rob Kay - manual author (talk) 16:40, 8 April 2015 (BST)
