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  

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, subtables ( Employees and External Users) of the people table , are chiefly used to store information about individuals, including any associated company or such as the company they are associated with, or their contact information. People Users may be external or internal to your company. It is important to put employees on the right Groups and Teams to control their access.

In this document, the terms "contact," "user," and "people"/"person" are used interchangeably.

, so it is vital from both a security and workflow-enabling standpoint to put users in the right groups and teams.

Users People outside your company should generally go in to the External Users table, while Employees should go into the Employees table. We recommend that all individuals be stored in the system as an Employee or an External User, who are involved with your company, even people who will are not be able to access the system as a user.

...

,

...

be

...

As a background table, many other tables link to the information stored in one of the People subtables.

Use Case for External Users

External users may be created manually by guests and members of the Base ServiceDesk, Contract Manager, Customer Manager, Marketing, Project Manager, Sales, Business Admin,  and Admin groups. They may also be created as the result of a conversion from a Lead or Contract record, or may be created as part of an import from another database.

If a new external user is created (either directly or from a contract or contract party) and a login value is not entered, the system runs a rule to set the login to their email address (if they have one) and sets a default, unique password, but blanks out the default team. This allows the user to be recognized if they respond to an email from the system without actually giving them the ability to login to the system. This rule can be modified if you want such users to belong to a specific team so they can access the system through an end user portal.

Self-registration is available so that users can create their own logins, using the limited-access "register" account. Records created by the login of "register" are added to the Customer group and the Customer Team by default.

To create a link to permit self-registration, substitute the items in <brackets> below with the URL for your system, your KB Name, and the Exit URL you want to take users to:

https://<server-hostname>/gui2/login.jsp?KeyID=0&KB=<KB-name>&user=register&password=Register678&State=New:contacts.Customer&GUI=no/EUI&ExitURL=<yourpage>

This will allow the user to enter their contact information and then will log them out. They will not be able to choose from a list of companies, but instead will type in a company name. To see how this hyperlink is constructed, see Hyperlink Keywords and Examples.

When they save their user record, an email is sent to the 1st Level Support Team informing them that a contact has self-registered and asking them to validate the user's access and link them to the appropriate existing company in the system. This email template could be modified to send to anyone in your organization responsible for vetting users.

Use Case for Employees

Employees may be created in a variety of ways.

• A user with permission to create employees can add new employee records
• They can be automatically created via sync with Active Directory or LDAP or the first time they log in using one of those authentication methods
• They may also be created from a SAML provider, such as Okta, when they first log into the system
• They are often imported during implementation from an Excel or .csv spreadsheet

Once an employee is given access to the system, their user information can be modified in a variety of ways:

• An admin user can deactivate their access and update their information
• Sync with LDAP or AD can update information that has changed in some other system
• Scheduled import/updates from another backend system can update their information if it changes
• The user may modify any fields they are allowed to edit by clicking on My Profile in the Home section of the left pane

...

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:

• 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

Automation

The default automation on the employee subtable includes the following actions:

• If you are using Adobe Sign for e-signature, and the value in the Adobe Sign Sender field is set to or changes to Yes, a user account is automatically created for the user at Adobe Sign, so that they can send envelopes under their own name.
• If the value in the Adobe Sign Sender field changes from Yes to No, that account is automatically disabled at Adobe Sign.

See the Adobe Sign Tables and Setup section for more details.

There is another rule that handles document approval generation when an employee is identified as a reviewer on the Documents table. The rule runs down to the employee and generates the approval record from there.

Ownership of People Records

Employee and External User records are owned by the user whose login matches the Login field of the record. More simply, each Employee or External User owns their own record.