1. Developing and Deploying Siebel CRM
  2. About Seed Data Users

About Seed Data Users

While Oracle cannot predict what Users will use a particular Siebel CRM instance, there are several Users, some of which are also Employees, that are created as Seed Data to serve specific functions. This topic will explain those Users, as well guidelines for adding new Users.

The following Users are required for the Siebel CRM system to function:

  • SADMIN (Employee User). After installing Siebel CRM, it is necessary to be able to log in as some user in order to do anything. This is true of any system. For example, a new Microsoft Windows implementation always has an Administrator user. While a Unix system will have an admin user. The SADMIN user is that lynch pin user for Siebel CRM. It is loaded as part of seed data and by default has access to every screen and view in the Siebel CRM application.

    It should be noted that there is a common misconception that SADMIN is somehow magical, in the sense that it can circumvent various security mechanisms. For example, there is an assumption that if a user creates a new customer account record, SADMIN will automatically be able to access that record. That is not accurate. The SADMIN user has access to the Account Administration View, which in turn provides access to all customer Accounts; however, were the SADMIN user to lose access to that Administration View, it would lose access to customer accounts to which it is not directly associated.

    However, this is precisely why Seed Data associated with the SADMIN user should not be modified. For example, removing the SADMIN user's access to particular parts of the application or certain records could result in a situation where the application is no longer configurable or data is essentially unreachable, because no user has access.

    Therefore, rather than adjust SADMIN's default access, it is preferable to restrict who can log in as this user by keeping the password secret.

  • GUESTCST (Customer User), GUESTERM (Employee User), and GUESTCP (Partner User). These are proxy users. By default, they have access to very little, but what they can access is very important, as they determine what users can see before they login. Consider, for example, an Internet-facing customer portal for a bank. That bank may use Siebel CRM for customer-specific activities, such as checking account balances or initiating payments. However, it will also offer basic services that should be available without the need for a customer login. For example, a user should be able to visit the web site and look up the location of the nearest branch of the bank and should not have to log into their account to do so.

    The proxy users in this example, GUESTCST, provide this capability. Each has access to a set of screens and views within the application that should be readily available without logging in.

    There three different users allow some flexibility in terms of what type of user can see which views without logging in. Any can be specified as the Anonymous User when creating a Siebel Application Interface Profile as explained in the Installing the Siebel CRM Environment chapter. In the out-of-the-box seed data, these are mapped to out-of-the-box views as follows:

  • GUESTCST (Anonymous Customer User). Includes access to customer-facing views, such as branch locator or product configuration.

  • GUESTERM (Anonymous Employee User). Employee facing views, such as support knowledge bases for users to browse before creating a HelpDesk Service Request.

  • GUESTCP (Anonymous Partner User). Partner facing views, which could include any or all of the previous views, depending on the particular use case.

  • PROXYE. This is used during the User Self-Registration process. For example, a customer who wants to register for a site hosted by Siebel CRM.

  • UNIVERSALQUEUE. This user is obsolete. It can be ignored as it has no ability to access the application because this user has no way to log into Siebel CRM.