The People table stores records that represent the people who interact with your system, making it one of the most important tables in your system. The People table is one of, if not the most, prominent background tables in   Agiloft. The People table is considered a top-level table, which simply means that it has subtables. 

Use Case

Most systems categorize users into two types, which influence how they are able to interact with the system. In the Standard System Demo, these user categories are Employee and External User, which are represented in the system as subtables of the People table. When you create a record in the People table, the user category determines which subtable the record is stored in. In general, 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 users like suppliers or leads the potential to interact with the system, if it becomes necessary.

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:

• Create/Edit: Update Role is not empty validation; add or remove roles updates: This rule uses a saved search to find people records in which Update Role field is not empty and runs an update action to ensure that a group does not get removed if another active role is associated with it. It also contains an If-then-else action to handle role updates.
• Create/Edit:  Append Primary Team to Teams (web, API): This rule uses a saved search to find people records in which Primary Team is not contained in the Teams field and runs an update action to append the Primary Team to Teams.
• 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.

Ownership

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