The People table is one of the most important tables in your system because it stores records that represent the people who interact with your system. Most systems categorize users into two types, which influence how they are able to interact with the system. These user categories are Employee and External User, and are represented in the system as subtables of the People table. The People table is considered a top-level table, which simply means that it has subtables. The People table is one of, if not the most, prominent background tables in   Agiloft. When you create a record in the People table, the user category determines which subtable the record is stored in. All subtable records are contained in their top-level table, so you can view all Employee and External User records directly from the People table.

The two subtables, Employees and External Users, are chiefly used to store information about individuals, such as the company they are associated with, or their contact information. Users may be external or internal to your company, so it is vital from both a security and workflow-enabling standpoint to put users in the right groups and teams.

Users outside your company should generally go to the External Users table, while Employees should go into the Employees table. We recommend that all individuals who are involved with your company, even people who are not able to access the system as a user, be stored in the system as either an Employee or an External User. The primary benefit of adding them all is that email notifications can be sent to them via Agiloft if needed. This gives people like vendors or leads the potential to interact with the system, if it becomes necessary.

Ownership

Records in the People table are owned by the user in the Contact Owner field.

Automation

In the standard system demo, the People table contains one active rule. This rule is accessed by expanding the People table in the left pane, selecting Setup People, and then selecting the Rules tab:

• TB Demo Data Update: This time-based rule runs once every month, updates Demo Date fields, and deletes History. It consists of two actions: "U: Update Demo Dates' and "D: Delete History for TB: Demo Data Update." "U: Update Demo Dates" is an Update action that replaces the Date Created, Date Updated, Original Start Date, and Reference As Of fields with a date one month in the future. "D: Delete History for TB: Demo Data Update" is a Delete action that deletes history entries that are created after "U: Update Demo Dates" updates the designated fields.