Oracle Siebel Views, Custom Views, and Licensing Explained

What is Siebel Views?

• Definition: Siebel Views are specific screens within Siebel CRM that display related data and functionalities.
• Access: Users gain access to these views through assigned Viewlists.
• Responsibility: Assigned responsibilities automatically authorize users to use the corresponding views and products.
• Management: Crucial for managing user access and ensuring compliance.

Understanding Siebel Views and Their Importance

Oracle Siebel CRM is a powerful on-premises enterprise application, and its user interface is organized into views – screens that display specific business data (e.g., accounts, opportunities, service requests). Understanding how standard and custom Siebel views relate to Oracle’s licensing model is crucial.

Each view corresponds to certain modules or functionalities, and licensing is tied to what users can access, not just what they actively use.

This article explains Siebel views, customizations, and licensing in plain terms, helping CIOs and IT leaders avoid compliance pitfalls and optimize costs.

Understanding Siebel Views

Siebel views are the building blocks of the user interface in Siebel CRM.

A view is essentially a screen or page that allows users to interact with a specific set of data or functionality. For example, Siebel includes views such as an Account List View (displaying customer accounts) or a Service Request View (for support tickets).

Views typically contain lists, forms, or charts (called applets) relevant to a business task. They are grouped into higher-level categories called Screens (for instance, a Sales screen contains opportunity and contact views). Users navigate across Siebel by switching screens and views via tab menus.

Key points about Siebel views:

• Standard (Out-of-the-Box) Views: Oracle provides many pre-built views covering common CRM functions – e.g. Contacts, Opportunities, Leads, Service Requests, Campaigns. These are included with the base Siebel application license and support typical sales, marketing, and service processes.
• Access via Responsibilities: Each user in Siebel is assigned one or more responsibilities (roles) that determine which views they can see. In other words, a user’s role gives them a View List – a defined set of views/screens accessible to that role. This controls security and also has licensing implications (because any view a user can access must be licensed appropriately).
• Navigation: Views are organized under screen tabs (often visible as top navigation or side menu). Within a screen, users click on view links to drill down into specific data sets.

Standard views significantly reduce implementation time since they cover generic needs. For example, the “My Opportunities” view displays all sales opportunities assigned to the logged-in sales representative without requiring customization. However, every organization has unique needs – this is where custom views come into play.

Custom Siebel Views and Why They’re Used

Custom views are tailor-made screens that organizations configure or develop in Siebel to address specific requirements not met by the standard views.

Siebel is highly customizable: using Siebel Tools (the configuration/development utility), administrators can create new views, add fields, or combine information from multiple modules into one view.

Organizations create custom views for several reasons:

• Unique Data Requirements: For instance, adding custom fields or tables and wanting to display them. If the standard Contact view doesn’t show a needed data field (such as a custom “Customer Segment” field), a new view may be built to include it or to combine data differently.
• Industry-Specific Workflows: Different industries often have specialized processes. A healthcare company might need a view for patient data tracking, or a bank might add a custom credit risk view – screens not provided out-of-the-box.
• Improved User Productivity: Custom views can streamline workflows by bringing together information relevant to a user’s role. For example, a custom dashboard view might aggregate a customer’s profile, recent orders, and support tickets all on one screen for a 360° view, even if this spans multiple Siebel modules.
• Integrations and Reports: A custom view may display data from an external system or an advanced report (such as a BI dashboard) within Siebel’s UI, providing users with a seamless experience.

Example: A pharmaceutical company might create a Regulatory Compliance custom view to track drug trial data alongside customer data – something standard Siebel doesn’t directly provide. Or an enterprise might build a Global Customer Summary view that pulls account data across Siebel Sales and Siebel Service modules into one place.

Custom views are essential for user adoption and business fit, but they must be designed with licensing in mind. Just because you can configure it doesn’t mean you automatically have the right to use all the data or features it presents – that’s where Oracle’s licensing rules come in.

Siebel Licensing Basics (On-Premises)

Oracle Siebel is traditionally licensed as on-premises software (perpetual licenses plus annual support).

