Page tree
Skip to end of metadata
Go to start of metadata


Tables are containers used to group similar information types into discrete locations, such as contracts, users, or assets. The table defines the attributes of your data and stores that data in records in the database. Tables include the whole set of fields, relationships, and rules that govern how records act in the system. Additionally:

  • Individual pieces of information are stored in fields with a variety of attributes such as text, choice, and number.
  • Access to tables is controlled by group permissions, and tables you have permission to access are displayed in the Tables menu in the left pane. When new tables are created, only the admin group has permission until permission is granted to other groups.
  • You can create custom tables and relationships between tables.
  • Data from one table can be displayed in another table through linked fields in one-to-one, one-to-many, and many-to-many record relationships. For example, you might create a Support Contract table and an Asset table and then create a linked field relationship that connects each Asset record to information about its corresponding support contract.
  • Tables can contain subtables that inherit properties like fields and rules from the parent table. Features available in tables are also available for subtables, including: fields, layouts, searches, views, workflows, rules, charts/reports, permissions, and email. Records in a subtable are also viewable and can be worked on from the parent table. 

    Because subtables complicate an implementation, you should use them sparingly.

To create and edit tables:
  1. Go to Setup > Tables.
  2. Then:
    • To create a new table: With the Table Tree selected, click New.
    • To create a subtable: Select the table that will act as the parent, then click New.
    • To edit an existing table: Select the table and click Edit.
  3. Follow the Table Wizard to complete the process.

Background and Process Tables

The system uses two kind of tables: background and process tables. Background tables hold relatively static data used in the other tables. Background tables do not generally have business processes or significant automation associated with them. They're usually built before process tables. A table holding user or company records would usually be a background table.

Process tables hold records that are actively worked on, usually with some kind of user-followed workflow and dynamic activity. They generally pull in records and field values from background tables, such as the company associated with a contract. A table holding contracts that follow an approval process is an example of a process table.

Table Hierarchy

You can create a hierarchy in Agiloft by creating subtables. Subtables inherit fields and rules from their parent table.

Table Appearance

Views control what data is displayed when looking at a list of records (rows).

The table's layout determines how fields are arranged when viewing a particular record.

Table Configuration Tips

If a customer is using  Agiloft for a function that is not included in the default KB and is not using a default table, consider whether you can rename one of the default tables to benefit from the preconfigured reports and charts.

Be careful which item in the table tree is selected when you create a new table: select the top level of the hierarchy to create a new top level table, or select an existing table to create a subtable of it.

Completing work on a table involves the following tasks:

  • Create the table and all the fields.
  • Create a good layout that uses the fields in a reasonable order. If the table will be accessed by end users, the power user layout can be copied and edited to remove unnecessary tabs/fields.
  • Set the ownership permissions for the table on the Permissions tab of the Table wizard.
  • Create a Default view.  Make the view available to all teams and apply it as the default to all teams/subteams.

Layout Tips

  • We suggest changing the default alignment for all layouts to use the second alignment option, Align rows with same number of columns, instead of the first default.
  • Create an end user layout for tables that will be accessed in the End User Interface. To do so quickly, copy the power user layout to the end user layout to start with. That way the fields will appear on the layout during testing, and you can make adjustments after.
  • As a general rule, a two-column layout looks best.
  • Wide fields should be placed on their own row. 
  • Use the Preview button to see how the layout looks since you can't preview the end user layout. Know your fields and their widths to make the best layout.
  • If you are using visibility dependent fields that only show up if another field has a certain value, always put them to the right or on their own row; never use them in the left column before a field that will always appear.
  • Likewise, if you are putting a field on the form that only some users can see, don't put it in the left-hand column followed by a field that always appears. The missing field's space will not be compressed, and it will show up as an empty space in front of the field to the right.
  • Before closing the Table wizard, remember to click Finish to save the changes. Closing the window or canceling out of the wizard will discard all the changes.