BMC Remedy AR System core fields are a set of fields that every regular form must have. You can include these fields in other forms; if present, the fields follow the same rules and have the same meanings. The commonality gained by such a convention is useful for conceptual consistency, sharing definitions, and exchanging and merging databases.
Additional limits are placed on the core fields, including the fact that some fields are required, others are maintained by the system, and others have fixed or maximum sizes.
Core fields generally appear on every regular form to make sure that all forms share a common set of concepts. BMC Remedy AR System automatically includes core fields on all regular forms. Because display-only forms and joins do not directly store data in the database, core fields are not required for these types of forms. Core fields are also not required for view and vendor forms because they map to external data sources, which might not have these fields.
Core fields help provide consistency when merging and sharing data. Core fields significantly aid in the construction of solutions based on BMC Remedy AR System. You cannot delete core fields from regular forms-- although you can modify their appearance by altering labels, adding or changing menus, altering the display type, altering their location, or hiding them from view.
BMC Remedy Developer Studio localizes the labels of the core fields based on the server language and whether the server is UTF-8 or not. If the server is UTF-8, then the Developer Studio uses the current locale to localize the labels and does not base it on the server language.
The following table lists the BMC Remedy AR System core fields.
BMC Remedy AR System core fields
A unique identification value for each request in the system.
The Request ID field contains a character string that holds a unique index for each request. The form of this string is an optional prefix, which can consist of any alphanumeric characters, followed by a 0-padded numeral (for example, HD0000000000001 ). The length of the Request ID field must be either 1 or between 5 and 15 characters, inclusive. Specifying a length of 1 causes leading zeroes to be stripped from the value in the Request ID field. The prefix can be as long as the total length of the field less five characters.
Groups that have neither Change nor View access to the Request ID field do not have access to any other form information, regardless of the permission settings of the other fields. Data Type: Character Length: 5-15 For join forms, there is no limit to the number of layers of joins that BMC Remedy AR System supports, so the Request ID field of a join form contains more than 15 characters. See Joining three or more forms for more information.
Do not change the QBE Match setting to Equal for the Request ID field. Because BMC Remedy AR System adds a prefix and a series of zeros to Request IDs before it begins a search, users cannot run valid QBE searches against Request ID numbers if you set the QBE Match setting to Equal or Leading.
|2||Submitter||The name of the BMC Remedy AR System user who was logged in and submitted the request. This field is tied to the Submitter group when defining row-level security. For more information about row-level security, see Controlling access by using implicit groups: Row-level security. Submitter is a required field. Data Type: Character Length: 254|
|3||Create Date||The date and time at which the request was created in the system. The BMC Remedy AR System server sets this field, and it cannot be modified. Data Type: Timestamp|
|4||Assigned To||The user who is assigned responsibility for the request. This field is tied to the Assignee group when defining row-level security. For more information, see Controlling access by using implicit groups: Row-level security. Data Type: Character Length: 254|
|5||Last Modified By||The name of the user who last altered the request. BMC Remedy AR System sets this field to the login name of the user who last changed the request. It cannot be modified. Data Type: Character Length: 254|
|6||Modified Date||The date the field was last modified. The BMC Remedy AR System server sets this field to the time the last change to this request was made. It cannot be modified. Data Type: Timestamp|
|7||Status||Indicates the current state of the request. Users have control over this field. It must have a value at all times; there must be a default value in the event that the user does not specify a value when the request is created. The actual names and values of the status field can be customized. Status is a required field. Data Type: Selection|
|8||Short Description||A brief description of the request. A size limit forces the submitter to be concise. Short Description is a required field. Data Type: Character Maximum Length: 254|
|15||Status History||The user who last made a change, and the time the change was made to each of the states identified by the Status field. BMC Remedy AR System sets and maintains this field, and it cannot be modified. If status history recording and reporting is disabled, the status history is cleared and not updated. Data Type: Character|
Core field characteristics
The following core fields have special characteristics that you should consider when defining a new form.
Request ID field
BMC Remedy AR System uses the Request ID field (Field ID 1) to provide a unique identification value for each request entering the system. It is created and maintained by the system.
To improve the usability of the Request ID field, you can add a prefix to the field to make it more descriptive to your users. For example, in a distributed server environment where you transfer requests from Los Angeles to Chicago, the system can add the prefix LA to requests generated on the Los Angeles server and CHI to requests from Chicago. For more information, see Changing the Request ID field length or prefix.
The Request ID field is fundamental to access control in BMC Remedy AR System. Without access to this field, users have no access to the request, even if they belong to groups with access to other fields on the form. Groups that have neither Change nor View access to the Request ID field do not have access to any other form information, regardless of the permission settings of the other fields. For more information, see Using the Request ID field with implicit groups.
The Submitter field (field ID 2) defines which user created a request. The user who create a request is automatically a member to the Submitter implicit group. See Submitter and Assignee access. For information about preventing changes to this field, see Enabling submitters to modify requests.
Short Description field
The Short Description field (field ID 8) provides a common place for users to summarize a request. By default, the Short Description field contents appear in the results pane of a form whenever a search is performed.
You might want to include a menu of possible problem and request types for the Short Description field to make request submissions easier and reporting more efficient. For more information, see Working with menus.
Your application can use the Status field (field ID 7) to track the different states a request moves through in its life cycle. The meaning of each individual state helps define the workflow process and you can define any number of states. In addition to keeping track of each state of a request, BMC Remedy AR System keeps additional information with the Status field called status history. Status history includes the user name of the person who last changed the state of the request and the date and time that the change occurred. If status history recording and reporting is disabled, the status history is cleared and not updated.
Define states carefully. The Status field is the key field that represents the problem resolution process. The states must capture the important steps in the process, although not all states might be used during the life cycle of a single request. A good process is often represented by four or five states.
It is difficult to modify the Status field choices after users have begun to use the form, because the data for a selection field is stored in the database as an integer that relates to the order of the choices. For more information about selection fields, see Selection fields.
Assigned To field
The Assigned To field (field ID 4) enables ownership of each request to be tracked. If requests are designed to pass ownership from one user to another, create workflow that uses the Assigned To field. Users who are assigned ownership to a request are automatically assigned membership in the Assignee group. For more information about the role of the Assignee group in BMC Remedy AR System, see Special groups in BMC Remedy AR System.