User Administration

This chapter provides information about registering and administering users of Siebel employee, partner, and customer applications. It includes the following topics:

About User Registration

A user who is not a registered Siebel application user has no authenticated access to the Siebel database. Depending on the Siebel application, unregistered users have various levels of access. Minimally, the user can access a login page. By default, or by your configuration, unregistered users can have access to some or all of the views of a particular Siebel application.

You typically grant registered users more access to data and features than you grant unregistered users. A user can be registered for some or for all of your Siebel Business Applications. You can grant different registered users different levels of access to the database and features.

Typically, a user is registered when the following tasks are performed:

Create a user record in the Siebel database.
Provide the means for the user to be authenticated at login.

Depending on the Siebel application, a user can be registered in one or more of the following ways:

Self-registration. The user can self-register at the Web site.
Internal registration. An administrator at your company can register users.
External registration. A delegated administrator (a user at a customer or partner company) can register users.

If you implement an external authentication system, then adding a user to the Siebel database, whether by self-registration or by an administrator, might or might not propagate the user’s login data to the external authentication system. If the login credentials do not propagate to the authentication system, then you must create the login credentials separately in the authentication system.

If you implement database authentication, then adding the user to the database, with the user ID and password, is enough to allow this user to be authenticated. For more information about authentication and propagation of user data, see Security Adapter Authentication.

Requirements for User Registration

You must complete the following implementations before you can register users:

Install your Siebel Business Applications.
Set up and configure your user authentication architecture.
Create database accounts for users, as required by your authentication architecture.

Seed Data for User Registration

When you install your Siebel Business Applications, you are provided seed data that is related to user registration, user authentication, and user access to Siebel Business Applications. The seed data includes users, responsibilities, positions, an organization, and a database login. References to the seed data appear throughout this chapter. For detailed information on seed data and for procedures for viewing and editing seed data, see Seed Data.

About Anonymous Browsing

This topic provides information about anonymous browsing. Several Siebel Business Applications allow anonymous browsing of views intended for public access as default functionality. Anonymous browsing typically applies to Siebel customer and partner applications, not employee applications. However, you can configure any Siebel application to either allow or disallow anonymous browsing.

Unregistered users gain access to application views and the database through the anonymous user. The anonymous user is a record in the Siebel database that also performs functions during user authentication and user self-registration. If you implement an external authentication system, then the anonymous user has a corresponding record in the user directory.

The anonymous user session caches information so any changes to data, for example, catalogs, is not updated until either the user logs in or the anonymous user session is restarted.

For information about the anonymous user’s role in user authentication, see Configuring the Anonymous User. For information on implementing anonymous browsing, see Process of Implementing Anonymous Browsing.

Process of Implementing Anonymous Browsing

To implement anonymous browsing so that Siebel views are accessible to unregistered users, you must perform the following tasks:

For Siebel Business Applications for which anonymous browsing is implemented by default, confirm that these tasks have been completed.

Anonymous Browsing and the Anonymous User Record

This topic describes the modifications you might have to make to the anonymous user record when you implement anonymous browsing. For additional information on the anonymous user, see Configuring the Anonymous User.

This task is a step in Process of Implementing Anonymous Browsing.

The anonymous user is a record in the Siebel database and, if you implement external user authentication, a corresponding record in the external directory of users. The anonymous user is a component in user authentication, anonymous browsing, and self-registration. For applications that allow anonymous browsing, the anonymous user provides visibility of the pages for which you allow anonymous browsing.

Before implementing anonymous browsing, check that:

An anonymous user record exists in your Siebel database and external directory.
In general, you will have set up your user authentication architecture before configuring an application for user access so the anonymous user will already exist in your Siebel database and in your directory. For information, see Configuring the Anonymous User.
The anonymous user record is assigned appropriate responsibilities.
The responsibility that is assigned to a user record in the database contains a list of views to which the user has access. You must confirm that the anonymous user used for your Siebel Business Application includes an appropriate responsibility so that unregistered users can see the views you intend them to see.

If you choose to use a seed anonymous user in your authentication setup, then verify that its seed responsibility includes the views you want to provide for anonymous browsing. For example, if you use the GUESTCST seed user for a Siebel customer application, then verify that its responsibility, Web Anonymous User, includes the required views.

If the responsibility does not include your required views, then do one of the following:

Create one or more additional responsibilities that include missing views, and then add these responsibilities to the existing seed responsibility in the anonymous user’s Responsibility field. The user has access to all the views in all the assigned responsibilities. For information about creating a responsibility or adding views to a responsibility, see Configuring Access Control.
Copy the seed responsibility record, add missing views to the copy, and replace the responsibility in the anonymous user record with the modified responsibility.

Note: You cannot directly modify a seed responsibility.

Setting Configuration Parameters for Anonymous Browsing

This topic describes the configuration parameters you must set to enable anonymous browsing.

This task is a step in Process of Implementing Anonymous Browsing.

Perform the steps in the following procedure to implement anonymous browsing.

To set configuration parameters for anonymous browsing

For a Siebel Web Client deployment, set the AllowAnonUsers parameter to TRUE for the applicable Application Object Manager component as follows:
1. Navigate to the Administration - Server Configuration screen, then the Servers view.
2. In the Siebel Servers applet, select the relevant Siebel Server, then click the Components tab.
3. Select the applicable component, for example, Call Center Object Manager, then click the Parameters tab.
4. In the Component Parameters applet, locate the AllowAnonUsers parameter and set the Value to True.
  If this parameter is FALSE, then unregistered users are not allowed access to the Siebel application.
In the Siebel Application Interface profile, set the following parameters:
- Anonymous User Name
  This is the user name for the anonymous user. It is stored in the directory and also in the Siebel database. The anonymous user provides binding between the directory and the Application Object Manager to allow a Siebel application home page to display to a user who has not logged in. Similarly, this anonymous user supplies a login so the user can see other pages for which you allow anonymous browsing.
  
  Caution: Specify the name of a restricted user for the Anonymous User Name parameter. Do not specify system administrator (SADMIN) as the Anonymous User Name; doing so allows anonymous users to access every part of the Siebel system.
- Anonymous User Password
  This is the authenticated password that is paired with the Anonymous User Name parameter.
For more information on setting parameter values in the Siebel Application Interface profile, see Siebel Application Interface Profile Parameters.

Configuring Views for Anonymous Browsing or Explicit Login

This topic describes how to configure views for anonymous browsing.

This task is a step in Process of Implementing Anonymous Browsing.

When a view is included in the responsibility for the anonymous user, the view is still not accessible to unregistered users if the view is designated for explicit login. A view that is designated for explicit login requires the viewer to be a registered user who has been authenticated.

The following procedure outlines the general steps you must perform in Siebel Tools to allow a view to be accessible to anonymous users. For detailed information about modifying view properties in Siebel Tools, see Configuring Siebel Business Applications.

To remove the explicit login requirement for a view

Open Siebel Tools.
Select Tools, and then Lock Project.
In Object Explorer, select the View object type.
The Views list appears.
Select a view.
For each view, set the Explicit Login property to FALSE to allow the view to be available for anonymous browsing.
Set the Explicit Login property to TRUE if only registered users are to have access to the view.
Update the repository and deliver the updates, then unlock the project.

About Self-Registration

Several Siebel Business Applications allow users to self-register as default functionality. This topic observes the following principles about self-registration functionality that is provided by default with your Siebel Business Applications:

Self-registration applies to Siebel customer and partner applications.
You can configure any eligible Siebel application to either allow or disallow self-registration.
You can implement Lightweight Directory Access Protocol (LDAP) security adapter authentication with Siebel Business Applications for which you allow self-registration.

To implement self-registration for applications that use Web SSO user authentication, you are responsible for configuring the self-registration functionality at the Web site level and for synchronizing the user data with the Siebel database. Configuration guidelines are not provided in Siebel Business Applications documentation. Self-registration is not feasible when you implement database authentication.

Note: If you implement an adapter-defined user name in your user authentication environment, then you cannot implement tools that allow users’ Siebel user IDs stored in the directory to be managed from within Siebel Business Applications, including user self-registration. For information about user authentication, see Security Adapter Authentication.

User Experience for Self-Registration

Self-registration functionality is available with several Siebel Business Applications. The self-registration experience for end users varies, depending on the application. Some application-specific capabilities are:

