Core fields

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. 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 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.

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 AR System core fields.

ID	Field name	Description
1	Request ID	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 5 characters. The Request ID field is fundamental to access control in AR System . Groups that do not have Change or 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. For join forms, there is no limit to the number of layers of joins that AR System supports, so the Request ID field of a join form contains more than 15 characters. Do not change the QBE Match setting to Equal for the Request ID field. Because 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. 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. Data Type: Character Length: 5-15
2	Submitter	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. 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 Controlling access by using implicit groups: Row-level security. For information about preventing changes to this field, see Enabling submitters to modify requests. Data Type: Character Length: 254
3	Create Date	The date and time at which the request was created in the system. The 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. 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 AR System , see Special groups in AR System. Data Type: Character Length: 254
5	Last Modified By	The name of the user who last altered the request. 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 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	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. (This field rejects a NULL value.) The actual names and values of the status field can be customized. Status is a required field. 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, 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 Data fields. 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. 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 Defining application menus. 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. 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 fields

Comments