List of Data Types
Agiloft supports a wide range of different kinds of fields, called data types. In addition to native text, numeric, and date fields, there are a multitude of more complex data types that combine other fields or link to records and fields in other tables. Each of the available data types is described below.
Some of the more complex data types have their own dedicated articles that go into greater detail. Where applicable, these dedicated articles are linked in the Field Type column.
Field Type | Description |
|---|---|
This data type displays a button or hyperlink that users can click to perform a pre-defined action or set of actions. Action buttons are commonly used to automatically update one or more records, to generate new records such as approvals or tasks, to open a URL or send an email, or to perform some combination of actions. See Action Buttons for more information. | |
Append Only Text | The Append Only Text field is used to hold a series of notes input by different users. Each update is stamped with the date, time, and the name of the person who added the comment, and updates are displayed as read-only and in order. Entries can be displayed in chronological order with the input box at the bottom, or in reverse chronological order with the input box at the top. Append Only Text fields are unlimited in size. Generally, people can add new notes but not edit previous notes, though it is possible to give edit privileges to some users. Some common system fields using this data type are Additional Notes, Approval Notes, and Working Notes. It is possible to include just the latest note in an append only field in an automatic email. For example, in an exchange where a technician and a customer communicate via the additional notes field, rules can be set up to send only the latest update in the email instead of the entire correspondence. The Append Only heading text style can be configured in the Forms tab of the Look and Feel scheme. |
Billing compound field | There is a default Billing table generally hidden from view, available to all tables. Adding the Billing field data type to a table pulls the fields from the Billing table into the table as a set of linked fields with multiple values enabled. This allows users to create billing records from within the current table. It also adds two calculated fields to hold the total billable and non-billable hours. Access permissions to the underlying billing table are required for users to create billing records from another table. Billing Enhancements coming: auto-timer, auto-creation of billing records in background, more complex billing table structure allowing mapping of fields from parent tables into billing sub-tables so that reports run from billing table can include all relevant information from parent records |
| Calculated Result | A Calculated Result data type is a numeric field defined as a formula that uses other numeric fields—either local or linked fields—as elements of the formula. It's not actually linked to anything, but it refreshes based on the underlying field values. For example, a Billable Amount field in a Time Entries table may use the formula "$billable_hours * $billable_rate," which changes when the user adds more billable hours. This data type outputs numeric values and requires numeric inputs. Each of the fields used in the formula must be numeric. The included display settings are similar to standard numeric fields but also have a few extra options unique to the field. The field automatically updates when the input fields change, and you can configure it to only produce a result when all input fields have a value. Users cannot directly edit Calculated Result data types, regardless of their permissions. |
Choice fields define a set of options to display to the user. When you create a choice field in a table, you can select an existing choice list or create a new one. For example, you may have existing choice lists for Priority, Task Type, Status, or a simple Yes/No choice, each of which may be useful in multiple tables. Note that any choice list can be reused in other tables. Choices can be displayed as either radio buttons or a drop-down list. Furthermore, you can customize the order in which choices are listed; they can be listed alphabetically or, while editing the choice list, you can drag and drop list items to reorder them. Other fields can have their visibility and edit permissions dependent on the value in a Choice field. For example, you might only display the Other Role field if a Choice field called Role has a value of “Other.” Additionally, the list of available choices can change when the user selects a value in another Choice field. These are called Hierarchical Choice fields. For example, suppose one list contains U.S. states and a second list contains cities in those states. If the user selects Illinois as the state, then Chicago will show up in the list of cities. But Los Angeles, which is in California, will not appear in the list. The parent field is defined first, and then the child field can be defined. Navigate to Setup > System and click Manage Choice Lists to see where existing choice fields are used and to edit them. | |
Compound | Compound fields join two or more fields together to display them as a single unit. For example, the Full Name field in the People table is the compound of First Name and Last Name. You can choose to add separators between joined fields, such as "Everglades National Park / Florida." Compound fields can require uniqueness based on more than one field value to help prevent duplicate entries. |
| Credit Card | Credit Card fields capture all information related to credit/debit cards - card number, card holder's name, expiry date, and CVV. |
Currency | Currency fields can insert a currency symbol, such as the dollar sign in $30.65. Number fields share these language dependent display considerations: Best Practices
|
A date field stores a date in one of the selected format, such as May 15 2004, 5/15/2004, 15/5/04, or 15 May 2014. The format of dates is controlled in the Teams setting in Setup > Access > Manage Teams. | |
A Date/Time field stores some date and specific time on that date, such as May 1, 2004, 3:30pm. | |
An Elapsed Time field stores the difference between two points in time. They can use complex logic, allowing for a wide range of uses. For example, an Hours to Complete field may measure the time between a task being created and the task being completed. Or consider a Length of Contract field, which may measure the number of days between a contract start date and contract end date. Elapsed Time fields can exclude time based on a field value, such as when the Status field is set to Pending Customer, or based on the working or non-working hours of a team. These fields are typically automatically updated by the system through default values or rules, and they're often used in formulas or reports. For example, they may be used to calculate the average working hours to complete a task. Elapsed Time fields can also be displayed as a user entry block for entering time amounts. | |
An Email field stores one or more email addresses. Email fields can be configured to check email addresses for validity. For example, you can require that all email addresses contain the "@" character. | |
Email Pager | An Email Pager field stores the email address of a pager. Email sent to a pager is sent as plain text, and any HTML formatting is automatically discarded. |
A File with Versioning field allows attachment of any file type to a record. When adding this data type to a table, there are options to enable version control and check-in/check-out controls. An example of a File with Versioning field is a Contract Document field in a Contracts table. You can use this data type with the optical character recognition (OCR) action, which can turn flat image files or image-based PDFs into a text-searchable PDF. If Google Drive integration is enabled, File with Versioning fields can also hold a link to an existing Google Docs file, but Google Docs maintains control and Google permissions are required to open the file. Once Google Drive integration is enabled, visibility of this option is controlled by a global variable. | |
Floating Point | Floating Point fields are used to store numbers that may include decimal values. Some example fields include Billable Hours in a Time Entry table or a Rating field in a survey. This is the most common numeric data type. Any number of decimal values and any length is supported. If you aren't sure what type of numeric field to create, use a Floating Point field. Number fields share these language dependent display considerations: |
| Heat Bar | Heat bars show numeric data as a bar with colored segments. Build heat bars with data from a Related Table or from multiple Numeric fields. |
History fields are actually a special embedded table, automatically generated for new tables, which create date- and user-stamped history records of all edits and events that occur in a record. History provides a full audit trail that tracks all changes made to a record and includes snapshot capability that shows what a record looked like after any set of changes. Admins can choose to skip tracking of some fields and automated actions, which removes history records and avoids cluttered history reports. Removing a field from history tracking also makes it disappear from the Advanced Search drop-down field list. Do not delete fields without reason. In particular, you should never remove certain fields from History tracking:
To view record changes using History, click the Lookup icon next to an entry on the History embedded table. A window opens that shows you the changes made for that entry. To see what the record looks like after the changes, click the View [Table Name] After Change button. This shows you a snapshot of the record after the changes were made but before any later changes. For more information, see History Fields. The History field in a record is critical to store data that is used by reports and rules and should never be deleted. | |
Image with Versioning fields store attached files that are displayed as pictures within the record. For example, an employee record might have a small photo of that employee. Only files with appropriate image extensions can be uploaded to this field type. You can also configure these fields to display the images in the table view. | |
Integer | Integer fields are used to store integer numbers only. This data type is used rarely because it is more limited than Floating Point. There is generally little or no advantage to using Integer over Floating Point unless you want to display the numbers as a drop-down list. To make the drop-down list available as a display option, you must define the minimum and maximum values for the list. The minimum value that this field may have is -2,147,483,648 and the maximum value is 2,147,483,647. Number fields share these language dependent display considerations:
|
| Linked Logical Name | This is a special system field type; users do not typically create this data type manually. |
| Long Integer | The minimum value that this field may have is -1,152,921,504,606,846,975 and the maximum value is 1,152,921,504,606,846,975. Number fields share these language dependent display considerations: |
Multi-Choice fields are similar to Choice fields, but they allow for the selection of none, one, or multiple items from the list. Some examples of common Multi-Choice fields are Skills, Company Roles, and User Roles. Multi-Choice fields can be displayed as a multi-choice drop-down list, a set of checkboxes listing each option, or an input box with a lookup icon. Tables have space limits and Multi-Choice fields use 700KB, whereas Choice fields use only 2KB. If you need to save space, you can redesign your fields to use a series of Choice fields instead of a Multi-Choice field. For example, instead of using a Multi-Choice field to select company roles, you can list each role with a Yes/No Choice field. | |
A Password field stores passwords encrypted using one-way hash encryption. Passwords are shown as asterisks in the GUI. Administrators may set an option on password fields that will require the user to reset the password the first time the user logs in. For more information, see Password Management. | |
Percentage | A Percentage field adds the "%" sign to the field display. Using a Percentage field has no impact on the value of the number in the field. That is, it is not stored as 1/100th of its numerical value. With that in mind, if you use a Percentage field in a formula, you must divide by 100. Some examples of Percentage fields are an estimate of the chance of closing a deal or the progress toward completing an assignment. Notes
Number fields share these language dependent display considerations: |
Short Text | A Short Text field stores up to 255 characters of text. It can be set to require a unique value, which makes Short Text fields useful for preventing duplicate entries. Short Text fields can also be set to store entries in all caps, for uses like postal codes. For example, a Login field should be a Short Text field and require a unique value for each user. You may also want to prevent duplicate companies or locations, so you could use a Short Text field for the company or location name. If you need a longer text field, use the Text data type, which can be nearly unlimited in length but cannot require a unique value. |
| Singleton Check | A single checkbox representing True (checkbox selected) and False (checkbox cleared). |
Telephone/Fax | A Telephone/Fax field stores a phone or fax number. You can set a Telephone/Fax field to validate entries in order to prevent users from entering letters and to set a minimum and maximum number of digits. The system ignores commas, parentheses, and spaces during validation. There is also an option to allow multiple phone numbers to be entered in one field separated by a semicolon. Telephone/Fax fields can be set to display as a single input box or as two input boxes, with the second box intended to contain an extension number. If you allow multiple telephone numbers to be entered, you cannot display a second input box for an extension. |
Text | A Text field can store at least 1,000,000 characters of text and is used when more than 255 characters may be needed. The actual character limit of a Text field may be higher, depending on the underlying database. Text fields often work best for summary fields, but they cannot be forced to hold a unique value. Fields such as Task Description and Problem Description are examples of Text fields. Text fields can be displayed as:
For both HTML options ("Automatic HTML or plain text" and "HTML") text can be entered directly into the text field or users can click the Edit button and enter text into into a pop-up HTML editor where they can toggle between "HTML," which is a preview of the rendered HTML text and the HTML code. Both HTML options can also include pasted images, if you set the maximum field length to at least 50,000. Text fields can also be set to store entries in all caps, for uses like postal codes. |
A Time field stores the time of day, for example 5pm or 3:30am. These fields display a time with or without seconds, such as 14:00 or 14:00:30. Time fields are rarely used. Generally, they're only used to indicate the time a record is created for purposes of routing or reporting. | |
URL | A URL field stores a web site address using http(s)://... format. |
| Variable Formula | A Variable Formula field stores a formula which can include global variables, field variables, and standard functions. It is typically used in rules or other automation. |
| Survey Fields | |
| Question Description Field | The Question Description Field stores individual questions to be used in surveys or questionnaires. This data type is used to build records in a table that is specifically designed to hold questions. Each question record can include include other information, such as answer types, short question labels, and other metadata. In order to use surveys or questionnaires, the question table and its records are used with other tables and fields, such as a survey type table with records that use the Survey Definition Field and a surveys table with records that use the Survey Presentation Field. See Surveys and Questionnaires for more information. |
The Survey Definition Field works like a Multi-Choice field that allows users to select questions for a particular type of survey or questionnaire within a survey type table. This data type also allows users to define the question order, visibility dependencies, and whether answering a question is required. Examples of survey types include an onboarding survey, support case survey, or a service request survey. See Surveys and Questionnaires for more information. | |
The Survey Presentation Field stores an instance of a questionnaire or survey for a given record. It is used to define which survey type applies, to display a set of questions defined by the selected survey definitions, and to store the combined questions and answers. See Surveys and Questionnaires for more information. | |
Relationship Diagram Fields | |
| Relationship Diagram Fields | A relationship diagram field is a special data type that allows users to visualize the relationships between linked records in a tree diagram. |
| Linked Fields | |
You can copy one or more fields into the current table from another table within the same knowledgebase or any other Agiloft knowledgebase. To copy fields from a table in another knowledgebase, you must be a member of the admin group in both knowledgebases. This is useful for quickly adding fields that you have already created in another table or fields from built-in tables designed with this purpose in mind. For example, you could use a set of credit card fields or mailing address fields in several tables without having to redefine them for each table. This data type copies the fields with their attributes, but does not import any data or maintain any relationship with the source table. After you copy a field, if you make changes to the original field in the source table, your copy is not affected. | |
A "Link to single field" links to only one field in another table. This data type can be pulled into other tables as part of a linked set; values can easily be used in a filter or for automation in another table. For most cases, however, using "Link to selected fields" is a better choice because you can add fields after the initial implementation, whereas with a "Link to single field" you cannot add more fields later. See the design article, Linking to Multiple Records, for help choosing between these data types. | |
This data type enables multiple fields from a source table to be linked to the current table. This is the most commonly used linked field data type. For example, when a user submits a Case, you may want to automatically include the name, telephone number, and email address; the data can be pulled automatically based on the user's login. See Linked Fields and Reference Other Table vs. Create Independent Fields for more details. You can use "Link to selected fields from another table" with multiple values enabled (MVE), which changes their display to an embedded table. For more information on displaying linked fields this way, see Linked Fields Display. See the design article, Linking to Multiple Records, for help choosing between "Link to selected fields from another table" with MVE and "Link to single field from another table" with MVE. | |
This data type was intended to allow you to link all fields from a source table into another table. However, we recommend against using this data type because it does not add value in most circumstances. It was designed to handle small sets of fields to be reused in several tables, such as credit card fields and mailing address fields. But you can accomplish the same thing with a "Link to selected fields" with better control over the results. You can also use "Copy fields (attributes only) from another table" if you do not want to maintain any relationship with the source table. See Linked Fields and Reference Other Table vs. Create Independent Fields for more details. | |
This data type is used to pull values from more than one source table. Although this data type isn't very common, it is suited to specific scenarios. For example, you can use this data type to enable the Assigned To field in the Case table to pull values from the Contact table, to assign cases to individuals, and from the Team table, to assign cases to whole teams. See Linked Fields and Reference Other Table vs. Create Independent Fields for more details. | |
This field type shows one of the above link fields from the other direction. For example, you may have a field such as Assigned To in the Cases table that links to the Login field in the user table. This field type will allow you to create a table within each User record that shows all the Cases that the user is Assigned To. See Linked Fields for more details. | |
This data type shows the result of a configured search inside a record as an embedded table, without any preexisting relationship between the tables. To implement this data type, select a table and a saved search to show. Like other data types that display as embedded tables, you can select a table view and action bar to use specifically in the embedded table. | |
| Communications Search Result | This data type is similar to the Embedded Search Result type, but it's designed to show records from the Communications table. This data type is identical to the Embedded Search Result type except that you don't select a table, since it is always searching the Communications table, and that the data is subject to the restrictions and setup of the Communications table. For more information, see Communications Table. |
This data type stores the result of a calculation of two or more numerical fields. These fields may be on other tables. If a field from another table is used, Agiloft creates a linked relationship. If the field in the other table is modified, the data in existing tickets or objects update dynamically. This data type is often used in automation. To ensure that calculated data remains stable, all fields from other tables that are required for the calculation must be added to the current table using a linked relationship. An example of this data type is the calculation of a quoted price for a service call, based on a technician's hourly rate and the estimated duration of the work. Another related example is a calculation of the billable amount for work completed, based on the hourly rate and the actual time spent. Several fields in a table, using this data type with different filters on the same set of linked records, are often implemented to automate a process. For example, a "Number of Tasks" field counts all task records in a project and a "Number of Completed Tasks" field counts the task records with the "Closed" status. When the number of completed tasks changes, a rule compares the number of tasks to the number of completed tasks. When the number of completed tasks equals the total number of tasks, a rule automatically updates the project status to "Completed." | |
Windows Management Instrumentation Field | This field type enables the user to capture various kinds of information from a Windows-based user that can be accessed through the Windows Management Instrumentation (WMI) specification. WMI fields work natively with Windows, but the implementation uses ActiveX controls for accessing the WMI classes and properties. Your browser must support ActiveX technology to access the WMI properties, and some browsers require plugins to support ActiveX controls. To set up a WMI field, go to Setup > Tables > [Select table] > Edit > Fields, and select New > Windows Management Instrumentation Field. Fill out the wizard to choose the classes and options needed. The setup assumes you have a certain level of knowledge of the technology behind WMI. See Windows Management Instrumentation for more information. The sample knowledgebase includes a table named WMI Sample that contains common WMI field definitions and these can be copied into your current table using Setup > Table > [Select table] >Fields > New > Copy Fields from other table. If WMI fields are hidden by dependency conditions, they do not run the corresponding ActiveX components to poll the user's machine until they become visible. |
