About Creating New Users and Employees

While it is possible to create non-employee users within the Siebel CRM application, most non-employee users are created by the actual user through self-registration. For example, a customer who wants to place an order through the sales application registers before being able to complete the order, or an existing customer creates an account the first time they log a service request. The process of self-registration and how to customize the user experience is documented in the Siebel Security Guide. This topic focuses only on creating new Employee records.

There are two high-level steps for creating an employee user:

• Setting the employee’s Siebel CRM attributes.

• Setting the employee’s authentication requirement.

On the Siebel CRM side, creating an employee user involves the following steps:

• To ensure the most flexible visibility scheme, Oracle recommends that each employee has a unique position. This is not a strict requirement for employees. It is required for sales users. It is also possible for service users to share positions. Adding a position provides for finer control over data visibility and there is no downside to creating a unique position for each user. The first step in creating a new Employee record is to first create a Position record.

• After creating Position records for each new employee, navigate to Site Map > Application > User > Employee.

• Create a record with the user's first name, last name, and a login name (this may be arbitrary or may be dictated by the authentication mechanism). While not required, it is strongly recommended that each employee have an email address, as this can be leveraged for integration with corporate mail systems such as Microsoft Exchange, as well as sending email from within Siebel CRM.

• Associate the Employee's Position and specify one or more Responsibilities.

Having completed these steps, Siebel CRM now considers the Employee a full-fledged user. This user can be associated to Siebel CRM objects, such as Accounts, Opportunities, Contacts, or Service Requests.

However, the user will not actually be able to log into Siebel CRM. The reason for this is that Siebel CRM does not provide a native method for authentication, but rather relies on external authentication mechanisms. These are described in detail in the Siebel Security Guide, but are summarized here:

• Database Authentication. When database authentication is configured, Siebel CRM passes the username and password provided by the user directly to the underlying database for authentication. If you use this mechanism, each user must be created in the database by the Database Administrator and have access to the Siebel CRM database objects, such as tables and indices.

  Note: This is not the recommended model because a user can connect directly to the database through a database-specific utility, such as SQL*Plus, and would be able to interact freely with the data in the database. This creates a potential security problem.
• LDAP Authentication. With LDAP authentication, Siebel CRM uses an external LDAP authentication authority to validate a user's login credentials. The advantage of this approach over Database Authentication is the following:

  • A user can use their same credentials across many systems that share a common LDAP authority.

  • Because users do not have direct database credentials, the security issue described with Database Authentication does not apply.

• SSO Authentication. SSO authentication is very similar to LDAP authentication in that an external authentication authority is used to validate the user's login credentials. The difference is that under SSO authentication, once a user has logged into any SSO-enabled application within the enterprise, the user is not required to login again as long as the browser is open. For example, consider the case where Siebel CRM shares an SSO authentication authority with two other systems, X and Y. When a user navigates to system X, he or she will be required to enter credentials. If that same user opens a new browser tab and navigates to Siebel CRM (or system Y), the user will not have to provide credentials a second time.

Regardless of the authentication mechanism in use, to allow the Employee User to have access to the Siebel CRM system, it will be necessary to provision the user in that authentication authority. In the case of Database Authentication, this would mean creating the user in the database. In the case of the other two authentication options, it would mean provisioning the user in that authentication authority and providing a mapping from that user to the Siebel CRM login. For example, mapping SSO user [e-mail] to Siebel CRM user JSMITH. For specifics relevant to your implementation, see the Siebel Security Guide.