Siebel eService. A user self-registers to gain access to more services.
Siebel Sales. A user self-registers to be allowed to make an online purchase.
Siebel Partner Portal. A user self-registers as an individual to become a partner user with limited access, or a user self-registers as a request for his or her company to be approved as a partner. In either case the user is assigned a limited responsibility that contains views to master data, but not to transactional data. This responsibility differs from that for a partner user in an approved partner company.
For more information on registering partners and partner users for Siebel Partner Portal, see Siebel Partner Relationship Management Administration Guide.

To self-register

The user clicks New User on a Siebel application page, for example, the Siebel eService home page.
The Personal Information form appears.

The user completes the form, then clicks Next. For example, fields for Siebel eService are shown in the following table.

Field	Guideline
First Name	Required. Enter any name.
Last Name	Required. Enter any name.
Email	Required. Enter any valid email address.
Time Zone	Required. Specify the time zone.
User ID	Required. Enter a simple contiguous user ID, which must be unique for each user. Typically, the user provides this user ID to log in. Depending on how you configure authentication, the user might or might not log in with this identifier.
Password	Optional (required for some authentication implementations). Enter a simple contiguous login password. The password must conform to the syntax requirements of your authentication system, but it is not checked for conformity in this form. For LDAP security adapter authentication, the password is propagated to the user directory. For database authentication, the password is propagated to the database.
Verify Password	Required when Password is required.
Challenge Question	Required. The user enters a phrase for which there is an answer typically known only to this user. If the user clicks Forgot Your Password?, then this phrase is displayed, and the user must enter the correct answer to receive a new password.
Answer to Challenge Question	Required. The user provides a word or phrase that is considered the correct answer to the challenge question.

The Contact Information form appears. The fields on this form vary depending on the application.

The user completes the Contact Information form, and then clicks a button at the end of the form to continue. The names and number of buttons vary depending on the application.
If the application is Siebel Partner Portal or Siebel Sales, then the user does one of the following:
- A user who self-registers for Siebel Partner Portal chooses to register as an individual or to request that his or her company be approved to become a partner. In either case, the user completes a form requiring company information.
- A user who self-registers for Siebel Sales completes forms to provide, for example, payment information and address information.
On the Usage Terms form, the user must agree to the terms of the license agreement to be registered.
The Registration Confirmation message appears.

Process of Implementing Self-Registration

This topic describes the tasks involved in implementing user self-registration.

Self-registration comprises several components, as follows:

Siebel seed workflow processes provide a sequence of interactive forms to the user for collecting the new user’s data. These processes also validate data and write much of the data to the new User record in the Siebel database.
Some fields in the new User record in the database are populated automatically from fields in the anonymous user record.
A new record is created in the user directory. The security adapter authenticates the user against this record. Fields are populated automatically from the data the user enters to the forms.

Perform the following tasks to implement self-registration:

Self-Registration and the Anonymous User Record

This topic describes the modifications you might have to make to the anonymous user record when you implement self-registration. For additional information on the anonymous user, see Configuring the Anonymous User.

This task is a step in Process of Implementing Self-Registration.

Before implementing self-registration, verify that:

An anonymous user record exists in your Siebel database and external directory.
The New Responsibility field of your anonymous user provides all the views you require for self-registering users.

Different Siebel Business Applications in the same implementation can use different anonymous users. Two Siebel application user records, identified by their user IDs, GUESTCST and GUESTCP, are provided as seed data for use as anonymous users. Seed Data describes seed data users, responsibilities, and the Siebel Business Applications for which they are designed.

When a user self-registers, a new record is created in the User Registration business component. The User Registration business component is based on the same tables as the User business component, so a new User record is essentially created.

Note: When a user self-registers through partner applications, such as Siebel Partner Portal, data is also written to the Contact business component (or equivalent).

The following key fields are populated automatically from fields in the anonymous user’s record in the Siebel database:

Responsibility. The new user’s responsibility is inherited from the anonymous user’s New Responsibility field. A user’s responsibility determines the list of views to which the user has access.
New Responsibility. The new user’s New Responsibility field value is also inherited from the anonymous user’s New Responsibility field. The New Responsibility field is not used by regular registered users. Several Siebel Business Applications allow customer or partner users to be upgraded to delegated administrators. A delegated administrator can register other users, who inherit their responsibility from the delegated administrator’s New Responsibility field.

The New Responsibility field is a single-value field. Therefore, if the seed responsibility in the New Responsibility field of your anonymous user does not provide all the views you require for self-registering users, then do one of the following:

Replace the New Responsibility value with a responsibility you create.
Copy the seed responsibility record, add missing views to the copy, and replace the New Responsibility with the modified responsibility.

Note: You cannot directly modify a seed responsibility.

For information about creating a responsibility or adding views to a responsibility, see Configuring Access Control.

Setting the Propagate Change Parameter for Self-Registration

This topic describes the Siebel Propagate Change parameter. Setting the Propagate Change parameter to True simplifies user administration when you implement user self-registration.

This task is a step in Process of Implementing Self-Registration.

The user directory can be administered through Siebel Business Applications if you implement security adapter authentication. Changes such as adding a user, or changing a password by an internal administrator, a delegated administrator, or when a user self-registers, are propagated to the user directory.

Set the Propagate Change parameter to True for the security adapter so that user data, including user name and password, propagate to the user directory when users self-register from the Siebel Web Client.

To set the Propagate Change parameter to True

In a Siebel employee application, such as Siebel Call Center, navigate to the Administration - Server Configuration screen, then the Profile Configuration view.
Select LDAP Security Adapter.
In the Profile Parameters applet, set the Propagate Change parameter to True.

For additional information about setting the Propagate Change parameter, see Server Parameters for Siebel Gateway.

Note: If you do not configure your security adapter authentication architecture to allow administration through the Siebel Web Client as described here, then you must manually create a record in the user directory when a new user is created in the Siebel database.

About Activating Workflow Processes for Self-Registration

When you install Siebel Business Applications, you are provided with several workflow processes that control self-registration. For the self-registration workflow processes to be invoked, you must set the workflows to have a status of Active. For information about how to activate workflow processes, see Siebel Business Process Framework: Workflow Guide.

This task is a step in Process of Implementing Self-Registration.

About the Self-Registration Workflow Processes

The self-registration workflow processes together present a sequence of forms for the user to complete. They perform data validation, and they invoke database operations. The self-registration workflow processes which you must activate are as follows:

User Registration Initial Process. For purposes of self-registration, this process is invoked when a user clicks New User on the login form or clicks Check Out during the buying process in Siebel Sales. This process is also invoked by clicking Forgot Your Password? on the login form. The process branches to one of the following subprocesses:
- User Registration Process
- User Registration Forgot Password Process
User Registration Process. This is the main self-registration process. It updates the database, including:
- Creating a new User record
- Checking for a duplicate User record
- Updating the existing User record with new information if a duplicate record is found
User Registration SubProcess. This process is a subprocess to User Registration Process. It performs all of the information gathering and validation. The validated information includes:
- A duplicate user ID does not exist in the database
- The Password and Verify Password entries are identical
- All required fields are completed

The registration workflow processes branch at various stages depending on the following:

The application is Siebel Partner Portal
The application is other than Siebel Partner Portal
This is the default case, and it includes Siebel Sales, Siebel eService, Siebel Customer, Siebel Training, Siebel Events, and Siebel Marketing.

About the Self-Registration Workflow Process Views

The following table lists the views specified in the workflow processes that provide interactive forms during self-registration.

Table Self-Registration Workflow Views

View Name	Applications Using This View	Description
VBC User Registration Initial Form View VBC User Registration Password Error Msg View VBC User Registration Missing Info Msg View VBC User Registration Legal Confirmation View VBC User Registration Login Error Msg View VBC User Registration Confirmation Msg View VBC User Registration Declined View VBC User Registration Create User Error Msg View VBC User Registration Security Setup Error Msg View	All	These views, common to all applications that use the User Registration Process, comprise two groups: Personal Information form and messages resulting from flawed entries or a duplicate user ID with an existing user record. Usage Terms form and messages resulting from accepting or declining to agree.
VBC User Registration Contact Information View	Default	This view is the Contact Information form used by default.
VBC User Registration Company Information - Company View (SCW) VBC User Registration Company Information - Individual View (SCW) VBC User Registration Contact Information View (SCW)	Siebel Partner Portal	These views collect contact information and information about the user’s company.

