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's subtables. The People table is considered a top-level table, which simply means that it has subtables. The People table is one of the most, if not the most, prominent background table in any systemtables in  

...

Users 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 who are involved with your company be stored in the system as an Employee or an External User, , even people who are not be able to access the system as a user, like leads.

• The Employees subtable holds general employee information, like their role, primary team, and manager. It also holds personal information, like home address and phone number. In addition to the People and Employee tables, LDAP or Active Directory authentication can be used to create and update Employee user records.
• The External Users subtable holds information on non-employees who may or may not be users of the system. Each External User record includes fields that associate the user with a company, contracts, events, and other activities.

As a background table, many other tables use the information stored in the People table hierarchy. Nearly every other table in the system contains records with linked fields that link back to the People table hierarchy, making it incredibly vital to the system's overall functionality.

Use Case for Employees

Employee records can be created in a variety of ways:

• A user with permission to create Employee records can create them in either the People table or the Employee table directly
• Via sync with Active Directory or LDAP. The first time a user logs in using one of those authentication methods, an Employee record is generated for them
• From a SAML provider, such as Okta, when they first log into the system
• 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 make changes to their record, and do things such deactivate their access or update their information
• A sync with LDAP or AD
• Scheduled import/updates from another backend system
• The user may modify any fields they are allowed to edit by clicking on My Profile in the Home section of the left pane

...

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

Use Case for External Users

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

If a new External User record is created (either directly or from a contract or contract party) without a login value, the system runs a rule that:

• Sets the user's login value to to their email address
• Sets a default, unique password
• 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

Self-registration is available, and allows users to create their own logins using the limited-access "register" account. By default, records that are created with the "register" login are added to the Customer Group and the Customer Team.

To create a link to permit self-registration, substitute the items in <brackets> below with the URL of your system, your KB Name, and the Exit URL you want to take users to. Make sure to remove the brackets after adding your information.

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 link allows the user to enter their contact information, and then logs them out. Users are not be able to choose from a list of companies, but instead type in their company name manually. For more information on how this hyperlink is constructed, see Hyperlink Syntax and Examples.

When the user saves their record, an email is sent to the 1st Level Support Team informing them that a contact has self-registered. The email also asks them to validate the user's access, as well as link them to the appropriate company in the system. This email template can be modified, as well as sent to anyone in your organization who might be responsible for vetting new users.

Automation

The default automation in the Employees 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. This allows users to 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 Overview 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

...

• .