Unlike modern SaaS apps, Siebel is not a simple subscription – you purchase a license for each user or processor and then pay yearly support (typically 22% of license cost) for updates and support.

Understanding the licensing metrics and models is critical:

• Application User License: This is the most common metric for Siebel. An Application User means a named individual authorized to use the Siebel software. Every employee or internal user who logs into Siebel must have an Application User license for each Siebel module or product they use. This metric is independent of actual usage – even if a user logs in only once a month, if they are authorized to access, a license is required. (In Oracle’s terminology, this is similar to a “Named User” license.)
• Module-Based Licensing: Siebel CRM is a modular system. You license a base application and then any additional modules (like Siebel Marketing, Siebel Analytics, or industry-specific modules). Each module license is typically an add-on per user. For example, if you have 50 users and want to deploy the Marketing module in addition to the base Sales module, you need 50 licenses of Siebel Marketing as well (one for each user). Users only get rights to the modules you’ve licensed for them.
• Other Metrics: In some cases, other licensing models exist: Concurrent User (shared login pools) were offered historically but are less common now; Processor or Server licensing allows unlimited user access on a given server and is used when user counts are uncertain or for external-facing scenarios (e.g., customer self-service portal). There are also Enterprise licenses or Unlimited agreements where an organization negotiates rights for broad use (often as part of an enterprise agreement). However, most Siebel customers use user-based licenses.
• External Users: Oracle distinguishes between internal users (employees/agents) and external users (partners and customers). External users may use a different metric (such as Registered User or a CPU license for a public-facing portal) because it may not be practical to license each customer individually. It’s important to use the correct type; for instance, partners or customers should not be covered under cheaper internal user licenses – that would violate contract terms.

On-Premise Licensing Implications: When you buy Siebel licenses, you’re buying the right to deploy the software on your servers (or cloud infrastructure you manage) and allow a certain number of users or processors to use it. The “on-premises” nature means you have flexibility in deployment but also responsibility to ensure compliance.

Oracle typically does not enforce license counts through a technical kill switch – all modules and features can be enabled in the software.

Compliance is audited via contracts and audits, not automatic blocks. This puts the onus on the customer to restrict access appropriately.

Licensing Implications of Views & Custom Views

Siebel’s licensing is directly tied to the functionality a user can access, which often correlates with the views they can see.

A fundamental principle is: if a user has access to a view that belongs to a certain module, that user must be licensed for that module. This holds for custom views as well:

• Standard Views: Generally, standard views delivered with Siebel are covered under the base modules you’ve licensed. For example, if you purchased the Siebel Sales module for 100 users, those users can access all standard Sales-related views (accounts, opportunities, forecasts, etc.) as part of that license. Standard views for modules you didn’t buy should not be given to users. (Siebel doesn’t automatically hide them – administrators must configure responsibilities properly. If a standard view from an unlicensed module is assigned to someone, that’s a compliance gap.)
• Custom Views within Licensed Scope: If you create a custom view that only uses data and functions from modules you have, there’s no additional license needed just for creating the view. Oracle doesn’t charge “per view” or for customizing per se. However, you must ensure every user accessing that custom view has a license for the underlying modules. For instance, a custom view that consolidates Account (Sales) data and Service Requests (Service) data requires that those users have both the Sales and Service module licenses. In effect, the custom view is bridging two areas, and licensing must cover the full scope. Most companies already license core modules for their users, so an internal custom mash-up doesn’t inherently cost more unless it requires the addition of a new module.
• Custom Views that Introduce New Modules: Problems arise if a custom view pulls in functionality from a module your organization hasn’t licensed. For example, suppose your company licenses only the base CRM (Sales and Service) modules. Still, a developer builds a custom analytical dashboard within Siebel that utilizes Siebel Analytics or BI functionality (which may technically be available for configuration). Or a custom Marketing Campaign view is created even though you didn’t buy Siebel Marketing. In these cases, Oracle would consider this unlicensed usage. All users with access to that view would need to be retroactively licensed for the Siebel Analytics or Marketing module. This can lead to surprise costs in an audit. Bottom line: Customizing Siebel doesn’t bypass licensing – if the custom feature touches another product area, you need the license for it.
• Responsibilities and View Access: Since user roles (and their associated responsibilities) control view access, managing these roles is how you control licensing exposure. Best practice is to only grant users the views (and thus the modules) they truly need. For instance, if only the marketing team should have Marketing views, ensure no other roles include those views. If you create a custom view for a specific department, limit its assignment to those users, and verify that their licenses cover it. It’s wise to map each view (especially custom ones) to the Oracle product modules it falls under.