View Name

Applications Using This View

Description

VBC User Registration Initial Form View

VBC User Registration Password Error Msg View

VBC User Registration Missing Info Msg View

VBC User Registration Legal Confirmation View

VBC User Registration Login Error Msg View

VBC User Registration Confirmation Msg View

VBC User Registration Declined View

VBC User Registration Create User Error Msg View

VBC User Registration Security Setup Error Msg View

All

These views, common to all applications that use the User Registration Process, comprise two groups:

Personal Information form and messages resulting from flawed entries or a duplicate user ID with an existing user record.

Usage Terms form and messages resulting from accepting or declining to agree.

VBC User Registration Contact Information View

Default

This view is the Contact Information form used by default.

VBC User Registration Company Information - Company View (SCW)

VBC User Registration Company Information - Individual View (SCW)

VBC User Registration Contact Information View (SCW)

Siebel Partner Portal

These views collect contact information and information about the user’s company.

(Optional) Modifying Self-Registration Views and Workflows

You can modify existing views in a self-registration workflow process or create new views as required. You can also modify the seed workflow processes that are used for self-registration.

This task is an optional step in Process of Implementing Self-Registration.

You can modify the default self-registration functionality in several ways. See the following topics for additional information:

Modifying self-registration views, applets, and workflow processes include standard processes common with modifying other views, applets, and workflow processes.

The views used in the self-registration workflow processes are based on the VBC User Registration virtual business component, which collects the user data. The data is written to the User Registration business component and the Siebel database only when all stages of collecting user data are completed. Before you make any modifications, you must understand how these components handle the user data.

The User Registration and User business components are both based on the same database tables: S_PARTY, S_CONTACT, and S_USER. Therefore, writing a record through the User Registration business component is equivalent to writing a record through the User business component. In either case, a new user is created.

The user-registration process provides the following benefits:

If the self-registration process is terminated before completion, then it is not necessary to perform the time-consuming process of undoing a new, partially written record in the database. This process requires searching several tables.
User record duplication can be prevented before a record is written.

Replacing the License Agreement Text

You can replace the default license agreement that appears to the self-registering user in the User Registration Legal Confirmation View.

The DotCom Applet License Base 1 Column Web template includes the Web template file with the name DotCom Applet Form Base 1 Column, which is the file of name dCCAppletLicenseBase1Col.swt. The license agreement is contained in the dCCAppletLicenseBase1Col.swt file, following the phrasing: . You can replace the license agreement text. For information about working with Web templates, see Configuring Siebel Business Applications.

About Revising a Workflow Process

The self-registration workflow processes for your business scenario might require that you do revisions to the seed self-registration workflow processes, such as:

Replace or insert a view
Insert or delete a step
Modify a step

You cannot directly modify a seed workflow process, such as any of the self-registration processes. Instead, you must create a copy of the process, and then revise the copy.

By convention, to avoid renaming processes, you can use the Revise button to make a copy of the same name, but with an incremented version number. All other processes of the same name are assigned Outdated status, so that the new version can be the only active version. This convention is recommended for revising any workflow process, not just seed processes. For information about how to view, revise, activate, and deploy workflow processes, see Siebel Business Process Framework: Workflow Guide.

Custom Business Services

Siebel Business Applications provides predefined business services that you can use in a step of a workflow process. You can also script your own custom business services and then run them in workflow process steps. For information about predefined business services and creating business services, see Configuring Siebel Business Applications. For information about running business services in workflow processes, see Siebel Business Process Framework: Workflow Guide.

Redefining Required Fields

As default functionality, a user who is self-registering is required to provide entries in certain fields. These fields might differ depending on the application. A required field is indicated in the user interface by an asterisk (a star icon), where the field appears in a form.

For a view used in the self-registration workflow processes, you can change whether a field is required. Use Siebel Tools to determine the view that includes a self-registration field. For information about how to view, revise, activate, and deploy workflow processes, see Siebel Business Process Framework: Workflow Guide.

The CSSSWEFrameUserRegistration frame class is applied to applets that are used in views that appear in the seed self-registration workflow processes. This class allows you to specify required self-registration fields.

To designate a required field in a self-registration form, use Siebel Tools to modify the applet that contains the form. The following procedure is intended to present the main steps in a Siebel Tools task. For detailed information about working with applets and views in Siebel Tools, see Configuring Siebel Business Applications.

To designate a required field in a self-registration form

Open Siebel Tools.
Lock the User Registration project.
In Object Explorer, expand the View object type.
The Views list appears.
Select a view that includes a self-registration field.
In Object Explorer, expand the View Web Template child object type, and then expand its child, View Web Template Item.
Self-registration views typically contain a single form applet. It is listed in the View Web Template Items list.
In the View Web Template Items list, drill down on the link in the Applet field for the single applet that is listed. If there is more than one applet listed, then drill down on the one you think is most likely to contain the field you are looking for.
The Applets list appears with one record, the applet you drilled down on.
In the Object Explorer, expand the Applet object type, and then expand the Control child object type.
The Controls list appears after the Applets list.
In the Controls list, select the record whose Caption field is the name displayed in the user interface for the field you want to require users to complete. Record the value that appears in the Name column, for example, MiddleName.
In Object Explorer, click the Applet User Prop object type.
The Applet User Properties list displays the user properties for the applet in the Applets list.
With the Applet User Properties list active, choose Edit, and then New Record.
A new user property record appears.

Complete the following fields. Use the indicated guidelines.

Field	Guideline
Name	Required. Enter `Show Required` and a sequence number one greater than the highest existing sequence number. For example, if Show Required 6 is the highest sequenced entry, then enter `Show Required 7`. This entry is case-sensitive.
Value	Required. The name of the field that you recorded earlier in this procedure, such as MiddleName.

Update the repository and deliver the updates, then unlock the User Registration project.
When viewed in the self-registration interface, the new required field has an asterisk (a star icon) beside it.

Note: To make a required field no longer required in the user interface, follow the steps in the preceding procedures, with the following exception: in the Applet User Properties list, either check the Inactive column for the record you added, or delete the record.

Adding or Deleting Fields in an Existing View

All the data collected in views used in the seed self-registration workflow processes are written to fields in the User Registration business component. The following process describes how data is collected in the user interface and written to a user’s record in the database:

The user enters data, such as the user’s last name, into a text box on a form.
The text box is mapped to a field in the VBC User Registration virtual business component, such as LastName. Consequently, the data is written to that field.
Data from the virtual business component VBC User Registration is written to the User Registration business component. The User Registration business component writes to the same database tables as the User business component. Consequently, each field is actually stored as part of a user record.

Note: No data from the VBC User Registration virtual business component is written to the User Registration business component fields until the self-registration process is complete.

To add or delete fields in a view used in a self-registration workflow process, you must perform Siebel Tools tasks and then Siebel Workflow tasks (using Business Process Designer in Siebel Tools).

To add a field to one of the views used in the self-registration workflow processes, you must use Siebel Tools to do one or more steps of the following procedure. This procedure is intended to identify the major tasks required. For detailed information about modifying views and applets, see Configuring Siebel Business Applications.

To add a field to a view used in a self-registration workflow process

Open Siebel Tools.
Lock the User Registration project.
Determine the business component and the underlying database table on which the new field is based.
If the new field is not based on an existing database table column, then define a column on an extension table of the appropriate table.
Create a new field, based on the new or existing table column, in the appropriate business component.
If the new field is based on the User Registration business component, then create a new field in the VBC User Registration virtual business component. Use the exact same field name.
Configure the appropriate applet to display the new field in the user interface.
If necessary, configure the new field so that a self-registering user is required to complete it.
Update the repository and deliver the updates, then unlock the User Registration project.

Note: To remove a field from the self-registration user interface, you do not have to delete the field from the applet in which it appears. Instead, configure the applet so that the field is not displayed in the user interface.

About Changing the Physical Appearance of a View or Applet

For information about changing the physical appearance of a view or applet, such as moving fields or changing colors, see Configuring Siebel Business Applications.

About Creating a New View for Self-Registration

You create a new view for insertion into one of the self-registration workflow processes in the same way you create a view for any other purpose.

