Every Remedy developer knows that every regular form has eight special fields, numbered from 1 to 8, each one with a particular objective. The last of them, the short description, is often treated as an annoying feature of Remedy, specially when it is a required field. But far beyond it, the short description is a very important field that must be used as often as possible.

In this post I will cover the Short Description field, showing its special features, and providing some best practices.

The Short Description field

Short Description field, numbered 8, is a required text field with a predefined length of 254 characters. When you create a new form, it is automatically included as the rest of core fields. It seems to have no special use but to contain text.

A lot of Remedy developers automatically set this field with a default value of a dot or $USER$ and hide it. That is, to avoid using it. We can see this behavior even with BMC developers. In fact the majority of main forms of BMC Remedy ITSM Suite show this behavior (HPD:Help Desk is an example). So, why has BMC included this field as a core field when even its own developers avoid using it? That’s a good question. My opinion is, as almost always, that BMC developers doesn’t follow the best practices.

What’s the objective of the field id 8?

The rest of core fields has an easily deductible objective. Submitter is used to name the user who submitted the request. Assigned to is used to name the user who is responsible of attending the request. And so on… But Short Description seems to have no use for the majority of forms. Under my opinion all the problem resides in a bad name choose for the field. A better name would be just “Name”. That’s the objective of this field, to hold the name, summary or description of the request. And this is not as uncommon as you can think at the first moment.

Almost all regular forms have a summary field, a name, a subject or some text that describes it. So my recommendation is to use this field and to store that text. For an incident you have a subject. For an SLA you have a name. For a contract you have a summary. So don’t create a new field called “Name”, just rename the Short Description field to “Name”.

Advantages of using the Short Description field

First, ARS expects that field to contain a name or summary of the request. And you can find this expectation in several aspects of ARS. For instance, the default result list of a form is the Short Description field. In fact if you use this field as intended it will surely be included in your result list. Another example is the audit log form. As the rest of core fields, this field is copied at every audit. So when you list your audit log, the name will be the human-friendly id of your log registers.

Another advantage comes from sharing the same field id for this purpose. ARS is oriented to the field id, the field’s name is not important for ARS. So having the same id, is like having the same name for ARS. That means that every time you design some workflow to be shared, you can expect to have a name at field id 8. For instance, you can have a list of related elements to a request. The related elements can come from several forms. So you need to create a form that holds the relationships. In this form you can copy the field 8 of the related form, so you have the name of the object. It can be the name of the user, the contract, the incident, all form will have a name at field 8, allowing you to share the workflow elements.

Also, if you normally dive inside the database, to have a description at field C8 is of great help.

Finally if you share an audit form, field 8 will always be copied and will ease the reading of the log.

Final though

I think it is a bad practice to automatically discard the Short Description field, instead of trying to use it for what it is intended. I don’t mean to reuse it for storing a text sentence that is not a descriptor of the incident, this would be even a worse practice. I mean to use it as it is intended.