A conversational example:

Think of Siebel modules like rides at a theme park (Sales, Service, Marketing are different “rides”). Your license is like a ticket for each person for specific rides. Standard views are the paths to the rides.

A custom view might combine two rides into one experience, but then your ticket needs to cover both. If you accidentally build a new ride (feature) without buying a ticket for it, the park staff (Oracle auditors) won’t be happy if they catch you using it.

Common Compliance Pitfalls in Siebel Licensing

Oracle’s licensing audits often reveal similar mistakes across Siebel customers. CIOs and IT asset managers should be aware of these common pitfalls so they can avoid them:

• Not Removing Inactive Users: Siebel’s Application User licensing counts every individual authorized in the system, across all environments. A classic mistake is failing to end-date or delete user accounts when employees leave or roles change. For example, if 50 users left the company but remain active in Siebel, an audit would still count those 50 as requiring licenses. This leads to over-licensing (paying for users who aren’t there) or non-compliance if you don’t have enough purchased licenses to cover them. Always conduct periodic user clean-ups.
• Unlicensed Module Access (via Mistaken Configuration): As mentioned, Siebel doesn’t technically prevent admins from granting access to modules you didn’t buy. An admin might unknowingly enable a view from another module, or a custom view might tap into an unlicensed area. During an audit, Oracle’s scripts will detect usage of objects from all modules (e.g., tables or functionality related to Marketing or Analytics). If they find you’ve been using an unlicensed module, they will require you to purchase licenses for it (often for all users who had access) plus back-support fees. This can be an extremely expensive surprise. The fix is strict control: lock down access to only licensed modules and regularly review any customizations for compliance.
• All Environments Must Be Licensed: Many assume that development, test, or disaster recovery environments are exempt from licensing, but Oracle’s policy for on-premises software is that each environment requires licensing (unless contractually exempt). If you have a separate test Siebel installation with users who are not part of production, those users or that server also need to be covered by licenses. Oracle sometimes provides special terms (e.g., free DR if used only in failover, or a discounted sandbox license), but you must negotiate these terms. Don’t assume non-production use is excluded from licensing requirements.
• Mixing License Metrics Improperly: Be cautious when using a combination of user-based and processor licenses. Oracle expects a given Siebel deployment (for a module) to use one metric or a well-defined separation. For example, you cannot cover 100 users with user licenses and then try to cover an additional 50 users by purchasing one processor license on the same instance – it doesn’t work that way. In audits, Oracle will typically apply the stricter interpretation (often treating the entire environment under the processor metric if any processor license is present). The safest approach is to stick to one metric per module/environment, or have a clear division of usage.
• Incorrect User License Type (Internal vs External): If partners or customers access your Siebel system (say a partner portal or customer service portal), you must use the appropriate licensing (like Oracle’s External or Registered User licensing, or a processor metric). A compliance issue arises if, for example, 50 business partners were given logins and you just counted them as regular employees under your internal user licenses. Oracle’s audit will flag non-employees using employee licenses as a violation. Always classify users properly and purchase the right type of license for external user access.

These pitfalls can result in hefty penalties or forced purchases. The table below summarizes a few risks and their impact:

Managing Siebel Views and License Compliance

To maintain compliance and control costs, organizations should proactively manage Siebel views and user access.

Here are the best practices in a Gartner-like advisory style for CIOs and IT managers:

• Map Views to Modules: Maintain an internal mapping of which Siebel module each view (standard or custom) falls under. This clarifies which licenses are required when assigning a view to a user. For custom views, explicitly document which underlying tables or functions are used. E.g., if a custom view includes fields from the Siebel Service module and an Analytics component, mark those modules.
• Role-Based Access Control: Regularly review the responsibilities (roles) in Siebel. Align each role’s view access to the minimum necessary for that job function (“least privilege” principle). By tightening roles, you prevent users from inadvertently getting access to features they shouldn’t. This not only improves security and usability but also keeps licensing scope in check (no needless access to licensed features they don’t need).
• Internal License Audits: Treat license compliance as an ongoing process, not just a once-a-year task. Set up a quarterly or bi-annual audit routine: extract a list of all active Siebel users and their last login dates, list all views/modules enabled, and compare against your purchased licenses. This internal audit can catch issues early, for instance, spotting if a new custom view might be using an unlicensed module before Oracle does. Oracle License Management Services (LMS) provides scripts – you can run similar checks yourself to see what they would find in an official audit.
• Governance for Customizations: Establish a governance process for any new customization (like adding a view or integrating with another system). Include a licensing impact assessment as part of the change management. For example, before deploying a new custom view, have a checklist: “Does this use any module or feature we’re not currently licensed for? If yes, what is the plan – purchase a license or redesign the solution?” This ensures IT and procurement are aligned.
• Education and Awareness: Ensure your Siebel administrators and developers are knowledgeable about licensing constraints. Many compliance issues arise simply because a well-meaning administrator enabled something without realizing the licensing implications. Conduct briefings or include licensing guidance in the Siebel development guidelines. A culture of awareness can prevent mistakes (e.g., a developer will know to double-check before using that fancy Siebel Marketing feature in a custom view if the Marketing module isn’t licensed).
• Contract Clauses and Support: When negotiating with Oracle (whether for initial purchase or renewals), seek clarifications or special terms in the contract for any ambiguous areas. For instance, if you want to use a secondary test environment, negotiate a clause for free or reduced-cost test licenses. If you foresee heavy customizations, obtain written clarity on what is allowed under your license. Also, remember to budget for the 22% annual support on all licenses – this cost doubles the spend over ~5 years. It may be possible to negotiate slight reductions or consider third-party support if appropriate (though third-party support means no upgrades – a risk to evaluate).

By actively managing views and access, you not only stay compliant but also can optimize license usage.

For example, if you discover 20% of licensed users haven’t logged in for 6 months, you might reclaim those licenses or at least not buy more until needed. Likewise, if a custom view is only used by five users, perhaps only those five need a specific module license, rather than all 100 users, as long as you restrict the view to those five via roles.

Siebel Licensing Cost Overview

Oracle’s price list for Siebel (as of 2024) provides insight into the cost of these licenses. Below is a summary of typical list prices for Siebel CRM (on-premise) licensing and an example calculation:

• Siebel CRM Base Application License: Approximately $3,750 per Application User (perpetual license). This base license is required for each user and grants access to core CRM functionality (accounts, contacts, opportunities, etc.). Every Siebel user usually needs this base license.
• Industry Module License Add-ons: About $400 per user for each industry-specific base module. Oracle offers specialized CRM modules for various industries, including Financial Services, Communications, Life Sciences, and Public Sector. If you use one, it’s an add-on cost on top of the base. For example, a bank using Siebel Financial Services would pay an extra $400 for each user to access those finance-specific features.
• Other Add-on Modules: There are other optional modules (for example, Siebel Marketing, Siebel Analytics). Their pricing can vary, but they are typically also licensed per user in a similar manner (some add-ons may cost a few hundred dollars per user). Specialized tools like Siebel Tools (a development environment) may have unique pricing (e.g., approximately $20,000 per developer seat license), which is noteworthy if you have a development team customizing the system.
• Annual Support Costs: In addition to the upfront license purchase, Oracle charges annual support at 22% of the license fees. This is a recurring event to receive updates and support. While optional, dropping support means you can’t get new patches or versions, and reinstating support later incurs heavy penalties. Over 5 years, support fees will roughly equal the initial license cost. For budgeting, a $3,750 user license costs about $825 per year in support. Therefore, a user effectively costs approximately $4,575 in the first year (license + support) and $825 each subsequent year in maintenance.