You can include new applets in a view that you create that you include in a self-registration workflow process. You create the new applet and include it in the view in the same way as you would for any other purpose. However, if you base the applet on the User Registration business component, then apply the CSSSWEFrameUserRegistration class to the applet. This allows you to define fields for which an asterisk (a star icon) displays in the user interface. By convention, fields that you require users to complete during the self-registration process have an asterisk (a star icon). For information about working with views, see Configuring Siebel Business Applications.

(Optional) Managing Duplicate Users

When a user self-registers, the User Registration Process workflow process attempts to determine whether the user already exists in the database. User deduplication is a default feature, and it is configurable.

This task is an optional step in Process of Implementing Self-Registration.

As default functionality, if all of the following non-null field values entered by the self-registering user match those for an existing user, the users are considered to be the same person.

First name
Last name
Email address

If the self-registering user is a match of an existing user, then the existing User record is updated instead of a new User record being written. If the value in a field of the existing User record differs from the self-registering user’s non-null entry, then the existing field is updated with the new data. All other existing field values remain unchanged.

In the User Registration SubProcess workflow process, the duplication comparison is done by the ValidateContact method in the User Registration business service. The comparison is done by the Check User Key step.

Modifying Updated Fields for a Duplicate User

You can specify that certain fields in the User Registration business component are not updated when a duplicate user is determined.

The following procedure is intended to list the major steps you must do. For detailed information about doing any step, see Configuring Siebel Business Applications.

To exclude a field from being updated when a duplicate user is determined

Open Siebel Tools.
Lock the User Registration project.
Determine the field in the VBC User Registration virtual business component that you want to exclude from updating.
1. In the Object Explorer, click Business Component.
2. In the Business Components list, select the VBC User Registration business component.
3. In the Object Explorer, expand the Business Component item, then select the Field child item.
4. In the Fields list, query or scroll to select the field you want to exclude.

Add the appropriate business service user property.

In the Object Explorer, click Business Service.
In the Business Services list, select the User Registration business service.
In the Object Explorer, expand the Business Service item, then select the Business Service User Prop child item.
In the Business Service User Props list, create a new record.

Complete only the fields listed. Use the indicated guidelines.

Field	Guideline
Name	Enter `Exclude From Update` number, where `number` is the next number in the sequence for this particular user property. For example, enter `Exclude From Update 3`. This entry is case-sensitive.
Value	Enter the field name from the VBC User Registration virtual business component that you noted earlier in this procedure.

Update the repository and deliver the updates, then unlock the User Registration project.

Modifying Fields Used to Determine a Duplicate User

You can change the fields that are used to determine whether a duplicate user exists.

The following procedure is intended to list the major steps you must perform to modify the fields used to determine a duplicate user. For detailed information about performing any step, see Configuring Siebel Business Applications.

To modify the fields used to determine a duplicate user

Open Siebel Tools.
Lock the User Registration project.
Determine the fields in the User Registration business component that you want to add or delete from the duplication comparison.
1. In the Object Explorer, expand Business Component, and then expand its Field child.
2. In the Business Component list, select the User Registration business component.
In the Object Explorer, expand Business Service, and then click on its Business Service User Properties child.
The Business Services list and the Business Service User Properties child list appear.
In the Business Services list, select User Registration.
Delete a field from the duplication comparison:
1. In the Business Service User Properties list, select the record with name App User Key: Default number or App User Key: Siebel eChannel number (for Siebel Partner Portal) whose value is the User Registration business component field you want to delete from the comparison.
2. Click to put a check in the Inactive field, and then commit the record.

Add a field to the duplication comparison:

In the Business Service User Properties, create a new record.

Enter only the fields listed in the following table. Use the indicated guidelines.

Field	Guideline
Name	Enter `App User Key: Default` number or `App User Key:` application number, where application is the name of the Siebel application, and number is the next number in the sequence for this particular user property. This entry is case-sensitive. For example, you might enter `App User Key: Default 2` to add a field for Siebel eService, or `App User Key: Siebel eChannel 4` to add a field for Siebel Partner Portal.
Value	Enter the name of the field in the User Registration business component that you want to add to the duplication check.

Field

Guideline

Name

Enter App User Key: Default number or App User Key: application number, where application is the name of the Siebel application, and number is the next number in the sequence for this particular user property. This entry is case-sensitive.

For example, you might enter App User Key: Default 2 to add a field for Siebel eService, or App User Key: Siebel eChannel 4 to add a field for Siebel Partner Portal.

Value

Enter the name of the field in the User Registration business component that you want to add to the duplication check.

Update the repository and deliver the updates, then unlock the User Registration project.

Deactivating the Duplicate User Check

You can deactivate the duplicate user check.The following procedure is intended to show the main steps in deactivating the duplication check. For more detailed information on working with workflow processes, see Siebel Business Process Framework: Workflow Guide.

To deactivate the self-registration deduplication check

In Siebel Tools, select Workflow Process in the Object Editor.
Query or scroll to select User Registration SubProcess.
Create a revised copy of User Registration SubProcess.
For information, see (Optional) Modifying Self-Registration Views and Workflows.
Right-click and choose Edit Workflow Process to edit the revised copy.
The Process Designer appears, showing the current workflow process.
For each process step that applies to your application, record the sources of all connectors to the step and the destination of the single connector from the step. Reroute the connectors to bypass the step. For all Siebel Business Applications, choose the Check User Key step.
Delete the bypassed process step, which is no longer the source or destination of any connector.
Right-click and choose All Processes.
The Workflow Processes list appears again. The revised process is still selected.
Click Deploy.

Identifying Disruptive Workflows

This topic describes how to identify workflows that are interfering with the user registration process. Once identified, these workflows can be deactivated allowing the user registration process to proceed.

This task is part of Troubleshooting User Registration Issues.

If nothing happens when a user clicks Next in a User Registration view, then verify that the workflow processes that control self-registration are activated. For information on this task, see About Activating Workflow Processes for Self-Registration. If the appropriate workflows are activated, then the problem might be caused by a disruptive workflow. The following procedure describes how to identify and locate workflows that are disrupting the user registration process so that they can be deactivated.

To locate a disruptive workflow

In the Administration - Runtime Events screen, click the Events view.
Query for Object Name is null.
If there are no disruptive workflows, then only application type events are returned. Take note of any record whose Action Set Name value begins with Workflow. Such a record indicates that the workflow is triggered every time the event specified in the Event field happens. This can be particularly disruptive if the event is common, such as ShowApplet or WriteRecord. The Object Name normally constrains the actions to trigger only when the specified event occurs within the context of the object; for example, a specific business component or applet.
If there is a suspicious Event, then drill down on the Action Set Name and note the ID following the string ProcessId in the Business Service Context field.
Query against the database to find the suspect workflow. Use a query similar to the following:
```
select NAME from S_WF_STEP where ROW_ID='xxx'
```
where xxx is the ID noted earlier in this procedure.
The workflow returned in the query is the disruptive one. Deactivate it.

About Managing Forgotten Passwords

This topic describes how to manage forgotten passwords. If a user who has previously self-registered on a Siebel customer or partner application forgets his or her password, then the user can get a new password by clicking the Forgot Your Password? link in the login dialog box.

Note: Forgot Your Password? is a default feature of Siebel customer and partner applications, but it is available only if you implement LDAP security adapter authentication. To implement similar functionality in a Web SSO environment, you are responsible for configuring the functionality in your external authentication application, in your user directory, and in your security adapter. Consult your third-party vendor documentation for information about performing these tasks.

You can optionally configure the Forgot Your Password? feature in a number of ways:

You can specify the minimum and maximum length of the new password that a user can retrieve as described in Defining Password Length for Retrieved Passwords.
You can amend the forgotten passwords workflow process to change:
- The way in which the user identification data is compared with database user records.
- The identification data requested from users.
For information on both these tasks, see Modifying Workflow Process to Request Different Identification Data.

For additional information about managing forgotten passwords, see also the following topics:

Retrieving a Forgotten Password (Users)

This topic describes how users, who have previously self-registered, can create new passwords if they have forgotten their existing password. On a future login, users can change new passwords in the User Profile view.

The following procedure describes the steps involved in retrieving a new password.

To retrieve a new password

