Understanding Valid vs Invalid Outlook Contact User-Defined Field Names

If you create user-defined fields and only use these fields within Outlook itself, then this article will be of little or no interest. If, however, you need to (or at some point, think you will need to) share information between Outlook and an external data source, this article will cover some points that can potentially save many problems – specifically in terms of how field names are constructed.

Outlook virtually has no rules when it comes to the creation of user-defined field names, that is, almost any character is allowed in the construction of the actual user-defined field name with the following exceptions which are not allowed:

1. <_> (underscore/underline)
2. <,> (comma)
3. <#> (number/pound sign)
4. field name length not to exceed 32 characters

On the other hand, database products (such as Microsoft Access) have individual rules in terms of what characters are disallowed when defining database field names. The most common across all databases are:

1. < > (leading space)
2. <.> (period)
3. <!> (exclamation point>
4. <`> (accent)
5. <[> (left square bracket)
6. <]> (right square bracket)
7. — (any non-printable character)
8. field name length not to exceed 64 characters

Comparing the two lists above, you’ll notice that there is no overlap between the two, or in other words, any of the three illegal characters in Outlook can be used to define a field in MS Access and conversely, any of the illegal field characters can be used in user-defined field names created in Outlook.

So why does this matter to you, the Outlook user? It’s not your problem, right? Let whatever software that is going to move the data into and out of Outlook worry about things. That may be true but the focus and emphasis of this article is on “problem avoidance”, not right or wrong. To stress, different databases can have different rules as to field name structure and different file processing engines can also enforce their own restrictions (such as Microsoft Jet, SQL etc) when dealing with file names and data elements.

At a very minimum, using any of the characters above in field names, be it within Outlook or your database, means that the field name containing any illegal character cannot be duplicated between the two (i.e. <Rating.Value> – legal in Outlook is illegal in MS Access so either the field will be disallowed or some kind of character replacement will have to occur (i.e. replace an illegal character with another – such as an <*>). The other downside of character replacement is that duplicate field names can result.

A very simple example that you can try for yourself is to create a simple Excel spreadsheet giving one column the column name of “General P.O. Box” and try to import that into Outlook. You will notice that the period characters are replaced automatically by the Microsoft Excel file driver with “#” characters. Save the same worksheet as a CSV file, and the period characters are not changed when importing otherwise identical information. (ContactGenie products that process text files for importing purposes, first import the text data into an internal database and therefore the field naming conventions in terms of illegal characters apply to text files).

So what is the best practice to follow?

Very simply, the simplest and safest approach is to use only alphanumeric characters (a-z, A-Z, 0-9) with no spaces. For example, a field name of <RatingValue> is just as clear as one defined as <Rating.Value>. One only needs to look at Microsoft’s own internal field names for standard Outlook fields – <https://www.contactgenie.com/outlook_fields.htm>. For someone new to naming conventions, it can take a little getting used to thinking in terms of how a field name is to be constructed for programmatic use versus the field name (displayname/caption) that will be used for display purposes.

To put the best practice even more simply – follow the “KISS” principle and do not get cute/creative.

Internal versus Display Names for Outlook user-defined fields

When creating a new user-defined field in Outlook, the initial field name entered is defined as the internal UDF name for the field. It cannot be changed once created. When the UDFs are being created for a contact item that does not use a custom form, there is only one field name that is ever displayed in the “User-defined fields in folder” or “User-defined field in item” lists and that is the name used when creating the user-defined field.

When creating user-defined fields during the design of an Outlook custom form, there are actually two names associated with any given field. The first is the internal name used when working with a given field and the second is the DisplayName (or caption) which is the value used to show the field on the custom form. As mentioned, when creating a new user-defined field during custom form design, the initial name entered is assigned as the internal name but in this case, that name is also assigned as the field <caption> by default. Far too many people, create a user-defined field using the name they would like to see it on screen when the custom form is displayed. A field caption can be changed at any time after the field is initially created so some discipline should be used when creating new field names.

The Outlook field chooser in the custom form designer, shows all Outlook field names using the assigned DisplayNames and not internally assigned field names. DisplayNames will vary based on the language in use (i.e. English, French etc). A complete cross-reference of Outlook internal field names to display names for 9 languages can be seen here:
https://www.contactgenie.com/outlook_fields.htm

Following the rule of simplicity will go a long way in avoiding issues with other programs that deal with Outlook data with the operating assumption being that the priority is to get the job done and not try to find out how many exceptions there are to any given rule.