Real-World Pricing Example: Suppose a mid-size company needs 100 Siebel users for Sales and also wants the Financial Services industry module:

• Base licenses: 100 users × $3,750 = $375,000 one-time license cost.
• Industry module licenses: 100 × $400 = $40,000 one-time (to add Financial Services features for those users).
• Total initial license spend = $415,000 for 100 users with that module at list price.
• Annual support = 22% of $415,000 = $91,300 per year. (Budget this every year to stay supported.)

Over a typical 5-year period, this customer would pay $ 415,000 + (5 × $ 91,300) ≈ $871,500 in total for licenses and support for 100 users. Siebel is a significant investment. Enterprise customers often negotiate discounts (e.g., 20% or more off), especially for large purchases.

The larger the user count, the more negotiation leverage you have – Oracle’s list prices are high to start with. It’s common for a big deal to close at a substantial discount, and support fees would then be 22% of the discounted price.

Cost Control Tip: Only license what you need and plan for growth. If you anticipate scaling from 100 to 500 users in a few years, consider negotiating pricing tiers or securing future credits upfront.

Oracle sometimes offers enterprise licenses or broader agreements if you commit to bigger usage (or an Unlimited License Agreement for a fixed fee).

On the other hand, if your user count is expected to drop or you plan to phase out Siebel, be cautious when entering long-term contracts. Always align licenses purchased with actual usage to avoid shelfware.

Recommendations

• Audit User Access Regularly: Conduct quarterly reviews of all Siebel user accounts. Remove or end-date access for any users who no longer need it (e.g., former employees) to prevent over-licensing and compliance issues.
• Limit Unneeded Views: Revisit the roles/responsibilities to ensure users have access only to the views (and thus modules) required for their job. Eliminating unnecessary view access can reduce licensing exposure to unneeded modules.
• Map and Document Custom Views: For every custom view or customization, document which Siebel modules or additional Oracle products it touches. Use this to ensure you have corresponding licenses. This mapping should be part of the design process for new features.
• Train Admins and Developers: Invest in training your Siebel administrators and developers on Oracle’s licensing policies. Ensure they understand that enabling a new module or building certain custom features can have licensing implications. An educated team will make decisions that keep you compliant.
• Negotiate Proactively: When engaging with Oracle (for new purchases or renewals), negotiate terms that address common gaps – e.g., include a clause for test environments or obtain flexibility for a future module you plan to evaluate. Also, aim for discounts on large user counts and lock in pricing for anticipated growth if possible.
• Use License Tools: Utilize Oracle’s LMS scripts or third-party tools to monitor Siebel usage. These can help identify if any unlicensed modules are being accessed or if user counts exceed entitlements before Oracle comes knocking. Early detection allows you to correct course or budget for additional licenses in a controlled way.
• Consider Processor/External Licensing for Portals: If you have a scenario with many external users (such as a customer self-service portal via Siebel), consider a processor-based license or special external user licenses instead of standard user licenses. This can be more cost-effective and compliant for large volumes of external access.
• Keep Contracts and Proofs in Order: Maintain an organized archive of your Oracle Siebel license agreements, proofs of entitlement, and any Oracle correspondence. In the event of an audit or vendor discussion, you’ll need to quickly demonstrate what you own and any special terms.
• Plan for Support Costs: Budget for the 22% annual support, and periodically assess if you need all the licenses you’re paying support for. If your usage drops, you might be able to terminate and save on support (though be mindful of support reinstatement rules). Also, evaluate third-party support options if you’re in a steady state and need to cut costs, but weigh the trade-offs (no upgrades).

Checklist: 5 Actions for Siebel License Compliance