In the login dialog box, the user clicks Forgot Your Password?
The User Information form appears.
The user completes all fields of the form, and then clicks Submit.
- The database comparisons done with the Last Name field and First Name field entries are case-sensitive.
- The Work Phone # entry numbers are compared with the database. The comparison disregards any separators.
If a matching record is found, then the Challenge Question form appears.
The user enters the answer to the challenge question.
If the challenge question is answered correctly, then the user is prompted to enter a new password, and then to reenter the password to confirm it.
Provided that the passwords match and do not violate the requirements for passwords set by the directory server, the new password is set for the user.
Click Continue.

Defining Password Length for Retrieved Passwords

This topic describes how to configure the length of new passwords retrieved by users who have previously self-registered but who have forgotten their password. For information on the forgotten password feature, see About Managing Forgotten Passwords and Retrieving a Forgotten Password (Users).

To make sure that passwords conform to your company’s policy on password length, you can specify minimum and maximum character lengths for passwords by adding two user properties to the User Registration business service in Siebel Tools. These user properties are RandPassMinLength and RandPassMaxLength. When a user requests a new password using the Forgot Your Password feature, the User Registration business service invokes the SetPassword method to create the new password after verifying that the password meets the password length requirements defined for these two properties.

To define minimum and maximum values for password length

Open Siebel Tools and, in the Object Explorer, click Business Service.
The Business Services list appears.
In the Business Services list, query or scroll to select the User Registration business service.
Choose Tools, and then Lock Project.
In the Object Explorer, click Business Service User Props.
The Business Service User Props list appears.
Right-click in the Business Service User Props list and select New Record from the displayed context menu.
A new record field appears.

Complete the fields for the new record, as shown in the following table.

In this field...	Enter...
Name	RandPassMinLength
Value	Enter the minimum number of characters that your company’s password policy states a password must contain. The default value is 5.

In this field...

Enter...

Name

RandPassMinLength

Value

Enter the minimum number of characters that your company’s password policy states a password must contain.

The default value is 5.

This defines the minimum number of characters that a password can contain.

Step off the record to save changes.

Repeat the three preceding steps, with modifications for completing the fields in the record, as shown in the following table.

In this field...	Enter...
Name	RandPassMaxLength
Value	Enter the maximum number of characters that your company’s password policy states a password must contain. The default value is 15.

In this field...

Enter...

Name

RandPassMaxLength

Value

Enter the maximum number of characters that your company’s password policy states a password must contain.

The default value is 15.

This defines the maximum number of characters that a password can contain.

Update the repository and deliver the updates, then unlock the User Registration project.

Architecture for Forgotten Passwords

Forgot Your Password? is implemented in the User Registration Forgot Password Process workflow process. This process is a subprocess in User Registration Initial Process.

As described in Retrieving a Forgotten Password (Users), to receive a new password, the user must provide identification data that is compared with database user records. If all four fields return a case-sensitive match with an existing record, then the user must answer the challenge question associated with that record. The challenge answer must also return a case-sensitive match.

When a user enters values to the comparison fields in the user interface, the values are written to fields in the User Registration business component. This business component is based on the same tables as the User business component. The virtual field values are not written to the database, but are compared with field values in those underlying tables.

The user entries in the following fields in the user interface are compared with field values in the tables indicated:

The Last Name, First Name, Email, and Work Phone # fields are compared with S_CONTACT field values.
The Challenge Answer field is compared with an S_USER field value.

The User Registration Forgot Password Process workflow process uses the following views:

User Registration Forget Pwd Challenge Answer Error View
User Registration Forgot Pwd Error View
User Registration Forgot Pwd Invalid Error View
User Registration Forgot Pwd Reset Confirm View
User Registration Pwd Info View
User Registration Pwd Nomatch View
User Registration Forget Pwd Challenge Ques View

About Modifying the Workflow Process for Forgotten Passwords

You can modify the User Registration Forgot Password Process workflow process in the following ways:

Make a comparison of null fields as well as fields for which the user has provided a value
For information on this task, see Modifying Workflow Process to Query Null Fields.
Request different identification data from the user
For information on this task, see Modifying Workflow Process to Request Different Identification Data.

In the User Registration Forgot Password Process workflow process, the Query User step invokes the FindContact method of the User Registration business service. This method queries the database for user records whose data matches the identification data provided by the user. If the query returns a unique record, then the user can prove he or she owns the record by answering the challenge question.

The following table describes the arguments for the FindContact method.

Table Find Contact Method Arguments

List	Records	Comments About Values
Input Arguments	EmailAddress FirstName LastName WorkPhoneNum	The Input Argument field values are the field names in the User Registration business component that the FindContact business service queries for a match. The comparison is made with the process property values given in the Property Name field. These process properties collect the entries made by the user.
Output Field: Id Output Field: Login Name	As given by the Input Argument field values, the FindContact method is requested to return the Id and Login Name field values for each user record whose field values match the entries by the user. A temporary table of values is defined in which the rows are the records returned and the columns are given by the Value field values. One row of the temporary table contains the ID for a returned record in the Id column and the record’s Login Name in the Login Name column.
Output Arguments	Login Name Siebel Operation Object Id RegError	Each Property Name field value is a process property name. The Login Name and Siebel Operation Object Id process properties receive values if FindContact returns a unique matching record. If a unique record is not determined that matches the criteria, then RegError receives an error value. Siebel Operation Object Id is used to identify the user record for subsequent operations in the workflow process, and it receives its value from the temporary table’s Id column, that is, the ID of the user record. The Login Name process property receives its value from the temporary table’s Login Name column, that is, the Login Name of the user record.

List

Records

Comments About Values

Input Arguments

EmailAddress

FirstName

LastName

WorkPhoneNum

The Input Argument field values are the field names in the User Registration business component that the FindContact business service queries for a match. The comparison is made with the process property values given in the Property Name field. These process properties collect the entries made by the user.

Output Field: Id

Output Field: Login Name

As given by the Input Argument field values, the FindContact method is requested to return the Id and Login Name field values for each user record whose field values match the entries by the user. A temporary table of values is defined in which the rows are the records returned and the columns are given by the Value field values. One row of the temporary table contains the ID for a returned record in the Id column and the record’s Login Name in the Login Name column.

Output Arguments

Login Name

Siebel Operation Object Id

RegError

Each Property Name field value is a process property name. The Login Name and Siebel Operation Object Id process properties receive values if FindContact returns a unique matching record. If a unique record is not determined that matches the criteria, then RegError receives an error value.
Siebel Operation Object Id is used to identify the user record for subsequent operations in the workflow process, and it receives its value from the temporary table’s Id column, that is, the ID of the user record. The Login Name process property receives its value from the temporary table’s Login Name column, that is, the Login Name of the user record.

Modifying Workflow Process to Query Null Fields

By default, if a user completes fewer than all four fields on the User Information form, then only the fields that a user completes are used in the query to find a unique matching record in the database. For example, if the user enters first and last name only, then the query does not do any comparisons on the Email or Work Phone # fields.

You can specify that the Query User step (FindContact method in the User Registration business service) checks any empty fields to confirm that they are NULL in the database record to conclude that a record is a match. The following procedure describes this task.

To modify the User Registration Forgot Password Process workflow to query null fields

Make a copy of the User Registration Forgot Password Process workflow.

In the copy of the workflow, modify the Query User step by adding the QueryAllFields input argument with a value of Y. By default, the value of this input argument is N.

When you create input arguments, enter the fields and values described in the following table.

Field	Value
Input Argument	QueryAllFields
Type	Literal
Value	Y

Activate the amended copy of the User Registration Forgot Password Process workflow.
For detailed information about modifying workflow processes, see Siebel Business Process Framework: Workflow Guide.

Modifying Workflow Process to Request Different Identification Data

The data requested from the user in the User Information form is compared with data in existing user records to locate a unique database record. If you want to compare different data than those compared in the seed User Registration Forgot Password Process workflow process, then you must do the following tasks:

Modify the user interface
Modify User Registration Forgot Password Process input arguments

Modifying the User Interface for User Registration

To add or delete a field in the User Information form, you must use Siebel Tools to modify its underlying applet. The following procedure is intended to list the major steps you must perform to add or delete a field in the User Information form. For detailed information about performing any step, see Configuring Siebel Business Applications.

To add or delete a field in the User Information form

