Setting an empty value in either the Groups or the Primary team field will prevent the user from logging in, while preserving the history of what that user has done in the system.
The two subtables (Employees and External Users) of the people table are used to store information about individuals, including any associated Company or contact information. People may be external or internal to your company.
In this document, the terms "contact," "user," and "people"/"person" are used interchangeably.
People outside your company should generally go in 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, even people who will not be able to access the system as a user.
The External Users subtable stores external people who may or may not be users of the system. Each record includes fields to associate these users with companies, contracts, events, and other activities that relate to external users.
The Employees subtable holds information about company employees, like home address and working hours, which the External Users table does not. LDAP or Active Directory authentication can be used to create and update users in the Employees subtable.
As a background table, many other tables link to the information stored in one of the People subtables.
External users may be created manually by guests, Support Staff, and members of the Contract Management, Professional Services, Sales staff 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://\[your system hostname]/gui2/login.jsp?KeyID=0&KB=[your-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.
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 this activity.
Employees may be created in a variety of ways.
It is important to put employees on the right group and teams to control their access.
Once an employee is given access to the system, their user information can be modified in a variety of ways:
It is good to develop your own procedure for deactivating an employee who has been terminated. We do not recommend deleting users who leave the company.
Setting an empty value in either the Groups or the Primary team field will prevent the user from logging in, while preserving the history of what that user has done in the system.
The default automation on the employee sub-table includes the following actions:
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.
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 his own record.