A field is both a place to input a specific type of information, and the information itself that is then stored in that part of a record.
Agiloft supports fields of many different data types, such as text, single choice list, multi-choice list, integer, floating decimal point, telephone, email, URL, attached file, date, time, date/time, elapsed time, currency, and so on, and each field can be provided with validation rules appropriate to its type. For instance an integer field might require a value between 1 and 100. A full list of field types is provided in List of Data Types.
Each field has a "field name" and a "field label". The field name is the name of the column in the database, and may not contain spaces or most special characters. The field label is the value that users see through the GUI. Labels can contain spaces, for example Customer Name.
Agiloft provides full National Language Support, meaning that field labels can be translated into multiple foreign languages so the user will see labels in the language specified by their browser settings.
Adding and Modifying Fields
To review the fields for a particular Table and add, modify, or delete fields, go to Setup > Tables, select the Table to edit, then select the Fields tab.
To add a field:
Hover over New to view the drop-down of all available data types. A new progress window with progress indicators will pop-up when an administrator adds a new column to a table to indicate how long the operation will take. Adding database columns is usually quick, but can take longer in certain circumstances and on some systems.
To modify a field:
To change the settings for a specific field, click the Edit icon next to the field name. This opens the Field wizard where you can set default values, basic permissions, visibility or edit conditions, and other options based on the type of field.
Mass editing field properties
The Set Field Properties item on the action bar lets you set certain properties for multiple fields at once.
The following properties can be mass-edited: Set Visibility Dependence - sets visibility dependence on another field, Set Edit Dependency - conditional editing requirements, Set Requirement Dependency - whether the field is required under some conditions, and Enable/Disable Quick Edit - whether Quick Edit is enabled.
To do this:
- Select one ore more fields to edit.
- Hover over Set Field Properties and choose which property to change.
- Use the pop-up window the change the settings, and then click Finish to save.
The settings window shows the names of the selected fields. The dialog will also list any fields that cannot be modified, which is usually due to a data type incompatibility. For example, the system may say, "The changes won't be applied to the following fields: contacts_to_contacts."
|Data Type||Visibility Dependency Conditions||Restricted Editing Conditions||Requirement Conditions||In-Table Editing|
|Append Only Text||X||X||X||X|
|Long Integer Field||X||X||X||X|
|Linked Logical Name||X||X||X|
|Question Description Field||X||X||X|
|Survey Definition Field||X||X||X|
|Survey Presentation Field||X||X|
|Linked Data from Another Table||X|
|Embedded Search Result||X|
|Communications Search Result||X|
|Calculation on Multiple Linked Records||X|
|File with Versioning||X||X||X|
|Image with Versioning||X||X||X|
Each table comes with a set of default fields:
- Created By
- Creator Login
- Creator Team
- Date Created
- Date Updated
- Updated By
- Updater Login
- Updater Team
- Demo Data
- Communications - search result of emails linked to the record
You can change these default fields from the Table wizard by clicking Edit when Table Tree is selected. This allows you to create new tables that inherit different or additional fields.
Every table must have exactly one summary field. A summary field represents records at certain places in the system. For example, a table's summary field controls the items displayed under Last Opened on the left pane. And if you link two records in a table, the system uses the table's summary field and record IDs to indicate the linked records.
A regular Text field often works best for a summary field, but you can use any text field data type. To make a field a summary field, select Yes for Display as summary field? on the Options tab of the Field wizard. If you already have a summary field defined for the table, you'll receive a message indicating that the current field will be used instead.
For a new table some general field cleanup is likely to be necessary:
- Correct the History field that is automatically created - it must have the following changes made to it:
- General tab: change the field label to upper case: History. This way we know it has been touched.
- Permissions tab - give admin all permissions.
- Display tab - check all the boxes for the columns to display. Be sure to put the history field on a tab on the layout, usually on its own tab displays the best.
- Change the tab name for Communications in the layout to Emails to make it take less space.
Field Design Considerations
- Editing the linked field settings for a subtable in a hierarchical table setup will change the settings for all other subtables in that hierarchy.
- Fields cannot be converted from one data type to another. However, it is usually possible to create a new field of the desired data type and use the Mass Edit "Formula" feature to assign the old field's values to the new one.
- The "Type" field is only a label. When building dependent choice fields the "Type" field can not be the parent for a dependent choice field. For example, you can not have some options display if the subtable is SubTableA, and display other options if it's SubTableB.
- It is possible to set dynamic field defaults based on occurrence of results of changes in other fields values. For example, a date field might be set to the date that another field value changed. However, these are sometimes counter-intuitive and better handled via rules instead.
- You can delete any fields or tables not marked as undeletable. Often it is safest to just hide fields via permissions or layout instead, because deleting fields used by searches or reports may break them. If you try to delete a field used by linked fields you will get a warning wizard from the Integrity Manager that walks you through the deletion process.
- For a Related Table data type, be sure to edit the label on the first screen and on the display tab, check the box to left justify it. This makes a better display.
- Always when creating a linked set that includes ID field, edit the display characteristics for the ID field itself on the Display tab to make it 10 characters or less in width, otherwise it has a bad default and takes up about 70 characters, which looks bad.
- Never use the data type for a Link to Single Field in Other Table, except when multiple values must be enabled. It is inevitable that when you do this, the customer decides they want to include a second or 3rd field in the set, and it has to be completely redone. Always use link to selected fields, whether or not it is specified.
- When creating a linked field set, on the Mapping tab, never choose Do Not Update while leaving the box that enables non-source values empty. This will cause errors. Always Update should be selected in 99% of cases. If you enable non-source values you can use update matching fields instead.
- For a linked field with a default value, on the Options tab, always choose one of the two radio buttons that define whether to update when the underlying condition changes.
- When setting up date/time fields that will never be entered by user, don't use calendar and popup display, use simple text box 22 wide.
- When doing choice fields with only 2 choices, radio buttons typically look better. On the display tab, explicitly set it to 2 per row.
- When creating a text or short text field, don't skip the Display tab - you will almost always need to set the size of the display box away from the 70 default value.
- Wide text fields should all have the same display width to look neat, unless you use the "expand all fields to the same width" option on the alignment tab of the layout. Typically 90 or 95 is a good width that works on most screens.
- Write admin notes for fields when creating them. Admin notes can be printed out to create system documentation and reference materials for end users or other admins. Additionally, if another person takes over administrative duties, or you need to edit a field months after creation, they will help explain why a field exists. Remember that other people with different background knowledge will probably read your admin notes.
- Until you are familiar with each data type, always check the Display tab to be sure the display settings make sense, as it will save you time when creating layouts.
- Always label fields with titles that make sense and describe what they are used for so that anyone looking at the Fields tab can easily understand a field’s purpose.
- When building a new table, it's generally easiest to initially skip setting permissions for each field and to instead leave the default permissions as the admin group only.
- Always consider whether you're working with a live system when adding fields. Adding fields to a table locks it for other users, so consider doing so after working hours if the system is live.
- Certain data types use less space in the system than other data types. If creating a table with many fields, use Text fields over Short Text fields and Choice fields over Multi-Choice fields to save space and increase loading speed.
- Create fields in an efficient order. If a field will have other fields depend on it, such as for visibility or requirement conditions, create that field first.
- Make use of pop-up text or input instructions. They can explain a field's purpose to users or describe how it's used in automation.