Open Siebel Tools.
Lock the User Registration project.
If you are adding a field, then determine what field to add. Add to both the VBC User Registration virtual business component and the User Registration business component the field that corresponds to the field you want to add. Use the same names for these fields.
For more information, see (Optional) Modifying Self-Registration Views and Workflows.
1. In the Object Explorer, click Business Component.
2. In the Business Components list, query or scroll to select the User Registration business component.
3. In the Object Explorer, expand Business Component, then click its Field child item.
4. In the Fields list, add the field you need for this business component.
5. Repeat this process for the VBC User Registration virtual business component.

Configure the applet VBC User Registration Initial Form Applet to display or hide the field.

In the Object Explorer, click Applet.
In the Applets list, query or scroll to select the applet VBC User Registration Initial Form Applet.
In the Object Editor, expand Applet, then click its Control child item.

In the Controls list:

If you want to hide a field, then select its record in the Controls list and check its Inactive field.

If you want to add a field, then add a new record in the Controls list. Complete only the fields listed. Use the indicated guidelines.

Field	Guideline
Name	Enter a name for this field, such as City
Caption	Enter the caption you want for this field in the user interface, such as City
Field	Enter the field that you determined earlier in this procedure that you want to add, such as City
HTML Display Mode	Delete the default value, so the field is empty
HTML Row Sensitive	Check
HTML Type	Pick Text
Sort	Check
Text Alignment	Pick an alignment
Visible	Check
Visible - Language Override	Enter Y

Configure the appropriate applet Web template for VBC User Registration Initial Form Applet to display or hide the field.
Update the repository and deliver the updates, then unlock the User Registration project.

Note: To remove a field from the self-registration user interface, you do not have to delete the field from the applet in which it appears. Instead, configure the applet so that the field is not displayed in the user interface.

Modifying Input Arguments for the Workflow Process

In the Query User step of User Registration Forgot Password Process, you specify the input fields to the FindContact method in the User Registration business service that are used to find a matching user record. You must modify this step to add or delete an input field.

You make this change by modifying the input arguments for the Query User step for a revised copy of the User Registration Forgot Password Process workflow process, then activating this copy. When you create input arguments, enter the fields and values described in the following table.

Table Values for Input Arguments for Query User Step

Field	Guideline
Input Argument	Enter the name of the field in the User Registration business component that you identified in Modifying the User Interface for User Registration, such as `City`. This is the field in the existing user records with which the comparison is made.
Type	Pick `Process Property`.
Property Name	Pick the process property that corresponds to the field in the User Registration business component that you identified in Modifying the User Interface for User Registration, such as `City`. The process property has the same name as the field, by convention.
Property Data Type	This field automatically populates with the data type of the process property.

Internal Administration of Users

You can provide an employee, a customer, or a partner user with access to one or more Siebel Business Applications by performing the following tasks:

Provide the user with a method to be authenticated and thus to connect to a database account.
An internal administrator uses a Siebel employee application, such as Siebel Call Center, to add the user to the Siebel database.

Implement your authentication architecture before adding new users. As an ongoing task, you must arrange that each new user can be authenticated at login. The setup and administration that you must perform for each new user depends on the authentication architecture you implement:

Database security adapter authentication. You must enter the user name for a valid database account in the user’s user ID field. You must provide the user ID and the password to the database account to the new user.
LDAP security adapter authentication. You can configure your application so that when you create or modify user records in the Siebel database, the security adapter propagates those changes to the user directory. Therefore, no separate administration of the user directory is required.

Note: For a Siebel security adapter to propagate new or modified user data from the Siebel database to the user directory, the administrator who modifies the database records must log in through the same security adapter.
If you implement an adapter-defined user name in your user authentication environment, then you cannot implement tools that allow users’ Siebel user IDs stored in the directory to be managed from within Siebel Business Applications and you cannot propagate a user’s Siebel user ID to the directory.

Note: Make sure the application user has write privileges to the user directory. The application user is the only user who creates or modifies users in the directory.
Web SSO authentication. You must maintain corresponding records in the external authentication system, the user directory, and the Siebel database for each user. If you want to implement a mechanism for synchronizing these records, then you must develop the utility independently, and implement it at the Web site level. Configuration guidelines are not provided in Siebel Business Applications documentation. You must provide authentication credentials to the new user.

About Adding a User to the Siebel Database

A user of a Siebel application is a record in the User business component. The S_PARTY, S_CONTACT, and S_USER tables in the Siebel database underlie the User business component. Each user is assigned a responsibility, a user ID, and, depending on the authentication architecture being used, a password.

An employee or a partner user is a user who has a position within a division, either internal or external, in the Siebel database. Other users, such as those who use customer applications such as Siebel Sales, do not have a position or a division. The S_EMP_PER table underlies the Employee business component, to which employees and partner users belong, in addition to the tables that underlie the User business component.

An administrator uses different views to add employees, partner users, and other users, although each of these users has a record in the User business component.

Caution: You can modify field values for existing employees, partner users, or contact users, such as in the event of a name change. However, changing the user ID for such a user presents special issues, because this ID might be stored in various other types of records, using a field such as CREATOR_LOGIN (where a foreign key to the user record is not used instead). Values for such fields are not automatically updated when the user ID is updated. If you change the user ID, then you must also update such values in other records.

For more information about the functions of responsibilities, positions, divisions, and organizations, see Configuring Access Control. See the following topics for information on adding users to the Siebel database:

Adding a New Employee

The procedure in this topic describes how to add a new employee record to the Siebel database.

At a minimum, an employee must have a position, a responsibility, and a Siebel user ID. You can also associate attributes with employee records such as skills, tools, assignment rules, and availability. By doing so, you can use the employee record and its attributes with features such as Siebel Assignment Manager.

The following procedure creates a User record for the employee only as a stage in allowing the employee to access the database.

To add a new employee

Log in as an administrator to an employee application, such as Siebel Call Center, and then navigate to the Administration - User screen, then the Employees view.
The Employees list appears.
Add a new record.

Complete the following fields, then save the record. Use the indicated guidelines.

Field	Guideline
Last Name	Required. Enter any name.
First Name	Required. Enter any name.
User ID	Required. Enter a simple contiguous user ID, which must be unique for each user. Typically, the user provides this user ID to log in. Depending on how you configure authentication, the user might or might not log in with this identifier. If you implement database authentication, then this field must be the login name for a database account.
Password	Optional (required for some authentication implementations). Enter a simple contiguous login password. The password must conform to the syntax requirements of your authentication system, but it is not checked for conformity in this form. For LDAP security adapter authentication, the password is propagated to the user directory. For database authentication, the password is propagated to the database.
Responsibility	Required. Pick one or more responsibilities which include appropriate views for the employee. If the administrator who creates the employee user has a value in his or her New Responsibility field, then that responsibility is assigned to the employee user by default. For information about the New Responsibility field, see Modifying the New Responsibility for a User Record.
New Responsibility	Optional. If the administrator who creates this user has a value in his or her New Responsibility field, then that responsibility is assigned to this field by default. For information about the New Responsibility field, see Modifying the New Responsibility for a User Record.
Position	Required. To be an employee, a user must have a position. If you assign multiple positions, then the position you specify as Primary is the position the user assumes when he or she logs in.
Division	Required. This field is populated automatically with the division to which the Primary position belongs.
Territory	This field is a read-only multi-value group. You are not able to enter a value manually. When you complete the Position field, the Territory field is populated automatically with territories with which the position is associated. (This field appears on the More Info form.)
Organization	This field value is inherited from the user who creates this user, but the field is editable. Users whose positions are in this organization have access to this employee record. (This field appears on the More Info form.) For information about organization access control, see Configuring Access Control.

Completing Employee Setup

You can set up employees either before or after you assign them a responsibility. For more information about completing employee setup, see the initial setup topic of Siebel Applications Administration Guide. Also see Siebel Assignment Manager Administration Guide.

Deactivating an Employee

You can deactivate an employee by dissociating the employee record from its responsibilities, altering the user ID, changing the employee’s status to Terminated, and removing the employee’s access to the database. The following procedure describes these tasks.

To deactivate an employee

Navigate to the Administration - User screen, then the Employees view.
In the Employees list, select the employee you want to deactivate.
In the More Info view tab, delete all records from the Responsibility field.
Change the user ID slightly, to indicate that the employee is no longer current.
You might want to establish a convention for renaming user IDs when you deactivate employees. One possible convention is to append some text such as "expired" to the user ID. For example, you might change CARD to CARD-expired.That way you can continue to see the person’s name associated with previous activity in history records.
Select the Job Information tab.
Change the Employment Status field from Active to Terminated.
Remove the employee’s access to the database.
If you implemented database user authentication, then you can remove the user’s database account. If you implemented external authentication, then delete the user from the directory from which the user’s database credentials are retrieved.

