4Basic Organization Setup: Overview
Basic Organization Setup: Overview
Once the Siebel CRM components have been installed and configured, it is tempting to immediately start implementing configuration and other changes to personalize the functionality for a particular set of business needs. However, spending a small amount of time doing some administrative work in advance of this step will set the stage for smoother development and testing cycles, eventually leading to a better user experience in a production environment. This chapter includes the following topics:
About Seed Data
When the Siebel CRM Database is created, it logically has the following components:
-
Physical Structure. The physical structure includes tables, indexes, and a very small number of other database objects. Siebel CRM does not define business logic in database objects. For example, only nominal data validation (such as datatype) is done at the database layer. Siebel CRM does not use stored procedures or triggers in the base product except in rare cases. The physical database is 99% tables and indexes. This allows for the maximum amount of portability across the database platforms that Siebel CRM supports.Note: There are some specific examples where triggers are added later in support of the workflow or integration, but the basic product does not include these at the time of installation.
Repository Data. The Siebel CRM Runtime Repository contains metadata that defines how the Siebel CRM application behaves. For example, it defines which user interface objects a user can see, where to store data at the physical layer, validation rules, and workflow. Repository data is discussed in depth later in this guide and throughout the Siebel Bookshelf.
Seed Data. This is data that is placed in the database to provide the user with basic options before any customization or configuration of the product has occurred. The following are a few examples of seed data:
List of Values. This type of seed data appears in Picklists throughout the Siebel CRM application. For example, consider the possible states for a Service Request record. The possible states can include: New, In Progress, Waiting on Customer, Working, Waiting on Engineering, or Closed. However, different options may apply to an Activity. The possible states for an Activity can include: Planned, Confirmed, In Progress, or Done. A List of Values contains a default set of options for Picklists. For more information about List of Values, see About List of Values.
Currency. Currencies facilitate interactions with the global economy. The Siebel CRM database is seeded with the known world currencies for users to select from and to assist with conversion between them. For more information about currency, see About Currency.
Time Zones. Time zones are a critical component in working with a global economy. Time zones support showing Siebel CRM interactions in the time zone of a given user, but are crucial in determining whether Service Level Agreements are being met. For more information about time zones, see About Time Zones.
Responsibilities. Responsibilities determine which application views a particular user can see. For more information about responsibilities, see About Responsibilities.
The various types of seed data have the following factors in common:
Seed data is placed into the database at the time that the Siebel Database Configuration Wizard runs.
Seed data can be inactivated or supplemented. For example, you may add a new Service Request status or remove an existing one.
Seed data should never be deleted. If it is not wanted or needed, it should be inactivated. The reason for this is that the Siebel Upgrade Process (Incremental Repository Merge, or IRM) will put it back the next time it is run.
Other than activation or inactivation, seed data should not be modified. For example, if you want to eliminate the Closed Service Request status and create a new one named Finished, the recommended approach is to inactivate the Closed record and create a new record for Finished, rather than change Closed directly to Finished.
This avoids issues during the Upgrade IRM process.
In some cases, specific seed data is required for the application to work properly. This is particularly true for objects that have specialized functionality, such as Calendar objects.
Seed data may be modified in each release of Siebel CRM. For example, time zone rules change annually due to local laws. The Oracle Siebel CRM Engineering Team regularly update the time zone seed data to reflect current law.
About Views
Home Page Views. Home Page Views are where a user is placed immediately after login. These views are typically made up of several regions (known as applets) that will help a user to see the most important information they need to decide where to start their day. For example, a Field Service user may see a list of open Service Requests and a Calendar showing where they have scheduled customer appointments, while a Sales user might see a list of their Sales Opportunities and outstanding Activities.
List Views. List Views are where a user can see many objects of the same type. For example, a user may want to see a list of customer accounts, contacts, campaigns, or service requests. These views typically allow the user to drill into a particular item to a detail view in order to get more information about that object. For example, drilling into a specific customer account will provide access to related contacts, opportunities, service requests, or orders.
Detail Views. Detail Views are where a user can see more detailed information about a given top-level object as explained above.
Specialized Views. Specialized Views include charts, dashboards, or portals to other applications.
Runtime Repository. The Runtime Repository stores the actual definition of the view. For example, what objects appear in the view, how are those objects laid out, what child objects does it include, and what high-level screen object is a part of the view.
Administrative Seed Data. In addition to defining the view in the runtime repository, each view must be registered within the application. For more information about registering views, see Registering Views.
My Views. My Views shows all of the objects to which you have a direct association. My Opportunities shows all sales opportunities for which a given user is directly involved. These are typical used by independent contributors.
-
My Team's Views. My Team’s Views show all of the objects which meet one of the following criteria below. The typical user is a manager at any level.
You are a manager and are personally involved. For example, you are working on a sales opportunity.
You are a manager and have a direct report involved. For example, an employee working for you is working on a sales opportunity.
You are a higher-level manager and have someone who directly or indirectly works for you involved. For example, you are a director with a manager under you who has a sales representative working on a sales opportunity.
All Views. All Views show all of the objects across your particular Organization. This can be a little misleading, in that a large company may have many different Organizations in it. See the section on Organizations for more information, but as a simple example, consider a multi-national company. You may define an Organization as a region. For example, North America, Europe, or AsiaPac. You may want to be able to restrict visibility to users being able to see only those sales opportunities within their region. A typical user of these views is a senior executive or a cross-functional user, such as a technical support engineer who must support all customers.
All Across My Organizations. All Across My Organizations view is similar to All Views. All Across My Organizations view allows a user associated with more than one Organization to see all the objects within all those Organizations at once. To continue the previous regional example, this would allow separate regions for Eastern Europe and Western Europe to be defined as Organizations and allow a user to be associated to both of those and see all sales opportunities in either region. Typical users are senior executives or cross-functional users, such as Support Engineers.
All Across All Organizations. All Across All Organizations view shows all objects of a given type, without regard to owner or Organization. These views are typically reserved for very senior users, such as CEOs.
Administration. Administration views are specialized views that allow access to all records of a given type and always allow editing of those records, even if a given field or even the entire record would normally be marked read-only. These are reserved for system administrators and are used to repair data, for example, cleanup mistakes and reassign data when it is not visible to those users who need it.
About Seed Data Views
Immediately after installing the Siebel CRM database, there are well over 10,000 Views in seed data. This is an illustration of how extensive the Siebel CRM application is and many use cases and business needs can be accommodated by one of these views without the need for additional development or customization.
Registering Views
In the event that a new view is required, making that view available to end-users requires a few separate steps. For information on the actual creation of Views, such as the layout or content, see Configuring Siebel Business Applications. Only after defining the view and releasing it to the runtime repository will you be concerned with registering the view for use.
After designing, configuring, and testing the new view, navigate to the Site Map, Administration - Application, and then Views. Create a new record using the same name as that used when defining the view in the Siebel Runtime Repository. The only option required is whether or not that view should be made available to Siebel Mobile users, as indicated by the Local DB checkbox. This concept is explained in the Siebel Bookshelf. As a simple rule of thumb, a view that could expose a lot of data, such as an All Opportunities View, should not be made available to remote users for performance reasons.
About Responsibilities
Responsibilities provide access to specific Views to particular users. Different types of users need access to different views for varying functional reasons. For example, a sales representative should not be working on service requests and a field service engineer should not be creating marketing campaigns for visibility reasons or a partner user should not be able to see sales opportunities that partners from a different company are working for competitive reasons.
In addition to security and functional reasons, Responsibilities ensure that users are able to focus on the information most relevant to them. Responsibilities allow you to present only those views that a user actually needs to do their job by providing a many-to-many relationship between Views and Users.
The easiest way to conceptualize and define Responsibilities is to consider generic job classes. For example, sales representative, sales manager, service technician, or even CEO. These are classes of job that require access to different types of data. For example, sales users need access to sales-related data, such as sales opportunities, while service users need access to service-related data, such as service requests and require access to different levels of data and sales representatives need access to the data of customers that they directly work with, while service users need access to service data for all customers.
About Seed Data Responsibilities
Seed data responsibilities provide access to out-of-the-box views for various user types that are found in a given organization. There are over 400 Responsibilities defined and there are over 100,000 mappings from these responsibilities to various Views. While this sounds like a lot, consider all the different types of users within a large organization and the records to which they might need access:
Sales Representatives. Sales representatives need access to Accounts and Opportunities that they are working on.
Sales Managers. Sales managers need access to Accounts and opportunities that they or their reports are working on.
Marketing Managers. Marketing managers need access to all customers in order to conduct marketing campaigns.
Field Service Engineers. Field service engineers need access to all customers associated with service requests that they are working on.
Call Center Support Engineers. Call center support engineers need access to all customers since any customer can call and service requests they are working on.
Fulfillment Center Workers. Fulfillment center workers need access only to requests for literature fulfillment and the contact information for the recipients.
CEOs. CEOs need access to all customer data. However, the CEOs may have restrictions on the types of changes that they can make and should not be able to modify system administration data. For example, changing Siebel CRM application behavior.
Application Administrators. Application administrators need access to everything so they can address any issues that may occur.
For these reasons, Oracle engineers have seeded responsibilities to reflect the most common roles seen within an enterprise. This makes it easy to quickly associate a given new user with an existing Responsibility.
Adding New Responsibilities
There are many seeded Responsibilities, but nearly all Siebel CRM customers add their own Views and need a way to expose those Views to their users. The recommended approach is to use a combination of seeded Responsibilities and custom Responsibilities.
Giving a user a seeded Responsibility will ensure that a user receives new views relevant to their job function as and when Oracle releases new functionality within the product. For example, assume that Oracle Engineering adds a new set of views to the existing sales functionality in Siebel CRM. Oracle Engineering will not just create the views, but will also add them to appropriate existing Responsibilities. Therefore, a customer user with that Responsibility will receive access to the new functionality whenever that new release is deployed without any administrative changes being required.
Custom Responsibilities will contain all views developed by the customer and any out-of-the-box views that do not come as part of their out-of-the-box Responsibilities.
To prepare for associating users with the correct Responsibilities, perform the following steps:
Determine the distinct job classes that will exist in your organization. For example, these might include Field Sales Representative, Sales Manager, Marketing Manager, Call Center Agent, or Call Center Manager.
Examine the seeded Responsibilities and determine which are appropriate for each job class.
In many cases, a manager job class may have the same Responsibility as the subordinates and an additional Responsibility for the additional views required for their management responsibilities.
Plan to create an additional Responsibility for each user class. This will contain all custom views for that user class. The table below illustrates out-of-the-box responsibilities and custom responsibilities for several user classes.
Table User Class Responsibilities
User Class
Description
Out-of-the-Box Responsibilities
Custom Responsibilities
Sales Representative
Individual contributor, works with a specific set of customers to close sales deals
Field Sales Representative
XYZ Field Sales Representative
Sales Manager
Manages a team of Sales Representatives.
Field Sales Representative
Sales Manager
XYZ Field Sales Representative
XYZ Sales Manager
Marketing Manager
Plans and manages marketing campaigns.
Marketing Manager
XYZ Marketing Manager
Call Center Agent
Answers phone calls from customers requesting service.
Call Center Agent
XYZ Call Center Agent
Call Center Manager
Manages the call center and its employees
Call Center Agent
Call Center Manager
XYZ Call Center Agent
XYZ Call Center Manager
Siebel Administrator
Manages all aspects of the Siebel CRM application.
Siebel Administrator
XYZ Siebel Administrator
These examples assume your company is XYZ. Use any simple prefix that will allow you to easily determine which are your custom Responsibilities and make them easy to find when querying.
Having documented the Responsibilities you plan to use, navigate to Site Map > Administration - Application > Responsibilities to add the custom Responsibilities. Since you have not created any custom views, yet, it is possible that your custom Responsibilities will have no related Views, which is expected. You will associate the Views to these custom responsibilities later as they are developed.
About Organizations
In Siebel CRM, Organizations allow data to be segregated across divisions or other organizational units within the overall company. Many companies do not leverage Organizational visibility in Siebel CRM, but it is a useful tool to segment data across sets of users. The definition of an Organization is at the discretion of the company implementing Siebel CRM, but below are some examples of reasons why Organizations might be appropriate:
Disparate geographies: Users in North America should not see Opportunity data from Asia Pacific. This could be for external legal or regulatory reasons or internal governance reasons.
Partner visibility to data: Consider a company who sells its products through external partner companies who use Siebel CRM. For competitive reasons, partner companies should not be able to see sales leads belonging to other partners. Segmenting data organizationally by partner ensures that this could never occur.
Diverse product areas: Consider a conglomerate that sells jet engines to airplane manufacturers and home appliances to end-consumers. Every type of data such as products, sales representatives, sales channels, potential customers, and pricing are all completely unrelated to each other and should not overlap.
Every company should consider its own needs and determine whether Organizational visibility makes sense. If so, it is best to create Organizations in advance as it is easier to ensure data is correctly segmented at the time it is created. Creating Organizations in advance is recommended even in Development and Test environments as this ensures that developers are always aware of the Organizational visibility requirements and are inherently developing and testing for it.
To create an Organization, navigate to Site Map >Administration - Group > Organizations and create new records based on your business needs. For more information about setting up Organizations, see Siebel Security Guide
About Positions
Positions represent job slots within an organization, typically a sales organization. Consider a sales organization that is defined by region. For example, Northeast Florida sales representative, South Florida sales representative, or Florida Panhandle sales representative. At different points in time, a different human may be handling that region. John Smith may be responsible for Northeast Florida today, but he might be moved to South Florida, promoted to sales manager, or even leave the company.
The customers and potential customers in his region do not change just because John moves to a different position or company. Someone else, perhaps Dave Jones, will take over those customers and opportunities and continue to manage that territory.
For that reason, Siebel CRM does not associate sales data, such as customer accounts, contacts, sales leads, or opportunities, with specific users, but rather with the position that conceptually owns this data.
At a given point in time, a given user will hold a position, in this example, Northeast Florida Sales Representative and be able to see all the relevant data for that position. When John Smith moves on, he is disassociated with that position and the new user, Dave Jones, is associated to that position. This immediately moves all the data visibility from John to Dave.
The following are some guidelines for creating positions:
For sales-centric organizations, there should usually be a one-to-one mapping between positions and users. You should create a position for each user before creating the actual users. There will be occasions where a user might have two positions. For example, John Smith is on vacation or the organization is looking for his replacement, so Dave Jones temporarily has his own position and John's, but as ideally the organization would like two sales representatives for this, two separate positions should be maintained in this type of example.
For service-centric organizations, positions play a much smaller role, because a service user is typically not bounded by geography or other constraints. For example, if a user works in a call center, answering phone calls from customers, that user is not typically associated to a particular region or set of customers. Rather, they must assist any customer who calls in. As such, in a strictly service organization, it is common for service users to share a position.
It is possible to have a combination model within a single company–individual positions for sales users based on the way in which territories are assigned while service users share a position.
Before continuing forward, create the required position records using the guidelines above for determining whether individual positions are required for each user or whether positions can be shared. Positions are created by navigating to the following: Site Map > Administration - Group > Positions.
About Users and Employees
Users represent individual humans (or, in the case of integration, virtual humans) who use the Siebel CRM system. A User is any valid user (person or automaton) that can use the system, and has a minimum requirement of a first and last name, Login Id, and a Responsibility. An Employee is a special class of user who additionally must have a Position and may also have other optional attributes, such as skills and certifications.
The distinction of Employees (having a Position) is the key difference–as noted above, sales-related data (sales accounts, opportunities, and contacts) are associated to Positions, and therefore only Employees (through their Positions) can own such data. Non-employee users, such as customers who are registered to use the system to log service requests or place sales orders, cannot own that type of data.
When creating a User record, consider the following:
Responsibilities (groups of views). Users require one or more Responsibilities. This determines which Views that user can even reach. It is important to understand that Responsibilities and Views dictate where the user can go. Responsibilities and Views do not fundamentally determine which data a user can see. For example, assume that a user, through his Position, can see Contact data for a particular customer. Unless the user also has access to a Contact view through a Responsibility, that user has no way to see that data, even though they are entitled to see it. For more information about responsibilities, see About Responsibilities.
Organizations. An Employee User may be associated with one or more Organizations. This allows the Employee to readily access in their own Organization, for example, account records in their geographic reason, while preventing them access to data outside that region. For more information about organizations, About Organizations.
Position. An Employee User may have one or more Positions. As with Organizations, Positions control visibility to individual records within the application, such as specific customer accounts, but at a more granular level. It should be noted that while an Employee may indeed have multiple Positions, a user can only actively use one at a time. For more information about positions, see About Positions.
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 above, 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.
About Creating New Users and Employees
While it is possible to create non-employee users within the Siebel CRM application, most non-employee users are created by the actual user through self-registration. For example, a customer who wants to place an order through the sales application registers before being able to complete the order, or an existing customer creates an account the first time they log a service request. The process of self-registration and how to customize the user experience is documented in the Siebel Security Guide. This topic focuses only on creating new Employee records.
Setting the employee’s Siebel CRM attributes.
Setting the employee’s authentication requirement.
On the Siebel CRM side, creating an employee user involves the following steps:
To ensure the most flexible visibility scheme, Oracle recommends that each employee has a unique position. This is not a strict requirement for employees. It is required for sales users. It is also possible for service users to share positions. Adding a position provides for finer control over data visibility and there is no downside to creating a unique position for each user. The first step in creating a new Employee record is to first create a Position record.
After creating Position records for each new employee, navigate to Site Map > Application > User > Employee.
Create a record with the user's first name, last name, and a login name (this may be arbitrary or may be dictated by the authentication mechanism). While not required, it is strongly recommended that each employee have an email address, as this can be leveraged for integration with corporate mail systems such as Microsoft Exchange, as well as sending email from within Siebel CRM.
Associate the Employee's Position and specify one or more Responsibilities.
Having completed the steps above, Siebel CRM now considers the Employee a full-fledged user. This user can be associated to Siebel CRM objects, such as Accounts, Opportunities, Contacts, or Service Requests.
However, the user will not actually be able to log into Siebel CRM. The reason for this is that Siebel CRM does not provide a native method for authentication, but rather relies on external authentication mechanisms. These are described in detail in the Siebel Security Guide, but are summarized here:
Database Authentication. When database authentication is configured, Siebel CRM passes the username and password provided by the user directly to the underlying database for authentication. If you use this mechanism, each user must be created in the database by the Database Administrator and have access to the Siebel CRM database objects, such as tables and indices.
Note: This is not the recommended model because a user can connect directly to the database through a database-specific utility, such as SQL*Plus, and would be able to interact freely with the data in the database. This creates a potential security problem.-
LDAP Authentication. With LDAP authentication, Siebel CRM uses an external LDAP authentication authority to validate a user's login credentials. The advantage of this approach over Database Authentication is the following:
A user can use their same credentials across many systems that share a common LDAP authority.
Because users do not have direct database credentials, the security issue described with Database Authentication does not apply.
SSO Authentication. SSO authentication is very similar to LDAP authentication in that an external authentication authority is used to validate the user's login credentials. The difference is that under SSO authentication, once a user has logged into any SSO-enabled application within the enterprise, the user is not required to login again as long as the browser is open. For example, consider the case where Siebel CRM shares an SSO authentication authority with two other systems, X and Y. When a user navigates to system X, he or she will be required to enter credentials. If that same user opens a new browser tab and navigates to Siebel CRM (or system Y), the user will not have to provide credentials a second time.
Regardless of the authentication mechanism in use, to allow the Employee User to have access to the Siebel CRM system, it will be necessary to provision the user in that authentication authority. In the case of Database Authentication, this would mean creating the user in the database. In the case of the other two authentication options, it would mean provisioning the user in that authentication authority and providing a mapping from that user to the Siebel CRM login. For example, mapping SSO user john.smith@company.com to Siebel CRM user JSMITH. For specifics relevant to your implementation, see the Siebel Security Guide.
About Creating Developer Users
A Developer User is a special class of user that is empowered to make configuration changes to the Siebel CRM application. Historically, a developer user was a traditional technical resource who performed coding and configuration changes. With the release of Siebel Innovation Pack 2017 and Siebel Web Tools, the ability to configure the Siebel CRM application can be extended to a wider set of users such as developers and business analysts. Basic changes such as adding a field or re-organizing the user interface in Siebel CRM can be completed by a much wider community of users.
The ability to modify the Siebel CRM application should not be granted lightly. When you modify the Siebel CRM application, keep in mind the governance process and the use of Siebel Approval Manager to ensure that changes are properly vetted and approved. Leaving aside the governance process, the basic capability for a developer or business analyst requires the following:
Each user who will be allowed to make configuration changes must be granted the Composer Administrator responsibility.
Each user who will be allowed to deliver configuration changes to the main branch must be granted the Workspace Administrator responsibility.
Any Developers or Business Analysts who will be making changes needs access to all views in the Siebel CRM application. For example, to create new View and Responsibility records or testing their changes to all objects. In a development environment, developers or business analysts must be granted the Siebel Administrator responsibility.
After granting any new responsibility to a user, the user must log out of the Siebel CRM application and close their browser in order to see the changes made to Siebel CRM.
About Other Seed Data
The critical seed data items that you will need to allow users to use the system while providing access to those functional areas and data they need while preventing them from others are addressed by the Seed Data objects described above. There are a number of other common Seed Data objects that will also need customization in order to meet the business requirements for your particular organization. The most common of these include:
About List of Values
The List of Values (LOV) entity is one of the most important in the Siebel CRM application. It provides the values in almost every dropdown or picklist within the Siebel CRM application. For example, setting the status of a Service Request to New, In Progress, Waiting on Customer or picking the recurrence pattern for a Calendar appointment to Weekly, Daily, or Monthly. LOV’s also provide values to even more internal technical items, such as the deployment state of a Workflow Process are all made available in the List of Values Seed Data.
A LOV is simply a huge list of all the drop-down values throughout the Siebel CRM application that are broken out by a type, that is stored in the LOV known as LOV_TYPE. The LOV_TYPE filters each individual picklist. Using the previous example of Service Request Status, Calendar Recurrence, or Workflow Process Status, you will see that there are three different LOV_TYPEs. The image below shows the three types of LOVs.
Each of LOV_TYPE has specific records relevant to the picklists where they are used. For example, consider REPEATING_APPT_TYPE in the image below.
These values appear in the application when selecting the repeating pattern for a meeting. The image below shows the REPEATING_APPT_TYPE values.
The LOV_TYPE value in this example, REPEATING_APPT_TYPE, determines which items show up in which picklist based on settings in the Siebel Runtime Repository.
REPEATING_APPT_TYPE: This LOV type indicates the types of repeating patterns that the Siebel Calendar can support. Logically, adding a new one, for example, every hour, is not going to work because the underlying calendar code will have no idea what to do with an hourly appointment. Oracle does not recommend customizing this LOV type.
SR_STATUS: This LOV type indicates the current status of a Service Request. This is an example of an LOV that can be modified, but there are some considerations. Specifically, based on the underlying object definition, it is not possible to make changes to a Service Request once it is closed. Therefore, while it is possible to add to the list of status values available, there could be negative behavior were the administrator to remove or rename the Closed status.
WFA_DPLY_STAT_CD: This is an example of an LOV that must never be modified. It is controlling the behavior of a repository object. The status of a given Workflow Process can certainly change, the administrator can mark a Workflow Process as Inactive or Active. However, making changes to the possible values would have unknown and undesirable repercussions.
The examples above all imply that it is not allowed or at least not recommended to change LOVs but that is not the case. For example, there is no reason not to modify Account or Contact Status values, the Service Request Areas and Sub-areas since these are completely acceptable changes.
As noted above, do not change LOVs for objects that control system behavior, such as Workflow Process Status.
Be careful modifying highly specialized objects or those that illustrate unique behavior in the application. For example, if you note that closing a Service Request makes it read-only, then be careful modifying that LOV type.
As with all seed data, do not delete LOVs. If something is not desired in your implementation, inactivate the LOV. On a side note, doing so is not effective in the long run since Siebel CRM upgrades restore missing LOVs. Removing a LOV lasts until the next upgrade, while inactivating it will last forever and the upgrade process will not reactivate inactive LOVs.
Similar to the last point, do not rename LOVs. If a name change is desired, for example changing In progress to Working. In that example, it would be best to inactivate the undesired LOV and create a new active one. Failure to do so will result in the renamed LOV coming back at the next upgrade and may throw errors during the upgrade process.
About Time Zones
There are various customer dashboards used within the service areas of the application that allow a user working with a customer, such as a live phone conversation, to see information about that customer, including their current time.
The calculation of Service Level Agreements. For example, if a customer is guaranteed a response within a certain number of hours, it is important to understand the time zone of the customer to accurately calculate how long the issue has been open or waiting a response.
Integration with other systems. For example, consider integration with Microsoft Exchange for calendar items. Without a common understanding of time zones, meetings may appear to shift as they are synchronized between the two systems.
In general, time zones are updated in every major Siebel CRM release, including every Innovation Pack. However, time zones change due to legislative reasons on a regular basis. For example, the United States changed the start and end dates for Daylight Savings Time (DST) in 2005. Other countries make more frequent and irregular changes, such as Brazil, which moves the DST transition date around based on Mardi Gras.
If any of these types of concerns are relevant to your implementation, ensure that Time Zones are updated regularly.
About Locale
Locale is a combination of geography, language, and culture. To understand Locale, consider the difference between the Unites States and the United Kingdom. Both share a common language, but they use completely different units of measure. The United States uses the English language, but use miles, degrees Fahrenheit, and gallons, while the United Kingdom uses kilometers, degrees Celsius, and liters.
Other examples include parts of Belgium and France that use French as a national language, but they have different dialects. For example, ninety is quatre-vingts dix in French, but nonante in Belgium.
Locale also covers punctuation. North Americans, for example, use a comma to separate the digits in a large number (1,000,000 being one million), while central European countries use a period (1.000.000 being the same million in central Europe) and Switzerland uses an apostrophe for the same million: 1'000'000.
Oracle provides seed data that reflects the common locales, but it is important that each locale in which you will have users is double-checked for accuracy.
About Currency
Currencies do not often change. The Euro is the last major change in currency. However, currency exchange rates constantly fluctuate. If your Siebel CRM application will be doing calculations such as forecasts, orders, or billing, in more than one currency, it is important to have a system in place for constantly updating the current exchange rate between various currencies.
About Sales Methodology and Sales Stages
For sales organizations, a common option is the selection of a sales stage. For example, a particular Opportunity might be Unqualified, Qualified, Lead, or Short List. In Siebel CRM, this concept is handled at two levels. The Sales Methodology is a parent attribute that defines the process followed for an Opportunity. The sales stages are the children relevant to the type of Sales Methodology.
There are some sales processes that require many steps. For example, a sale to a large corporation with a procurement organization that requires multiple sign-offs. or a fewer number of steps where a less complex process is needed to work through the sale. These are seen on Sales Opportunities. The following table contains examples of sales methodologies:
Table Sales Methodologies
| Sales Methodology | Sales Stages |
|---|---|
| Default Sales Methodology |
|
| Mortgage Application |
|
| Strategic Selling |
|
About System Preferences
The System Preferences control the overall Siebel CRM application behavior. In general, changing System Preferences effects every user unless there exists a specific user-level override, which is unusual. Individual System Preferences are documented throughout the Siebel Bookshelf by functional area. It should be noted that most System Preferences take effect at the next Siebel Server restart.