Do’s and Don’ts with Custom Fields in CLASS


Carefully Plan the feasibility of the custom field

Consider these things when creating a custom field

  1. What data needs to be recorded and why. Is a data field the best way to collect this data? Is the field for reporting purposes or Key Performance Indicators? If so think of the best way to measure, your desired output and the easiest way to record.

  2. What is the granularity of the data you are trying to capture?  Should the value you are capturing  be associated and visible with the Client, Service or Problem Type(Data entities)? Attributes associated with Clients for instance are properties that don’t change over time/service of the Client, for instance Date of Birth is associated with the Client.

  3. Is this data already available within our standard fields in CLASS and or our existing custom fields to avoid data duplication and double entry

  4. Remember adding a new data field comes with some overhead.  Users need to know it exists and why.  To fill it in correctly they need to be aware of and  understand its definition and purpose.  It needs to be maintained in the future. (

Consider Best Practices from a usability standpoint

  1. Ensure the title of the field is descriptive but also concise

  2. Create definitions (if not obvious) for the different values available in the field.    

  3. Ensure a consistent naming convention for fields if they are related to a group for instance  or if they  are related to a short term project

  4. Choose how the user interacts with the field (type) for example a Comment box or Single input.

  5. Choose the correct field type for what you are trying to capture: 

    1. Number – Used so values can be added quantitively

    2. Text – Defined Categories can be used to quantify responses (avoid free text)

    3. Date – Used for any kind of date stamp, measurement of day, month, year

    4. Time – Used for any kind of time stamp, measures time

    5. Email – some validation performed that is valid email.

  6. Avoid Plain free Text boxes where possible.  To improve data quality choose defined text options for your users and create definitions for them if necessary.

  7. Plan for edge cases to avoid issues with the process especially during launch or usage i.e. if you planned to release several Custom Fields. In this case a multi-line paragraph text box can be useful however use it sparingly.

  8. Consider where the field should sit on the interface itself.  Should it go under an existing grouping such as Service details or on its own Group (more on this later)

Consider if the Custom Field needs to be on the Client record or Service Record

Consider whether your custom field needs to appear on the Client record or the service record. Do note that when creating custom fields for services you can cause these to appear based on the problem type (or service type) of the service so that is more specific as with custom fields on a client these can only be mapped to a narrower scope.

To begin customizing remember the “Customize” button via the top right > Custom Fields Tab > New Button or Navigate to an existing field by turning the pages.

Consider if the Field should be Mandatory

Consider when it is appropriate to make a field Mandatory if these are reporting KPI specific and it’s a custom field its likely that making it Mandatory would be a good thing. This is done by selecting “Required For” after opening the custom field. On the other hand having too many Mandatory fields increases the time per record and may reduce data quality and stats due to user frustration.

Enable Filtering and Reporting on the Custom Field

You can enable Custom Fields to be filtered on in views such as Search Services and Search Clients. This is via the “Show in list view” tick box.

Adding Standard or Custom Fields with the Column Chooser

Utilize Custom Fields on DIY Reports and consider using the Report Column Header

Similar to the above point the “Show in Report View” enables custom fields to be searched for and dragged and dropped into DIY Reports this is turned on by default when you first create a Custom Field.

Just note that custom fields are normally prefixed with “CF _” and will not present data unless the “Include Custom Fields” tick box is checked on the left hand side just above the load report button.

Utilize a Grouping for your Custom Fields

On a service record for example rather than the custom fields appearing at the bottom of the Characteristics section and or the basic details section it may be more beneficial to “Group” them in there own section with a Label. Some Examples Centre’s have used this to centralize on a record:

  1. Unique Metrics they need to Track and or Business processes
  2. Veteran status and fields related to that
  3. Conflict Check and Supervision Workflows

To Group fields you need to:

  1. First create a new group via that familiar customize button on the top right of an open service or client record.

  2. After pressing the button and going to the “Custom Fields Tab” instead of pressing New via the top right again highlight it (mouse over) and select “New Group”. All you will need to enter is a name and save i.e. “Service Check” 

Now any existing fields or new fields can be put under that grouping by first opening the custom field and updating the group field 

An example Grouped set of Custom Fields below: 

Consider Shortening the name on a field on DIY Report for a Custom Field

Where appropriate you have the ability to shorten and or abbreviate a custom field’s title on a DIY Report view so the Column Title does not take up too much space. We don’t suggest you use abbreviations unless its extremely common knowledge at your centre but just to shorten the name if you want DIY reports with allot of custom fields to be displayed in a more user friendly manner after you have pressed the “Load Report” button.

Use Drop Downs rather than column based buttons or radio buttons

This is preferential but please remember a drop down can encapsulate more information and display in a more compact manner rather than having several columns of buttons, this will increase the usability of your services.

In particular for Multiple Choice (Only One Answer) the drop down should be the preferred display method.


Make sure not to edit Standard NLAP related fields and or to create custom fields to capture the data as this may affect your standard Reporting

If you are unsure where to record a demographic or if said field already exists in CLASS please contact our helpdesk and we can look into that for you. Please also review the Data Standards Manual and our Data Consistency Guide

Do not change a Custom Field’s data type and or how it is displayed once it has been in use so please plan carefully

This can cause issues with the risk of not being able to display prior data recorded especially if the data type has been changed reports will need to be run on a particular time period rather than broadly now to capture a modified field

Existing Custom DIY Reports with a changed custom field will now throw concurrency errors and may need to be updated

Do not use special characters within the options and or title of the Custom Field

We suggest you avoid the insertion of Characters such as an Apostrophe ‘ or any other special characters: (!,$,%,^) as this can cause issues when exporting content out of CLASS and into other systems as well as within CLASS itself.

Do not use Single Check box if the data you are trying to record could be more complex or better encapsulated with a Dropdown

The Single Check box are better suited to opt-in type data that isn’t typically included in CLASS (like marketing emails tick box, client advised of file destruction policy etc). Having a Dropdown with options for i.e. Yes, No, Unkown, “N/A” can prove more useful from a reporting perspective as the Check box will show up as “Yes” for ticked and blank for the rest.

Do not leave unused fields if they are mandatory active

We suggest if a field or set of custom fields were used to record information and or a survey for example and are no longer used that you don’t delete them but instead hide them from the record itself by un-ticking active and removing all permissions under “Show For” and “Available for” by clicking the “x” next to each option then saving.

Part of this process may be appending something like “Old do not use” to the field name so future CLASS administrators at your centre are aware when looking at existing custom fields. Consider creating a Living document internally that keeps a catalogue of your custom fields and their historic usage as its better to be prepared or able to report on these if some need for doing so will arise in the future.

Related Reading:

Managing Custom Fields 

Customization Training