Note: In the case of external authentication, if the external user directory (such as LDAP) is shared by many applications, do not delete the user from the directory. Make sure that the user's database access user name and password are different from that user’s directory user name and password. Otherwise the user might be able to access the database directly using some database connection tools.

About Adding a New Partner User

A partner user is typically an employee in a partner company or a consultant to your company.

A partner user must have a position in a partner organization to be associated with that organization or to belong to position-based teams, such as opportunity or account teams.

You can assign a position to a new partner user from the following sources:

Positions that you create internally and associate with the delegated administrator’s partner organization
Positions created by delegated administrators in the partner organization

You can register and administer partner users in the Administration - Partner screen in Siebel Partner Manager or another Siebel employee application for which you have licensed this screen. For information about using the Administration - Partner screen, see Siebel Partner Relationship Management Administration Guide.

Adding a New Contact User

The procedures in this topic describe how to add a new contact user record to the Siebel database and how to promote a contact to a contact user.

Users who are not employees or partner users do not have positions. These users include, for example, customers who use Siebel Sales or students who use Siebel Training. They are called customer or contact users to distinguish them from employee and partner users.

Contacts, such as contacts at a customer account, can exist in the database without having login capability. You create such contacts as Persons in the Administration - User screen. The procedure in this topic applies to contact users to whom you are providing a login to the Siebel database.

Caution: You can modify field values for existing contact users, such as in the event of a name change. However, changing the user ID for such a user presents special issues, because this ID might be stored in various types of records, using a field such as CREATOR_LOGIN (where a foreign key to the user record is not used instead). Values for such fields are not automatically updated when the user ID is updated. If you change the user ID, then you must manually update such values in other records.

The following procedure describes how to add a new contact user.

To add a new contact user

Log in as an administrator to a Siebel employee application, navigate to the Administration - User screen, then the Users view.
The Users list appears.
Add a new record.

Complete the following fields, then save the record.

Use the indicated guidelines. The new user appears in the Users list.

Field	Guideline
Last Name	Required. Enter any name.
First Name	Required. Enter any name.
User ID	Required. Enter a simple contiguous user ID, which must be unique for each user. Typically, the user provides this user ID to log in. Depending on how you configure authentication, the user might or might not log in with this identifier.
Password	Optional (required for some authentication implementations). Enter a simple contiguous login password. The password must conform to the syntax requirements of your authentication system, but it is not checked for conformity in this form. For LDAP security adapter authentication, the password is propagated to the user directory. For database authentication, the password is propagated to the database.
Account	Pick one or more accounts to associate to the user. Specify one as the primary account. By default, the user sees this account when he or she logs in. For information about the function of the account in delegated administration, see Delegated Administration of Users.
Responsibility	Pick one or more responsibilities which include appropriate views in the customer application, such as Siebel eService, for this user. If the administrator who creates the contact user has a value in his or her New Responsibility field, then that responsibility is assigned to the new contact user by default.
New Responsibility	If the administrator who creates this user has a value in the New Responsibility field, then that responsibility is assigned to this field by default. For information about the New Responsibility field, see Modifying the New Responsibility for a User Record.
Time Zone	Choose a time zone so that times for events can be expressed in terms of this zone.
User Type	This field serves as a filter so that different applications can query for contact users only applicable to each particular application.
Work Phone # Home Phone # Fax #	The application interprets only the digits the user provides. Any separators are disregarded.

Promoting a Contact to a Contact User

You can promote an existing contact to a contact user by assigning user credentials and a responsibility to a Person record (a contact), as described in the following procedure.

To promote an existing contact to a contact user

Log in as an administrator to a Siebel employee application.
Navigate to the Administration - User screen, then the Persons view.
The Persons list appears.
Select the record of the contact to promote.
Enter values for the User ID, Password, Responsibility, and New Responsibility fields.

Modifying the New Responsibility for a User Record

A user record might or might not have a value in the New Responsibility field in the Users view. If a value does exist, then whenever the user creates a new user, the new user’s Responsibility field is assigned the value in the creating user’s New Responsibility field by default. This principle applies when a user of any type (employee, partner user, contact user) creates any other type of user.

A user’s own New Responsibility field is populated in one of the following ways:

The New Responsibility field value is inherited from the New Responsibility field of the user who creates this new user.
The New Responsibility field value is manually assigned to the user.

A user’s New Responsibility field can only be modified by an internal administrator.

Delegated administrators of Siebel customer and partner applications can upgrade a user’s Responsibility, but they cannot edit the New Responsibility field. Therefore, your internal administrators control the default responsibility that any customer or partner user inherits from a delegated administrator. It is important to make sure delegated administrators have New Responsibility values that you intend your new customer and partner users to have, such as the seed responsibilities provided for such users.

You might or might not want to use the New Responsibility field functionality when administrators create new employee records. If there are a variety of responsibilities assigned new employees, then it might make sense to leave employee’s New Responsibility field empty. If most of your new employees are assigned the same responsibility or you want to create a batch of new employee records that all have the same responsibility, then it is probably more efficient to assign a New Responsibility value to the administrator who adds the employees.

An internal administrator can modify New Responsibility values for employees, partner users, and contact users in the same administration screen.

To modify a user’s New Responsibility field value

Log in as an administrator to a Siebel employee application and navigate to the Administration - User screen, then the Users view.
The Users list appears, containing all the employees, partner users, and contact users in the database.
In the Users list, select the user record to modify.
In the form, pick a new value in the New Responsibility field, then save the record.
The user must log out and log in for the New Responsibility value to become active.

Delegated Administration of Users

A delegated administrator is a user of a Siebel customer or partner application whose responsibility provides views that allow the delegated administrator to register and administer other users of that application. Delegated administration is typically implemented in business-to-business relationships.

Delegated administration of users minimizes your internal administrative overhead by moving some of the administrative load to administrators in your customer or partner companies.

See the following topics for further information about delegated administration of users:

User Authentication Requirements for Delegated Administration

Delegated administration is default functionality of most Siebel customer and partner applications, but it is available only if you implement LDAP security adapter authentication.

Delegated administration cannot be implemented if you use database authentication. If you want to implement delegated administration in a Web SSO authentication environment, then you are responsible for configuring the functionality in your external authentication application, in your user directory, and in your security adapter. Such configuration guidelines are not provided in Siebel Business Applications documentation.

Delegated administration requires that you configure the LDAP security adapter to propagate new and modified user data from the Siebel database to the user directory.

If you implement an adapter-defined user name in your user authentication environment, then you cannot implement tools that allow Siebel user IDs stored in the directory to be managed from within Siebel Business Applications, including delegated administration of users. For information about user authentication, see Security Adapter Authentication.

Note: Make sure the application user for your Siebel customer or partner application has write privileges to the user directory.

Access Considerations for Delegated Administration

A delegated administrator has restricted access to user data.

Customer applications. A delegated administrator can only see users who are associated with accounts with which the delegated administrator is associated. The My Account User Administration View is based on the Account (Delegated Admin) business component. This business component essentially restricts a delegated administrator’s access to data that is associated with the accounts with which the delegated administrator is also associated.
Partner applications. A delegated administrator can only see partner users whose positions are in the same partner organization to which the delegated administrator’s position belongs.

A delegated administrator can add regular registered users or other delegated administrators. However, an administrator at your host company must add the first delegated administrator in:

Each account for a Siebel customer application
Each partner organization for a Siebel partner application

Creating a delegated administrator internally requires that you provide a user with a responsibility that includes the views needed for delegated administration. Your Siebel application provides seed responsibilities for delegated administrators of customer and partner applications. For information about seed responsibilities, see Seed Data.

Note: Delegated user administration screens, navigation, and procedures vary somewhat among Siebel Business Applications. The remaining topics describe delegated administration that is representative of customer and partner applications.

Registering Contact Users (Delegated Administration)

A delegated administrator who uses a Siebel customer application must belong to at least one account. The delegated administrator registers a user in the currently active account. The new user inherits membership in that account.

A delegated administrator must assign at least one responsibility to a new user. A delegated administrator can only assign responsibilities, including seed responsibilities, to users who are associated to same organization that the delegated administrator is associated with.

