The Last Resort: Custom Fields

For many years, I worked implementing different enterprise systems for organizations of all sizes. At some point during the project (hopefully earlier than later), someone would discover that the core application had no place to store a potentially key field. Against that backdrop, the team and I had a few choices:

• customize the system
• store the data in a standalone spreadsheet or database
• add and use a custom field

While a custom field was often not an elixir, it often solved our problem. At the very least, it was usually the lesser of the three evils mentioned above. A custom field would not tax the IT department nearly as much as tweaking the code, and functional end users enjoyed being able to see that information in the native system–and report off of it.

In this post, I’ll review some best practices associated with custom fields.

Tip 1: If necessary, make it required.

Some systems I’ve seen lacked fields for specific information related to employees or vendors. Perhaps the company had to track whether an employee received a laptop or if a vendor required particularly unusual payment terms. (I’m using fairly generic examples here). In that case, adding a custom field made all of the sense in the world.

While optional fields can be beneficial, understand that there are perils associated with not requiring users to enter data for them. In the examples above, requiring a “Yes/No” response theoretically guarantees that someone selects one of the two in that field. (Of course, it might not be the right entry, but that’s a totally different discussion). Note that you might not want to require a field that only applies to two percent of the population, lest you face mass disaffection from your users–and a good number of errors.

Tip 2: Lock it down.

With custom fields, the single biggest mistake I’ve seen organizations make is to give employees the ability to add their own values. Imagine a drop-down list for employee laptops with the following choices:

• YES
• NO
• ACER
• DELL
• DELL INSPIRON
• IBM
• IBM PC
• MAC
• DLL (intentionally mispelled)

Lists like this can explode in no time.

Agree on a predefined set of choices and restrict end users from adding their own, unless you trust them and they have been trained. Remember GIGO. Anyone reporting on “YES” only will not get true results–and incorrect business decisions will result.

Tip 3: Audit.

Creating a custom field by itself means very little. Regularly running audit reports can often nip a big data problem in the bud. In the example above, the purchase of more expensive Mac computers might drive higher procurement costs, although I would hope that most accounting departments wouldn’t need to rely upon a custom field.

But perhaps Macs need a software update and the organization needs to quickly amass a list of those with Apple computers. The possibilities are limitless.

Tip 4: Don’t overdo it.

Creating necessary custom fields can certainly bail organizations out of some pretty big problems, but it’s importnat not to rely on them too much. In other words, if your application requires 100 custom fields, maybe it’s time to look at a new system altogether–either enterprise-wide or best-of-breed. Custom fields are typically the places of last resort. Odds are that systems that rely upon them to a large extent are not terribly robust.

Simon Says

Follow these rules for creating custom fields and you should be able to get more out of them.

Feedback

What say you?