• User Cleanup: Identify all Siebel user accounts across production and test systems. Deactivate any unused or obsolete accounts and ensure a process is in place to remove access when staff leave or change roles.
• Custom View Inventory: List out every custom view or custom module in your Siebel implementation. For each, verify which Oracle Siebel modules or components it utilizes. Check these against your license entitlements to confirm you’re covered.
• Role and View Review: Review each Siebel responsibility (role) to see what views it grants. Ensure that no role inadvertently grants access to a module you haven’t licensed. Adjust responsibilities so that each corresponds closely to a specific set of licensed functions.
• Environment Licensing Check: Take stock of all environments (dev, QA, DR). Ensure that licenses are allocated for these environments or that explicit contract allowances are in place. If not, plan to license non-prod environments or seek clarification/amendment with Oracle to avoid audit issues.
• Internal Audit Schedule: Mark your calendar for a periodic internal licensing audit (for example, every 6 months). During each internal audit, run usage reports: check active user counts vs. licenses owned, modules accessed, and any new customizations introduced. Address any discrepancies immediately, before an official Oracle audit or renewal.

FAQ

Q1: Does creating a custom view in Siebel require extra licenses from Oracle?
A1: Not by itself. You don’t pay specifically for “creating a view.” However, what the custom view contains can trigger licensing needs. If the custom view uses only features of modules you’ve already licensed (and all users accessing it are licensed for those), no additional license is needed. If it pulls in functionality from an unlicensed module (for example, a custom analytics view when you haven’t licensed Siebel Analytics), then yes, you would need to purchase licenses for that module for the users of the view.

Q2: How can I tell which Siebel module a particular view is associated with?
A2: Oracle’s documentation and Siebel Tools can help here. Generally, views are grouped under screens that correspond to modules (e.g., Sales, Service, Marketing). A view like “Opportunity List” is part of the Sales module. A view called “Service Request Detail” is part of the Service module. For custom views, you determine it by the data and business components used: if your custom view displays or edits data from a specific Siebel module’s tables, it’s tied to that module’s license. It’s a good practice to maintain an internal catalog of views with notes on associated modules.

Q3: Is Siebel CRM available as a cloud (SaaS) service or only on-premises?
A3: Siebel CRM is primarily an on-premises application, deployed on your own servers or cloud infrastructure (such as Oracle Cloud or AWS) that you manage. Oracle does not offer Siebel as a SaaS subscription in the way Salesforce or Oracle’s Fusion Cloud CRM is offered. You buy perpetual licenses for Siebel. (Oracle did have “Siebel CRM OnDemand” historically as a hosted service, but Oracle’s strategic cloud CRM offering now is the Oracle Fusion CX suite, not Siebel.) So, for Siebel, assume on-prem licensing rules – you’re responsible for compliance. You can run Siebel on cloud VMs, but licensing is still your responsibility (bring-your-own-license).

Q4: What happens during an Oracle license audit for Siebel?
A4: In an audit, Oracle’s License Management Services will typically ask you to run scripts or provide data from your Siebel system. They will collect: the number of user accounts, lists of responsibilities and views those users have, which modules are enabled or have data in use, and server info if processors are licensed. They will match this against your entitlements (the licenses you’ve purchased). If they find, for example, 120 users in the system but you purchased only 100 user licenses, they’ll flag a shortfall. Or if data indicates you used a module you didn’t buy, that’s a non-compliance issue. The result is usually a report that requires you to purchase additional licenses, plus backup support for the period of unlicensed use. The best defense is to perform internal audits beforehand and rectify issues (such as cleaning up users and removing access to unlicensed features) proactively.

Q5: Can we mix user and processor licenses for the same Siebel deployment to save money?
A5: Typically, no, you should avoid mixing metrics for the same product instance without explicit agreement. Oracle’s policy is one primary metric per environment or module. If you try to cover a base set of users with Application User licenses and then add a Processor license to cover extra usage, it can lead to compliance confusion. In practice, if both types exist, Oracle might consider the entire deployment as processor-licensed (and still enforce minimum user counts per processor). It’s safer to choose one metric. Suppose you have a scenario where internal users are well-known (via user licenses) but an external portal is also accessing the same instance (which might require processor licensing). In that case, it’s best to separate them logically or negotiate terms with Oracle that delineate usage. When in doubt, consult with Oracle or a licensing expert before mixing licensing models – otherwise, you might accidentally invalidate your user licenses or face an audit dispute.