The delegated administrator is associated with the organization to which the proxy employee for the application belongs. The proxy employee is provided as seed data and is associated with the default organization. As with other seed data that Siebel Business Applications provide, you cannot modify the proxy employee. This means that to associate a delegated administrator with an organization other than the default organization, you have to make a copy of the proxy employee record and rename it. You then assign the renamed proxy employee to the organization that you want to associate the delegated administrator with. A responsibility is associated with an organization by an administrator at your company using an employee application such as Siebel Call Center.

For example, if the application object manager in use is the eCustomer Object Manager (ENU) and the proxy employee (PROXYE) is assigned the position Proxy Employee in Default Organization, then the eCustomer Object Manager (ENU) runs under the Default Organization context. If you need to run the eCustomer Object Manager (ENU) under the China Organization, then you create a copy of:

eCustomer Object Manager (ENU) and rename it (for example, eCustomer_China)
Proxy Employee and rename it (for example, PROXYE_CHINA)

You then assign the modified proxy employee (PROXYE_CHINA) to a position in the China Organization. This results in the application (http://WebServer/eCustomer_China) connecting to the China Organization because PROXYE_CHINA is associated with a position in this organization. For more information on the proxy employee, see Seed Employee.

To register a new customer user (by a delegated administrator)

Log into a Siebel customer application that implements delegated administration, such as Siebel Sales or Siebel eService.

Note: The delegated administrator must have user type Web Delegated Customer Admin.
Click My Account, and then click User Administration under My Company.
Lists of delegated accounts and associated users appear.
In the Delegated Accounts list, select the account with which you want to associate the new user.
The users in this account appear in the Users list.
Create a new record.

Complete the following fields, then save the record.

Use the indicated guidelines. The new record appears in the Users list.

Field	Guideline
Last Name	Required. Enter any name.
First Name	Required. Enter any name.
User ID	Required. Enter a simple contiguous user ID, which must be unique for each user. Typically, the user provides this user ID to log in. Depending on how you configure authentication, the user might or might not log in with this identifier.
Password	Optional (required for some authentication implementations). Enter a simple contiguous login password. The password must conform to the syntax requirements of your authentication system, but it is not checked for conformity in this form. For LDAP security adapter authentication, the password is propagated to the user directory. For database authentication, the password is propagated to the database.
Responsibility	Pick one or more responsibilities, such as a seed responsibility provided for contact users. If the delegated administrator who creates this user has a value in the New Responsibility field, then that responsibility is assigned to this user by default. For information about the New Responsibility field, see Modifying the New Responsibility for a User Record.
Home Phone # Work Phone # Work Fax #	The application interprets digits only in these telephone number entries. Any separators are disregarded.

Registering Partner Users (Delegated Administration)

A delegated administrator using a partner application, such as Siebel Partner Portal, has a position in a partner division. The delegated administrator can only assign to a new partner user a position from those included in the partner organization to which the partner division belongs.

A partner user must have a position in a partner organization to be associated with that organization or to belong to position-based teams, such as opportunity or account teams. A delegated administrator in a partner company can assign a position to a new partner user from the following sources:

Positions that you create internally and associate with the delegated administrator’s partner organization
Positions created by delegated administrators in the partner organization

A delegated administrator can only assign responsibilities to partner users whom your host company associates with the delegated administrator’s partner organization. An administrator at your company associates partner organizations with responsibilities using an employee application such as Siebel Partner Manager. To provide a new partner user with access to the database, a delegated administrator must assign a responsibility when registering the partner user.

To register a new partner user (by a delegated administrator)

Log into a partner application that implements delegated administration, such as Siebel Partner Portal.

Note: The delegated administrator must have user type Web Delegated Customer Admin.
Navigate to the Administration screen.
In the Explorer, expand the organization in which you will create the partner user.
Click the Users child item to display the users in this organization.

In the Edit User form, create a new record to add a new user.

Complete the following fields, then save the record. Use the indicated guidelines. The new partner user record appears in the Users list.

Field	Guideline
Last Name	Required. Enter any name.
First Name	Required. Enter any name.
User ID	Required. Enter a simple contiguous user ID, which must be unique for each user. Typically, the user provides this user ID to log in. Depending on how you configure authentication, the user might or might not log in with this identifier.
Password	Optional (required for some authentication implementations). Enter a simple contiguous login password. The password must conform to the syntax requirements of your authentication system, but it is not checked for conformity in this form. For LDAP security adapter authentication, the password is propagated to the user directory. For database authentication, the password is propagated to the database.
Position	If you assign multiple positions, then the position you specify as Primary is the position the partner user assumes when he or she logs in.
Responsibility	Pick one or more responsibilities, such as a seed responsibility provided for partner users. If the delegated administrator who creates this user has a value in the New Responsibility field, then that responsibility is assigned to this user by default. For information about the New Responsibility field, see Modifying the New Responsibility for a User Record.
Work Phone # Home Phone # Work Fax # Pager #	The application interprets digits only in these telephone number entries. The user can enter any separators.

Maintaining a User Profile

Each employee, partner user, and customer user is provided a profile screen in which to update identification and authentication data. Depending on the application and on the authentication architecture you implement, a user can perform tasks such as:

Profile forms, names, and navigation paths differ somewhat across Siebel Business Applications. The procedures in these topic are representative of those in Siebel employee, partner, and customer applications. Procedures in individual applications might differ.

Editing Personal Information

Users can change a variety of personal information in their profile form. In this context, authentication and access control data, such as passwords and positions, are not included. The following procedure describes how to edit personal information.

To edit personal information

Depending on the application, the user does one of the following:
- In a Siebel customer application, the user clicks My Account, and then clicks User Profile under My Settings. The User Profile form appears.
- In a Siebel partner application, the user clicks Profile. The Personal Profile form appears.
- In a Siebel employee application, the user navigates to the User Preferences screen, then the Profile view. The User Profile form appears.
The user clicks Edit to make the form fields editable, if necessary.
The user enters or changes data in editable fields, then saves the record.

Changing a Password

If you implement database or security adapter authentication, then a user can change the login password.

Note: If you want to implement similar functionality in a Web SSO authentication environment, then you are responsible for configuring the functionality in your external authentication application, in your user directory, in your security adapter, and in the Siebel application views. Configuration guidelines are not provided in Siebel Business Applications documentation.

To change a password, a user accesses the profile form as described in Editing Personal Information, and then completes the appropriate fields. The password-related fields are not editable if the password cannot be changed in the current authentication architecture.

Mobile users using the Siebel Mobile Web Client can also change their passwords for the local database and for synchronization. For details, see Siebel Remote and Replication Manager Administration Guide.

Changing the Active or Primary Position

An employee or partner user of a Siebel application can have one or more positions, of which one is the primary position. When the user logs in, the user assumes the primary position only and the data access that the position determines.

An employee can assume a position other than the primary position, which immediately makes it the active position. The employee then accesses only the data determined by the new active position.

Changing the active position does not change the employee’s primary position. When the employee subsequently logs in, the primary position becomes active.

Data visibility for a user is generally determined by the active position, rather than by a union of the user’s associated positions. However, catalog and group visibility are based upon the user’s employee record and are independent of the user’s active position. If users are associated with more than one position, then they have visibility to all the records associated with any of the catalogs that are associated with any of their positions (or associated with another applicable access mechanism).

To understand data visibility for a user, you must consider which access-control mechanisms are associated with the user (positions, user lists, access groups, and so on) and with which catalogs or categories those mechanisms are associated.

Changing the Active Position in a Siebel Employee Application

The following procedure describes how to change the active position in a Siebel employee application.

To change the active position in a Siebel employee application

Navigate to the User Preferences screen, then the Change Position view.
The Change Position list appears.
Click on a position record to select it, and then click Change Position.
A check appears in the Active Position field for the selected position.

Changing the Primary Position in a Siebel Partner Application

A partner user can change the primary position as described in the following procedure. The user assumes the primary position when the user next logs in.

To change the primary position in a Siebel partner application

The partner user clicks Profile.
The Personal Profile form appears.
The partner user clicks the Active Position select button.
The Positions Occupied list appears.
The partner user checks a position to make it the new primary position, and then clicks the Save button for the record.
The partner user clicks OK.
The new primary position displays in the Personal Profile form.
The partner user logs out, and then logs in again to make the new primary position active.