> ## Documentation Index > Fetch the complete documentation index at: https://docs.germainux.com/llms.txt > Use this file to discover all available pages before exploring further. # Outlier Detection for Oracle Siebel CRM (Configuration) > GermainUX detects unusual behavior in Oracle Siebel CRM that may be hidden within large volumes of normal user, application, and business-process data. Components `GermainUX Engine Service: GermainUX Analytics Feature availability for Siebel: GermainUX 2023.2 or later` [`Engine`](https://docs.germainux.com/main/germain-ux-engine) [`JS Profiler`](https://docs.germainux.com/main/germain-ux-js-profiler) [`Mobile App`](https://docs.germainux.com/main/germain-ux-mobile-app) [`RPA Bot Recorder`](https://docs.germainux.com/main/germain-ux-rpa-bot-recorder) [`RUM JS`](https://docs.germainux.com/main/germain-ux-rum-js) Availability 2014.1 or later > [card] [Detection mechanisms](#detection-mechanisms) > > Combining methods for coverage > [card] [Select Siebel KPIs to analyze](#select-siebel-kpis-to-analyze) > > Starting with outcome-linked KPIs > [card] [Examples](#examples) > > Sample outlier scenarios > [card] [Troubleshooting](#troubleshooting) > > Resolving detection issues **Configure Outlier and Anomaly Detection for Oracle Siebel CRM** GermainUX detects unusual behavior in Oracle Siebel CRM that may be hidden within large volumes of normal user, application, component, error, and business-process data. It can help identify: * A new error among recurring errors * An abnormal increase in Object Manager response time * A component using an unusual percentage of its task capacity * A sudden increase in crashes * A workflow becoming slower than its historical baseline * An unexpected decline in user activity > [accordion] Show all 9 > > * A Siebel server behaving differently from comparable servers > * A record or process that stops progressing > * An issue affecting one team, region, browser, server, or application version ## Outlier, anomaly, and SLA violation These terms describe different conditions. | Term | Meaning | Siebel example | | - | - | - | | **Outlier** | An individual value differs significantly from comparable observations. | One Object Manager request takes 45 seconds when similar requests normally take two seconds. | | **Anomaly** | A pattern, trend, spike, decline, or segment deviates from expected behavior. | Service Request completion time rises abnormally for one team during the current week. | | **SLA violation** | A value crosses a predefined business or technical threshold. | Object Manager task utilization exceeds 95%. | | **New category** | An event signature has not previously been observed. | A new Siebel crash stack trace appears for the first time. | A condition can satisfy more than one definition. For example, a response-time spike can be both statistically anomalous and above its SLA. ## Detection mechanisms No single method detects every type of unusual Siebel behavior. Combine the mechanisms appropriate to the monitored data. | Mechanism | Primary purpose | Siebel example | | - | - | - | | **Smart Insights** | Detect statistically meaningful changes relative to expected behavior | Response time becomes abnormal compared with the same business period | | **Categorization** | Group similar events and distinguish new patterns from known ones | Identify a new Object Manager error or crash signature | | **Error Analysis** | Prioritize errors according to user and business impact | Surface an error interrupting a critical workflow | | **Document Audit** | Track record changes and time spent in each state | Detect Service Requests that stop progressing | | **Fixed SLAs** | Detect breaches of defined operational limits | Component task utilization exceeds 95% | | **KPI relationships** | Identify related changes that may explain an anomaly | Correlate slow user clicks with HTTP, Object Manager, and database degradation | See [Outlier and Anomaly Detection](https://docs.germainux.com/main/outlier-detection.md). ## Prerequisites Before enabling anomaly detection: * Deploy and connect the GermainUX Engine. * Configure the required Siebel data sources. * Confirm that the selected KPIs receive consistent data. * Verify application, environment, server, and component dimensions. * Collect sufficient representative historical data. * Identify normal business periods and maintenance windows. > [accordion] Show all 9 > > * Configure error and crash categorization where applicable. > * Define who will investigate and respond to detected anomalies. > * Confirm that detected conditions can be validated against raw instances. An unreliable or incomplete source KPI will produce unreliable anomaly results. ## Select Siebel KPIs to analyze Begin with KPIs tied to meaningful operational or user outcomes. ### User-experience KPIs Examples include: * Siebel user-click duration * Page, screen, or view performance * Network-request duration * Browser errors * User-facing application errors * Session duration > [accordion] Show all 10 > > * Business-process duration > * Process-step duration > * Workflow overrun > * Abandonment or timeout ### Application and component KPIs Examples include: * Component availability * Component run state * Running tasks * Task-utilization percentage * Tasks per process * Active MTS processes > [accordion] Show all 12 > > * MTS-process utilization > * Server Manager response > * HTTP and SISNAPI availability > * Object Manager errors > * Log-error volume > * Crash volume ### Infrastructure and database KPIs Examples include: * CPU * Memory * Disk * Network * Database response time * Connection or session volume > [accordion] Show all 9 > > * SQL duration > * Query volume > * Integration response time Avoid enabling anomaly detection indiscriminately on every available KPI. Start with KPIs for which an unexpected change would require investigation or action. ## Establish a baseline Smart Insights requires representative historical behavior. The baseline should include: * Normal business days * Busy and quiet periods * Weekday and weekend differences * Regular batch or maintenance activity * Seasonal patterns * Expected regional differences * Normal application releases when appropriate * Representative user and transaction volume Do not establish a baseline using only: * An outage * A load test * A migration period * An unusual business event * An incomplete deployment * A period with missing data Wait until monitoring is stable before treating statistical results as operational alerts. ## Use business-period comparisons Siebel activity often follows predictable time patterns. Compare current behavior with the appropriate historical period, such as: * Same time on previous business days * Same weekday in previous weeks * Current business hour versus equivalent business hours * Month-end versus prior month-end periods * Peak contact-center hours versus previous peak periods Comparing Monday morning with Sunday night can produce an apparent anomaly that is simply normal business behavior. ## Select dimensions Dimensions help determine whether an anomaly affects the entire environment or one segment. Useful Siebel dimensions include: * Application * Environment * Enterprise * Server * Component * Object Manager > [accordion] Show all 20 > > * Screen > * View > * Applet > * User > * Team > * Role > * Department > * Region > * Browser > * Application version > * Business process > * Process step > * Error category > * Integration endpoint Avoid dimensions with excessive cardinality unless the analysis requires instance-level detail. Extremely granular segmentation can create insufficient data per segment and unstable results. ## Configure Smart Insights Configure Smart Insights for the selected KPI and measure. For each configuration: **1. Select the KPI** **2. Select the measure to analyze** **3. Define the application and environment scope** **4. Add the dimensions required for segmentation** **5. Select the relevant business-period comparison** **6. Exclude planned maintenance and nonrepresentative periods** **7. Allow sufficient time to establish a baseline** **8. Review detected increases, decreases, spikes, and deviations** **9. Validate results against individual facts** **10. Configure alerts only after the detection quality is acceptable** Useful measures include: * Count * Average * Median * Percentile * Maximum * Error rate > [accordion] Show all 11 > > * Availability percentage > * Unique users > * Completion rate > * Overrun > * Task-utilization percentage Use percentiles instead of averages when a small group of slow transactions would otherwise be hidden. ## Configure categorization Categorization is appropriate for high-volume events with repeated signatures, including: * Object Manager errors * JavaScript exceptions * User-facing errors * Crashes * Log messages * Failed transactions It helps answer: * Is this issue new or known? * How often does this category occur? * Is its frequency increasing? * Which users, applications, or components are affected? * Did the category appear after a release? Normalize variable values such as record IDs, usernames, timestamps, and transaction identifiers before generating categories. See: | Resource | Link | | - | - | | Error Monitoring for Oracle Siebel CRM | [Error Monitoring for Oracle Siebel CRM (Configure)](https://docs.germainux.com/main/siebel-error-monitoring-configuration.md) | | Crash Monitoring for Oracle Siebel CRM | [Crash Monitoring for Oracle Siebel CRM (Configure)](https://docs.germainux.com/main/siebel-crash-monitoring-configuration.md) | ## Configure Document Audit Use Document Audit when the unusual condition involves a Siebel record or business object rather than a technical metric. Examples include: * A Service Request remains in one status for too long. * An Order changes to an unexpected status. * A record is updated unusually often. * Customer data stops synchronizing. * A process skips a required status. * A record changes outside the expected workflow. Document Audit can retain: * Record identifier * Changed field * Previous value * New value * Change timestamp * User or process responsible, when available * Time spent in a status Combine the audit data with Smart Insights to detect abnormal volumes, missing changes, or unusual status durations. ## Combine detection methods | Investigation goal | Recommended combination | | - | - | | Find a new Siebel error | Categorization and Error Analysis | | Detect an abnormal error spike | Categorization and Smart Insights | | Identify a new crash pattern | Crash categorization and Smart Insights | | Detect slow Object Manager performance | Smart Insights, fixed SLA, and KPI relationships | | Find components approaching capacity | Fixed SLA and Smart Insights | | Detect a workflow slowdown | Business-process monitoring and Smart Insights | | Find processes that stop progressing | Document Audit and Smart Insights | | Identify errors blocking users | Error Analysis, categorization, and Session Replay | | Explain an abnormal KPI | Smart Insights, related KPIs, and instance-level analysis | ## Configure fixed SLAs Statistical anomaly detection complements rather than replaces fixed thresholds. Use fixed SLAs for conditions with a known operational boundary, such as: * Component unavailable * HTTP endpoint unavailable * Task utilization above 95% * Critical error detected * Crash detected * Process duration exceeding a committed target Use Smart Insights when the expected value changes by business period or when no single static threshold represents normal behavior. ## Configure alerts Alert only when the detected condition requires action. An alert should include: * KPI and measure * Current value * Expected or baseline value * Direction and magnitude of the deviation * Affected application and environment * Affected server, component, user group, or workflow > [accordion] Show all 10 > > * Number of affected users or instances > * Related errors and KPIs > * Link to the corresponding analysis > * Recommended owner Consider requiring persistence or multiple observations before alerting on noisy metrics. Do not delay alerts for immediate conditions such as a critical component outage or a new high-impact crash. Use maintenance periods to suppress expected deviations during planned work. ## Validate the configuration Before relying on anomaly alerts: **1. Review several detected anomalies manually** **2. Confirm that the source data is complete** **3. Compare the detected period with the correct business period** **4. Review the underlying raw instances** **5. Confirm that the dimensions identify the affected segment** **6. Determine whether the change is operationally meaningful** **7. Check for releases, maintenance, holidays, or volume changes** **8. Verify that related KPIs support the finding** **9. Adjust the scope or comparison period if false positives are excessive** **10. Test alert routing** Do not treat every statistical deviation as a defect. A change can be valid, expected, or beneficial. ## Investigation workflow When GermainUX detects unusual Siebel behavior: 1. **Detect** the condition through Smart Insights, categorization, Error Analysis, Document Audit, or an SLA. 2. **Quantify** its magnitude, duration, frequency, affected users, and business impact. 3. **Segment** by application, server, component, user group, process, region, browser, or version. 4. **Correlate** the anomaly with related KPIs and events. 5. **Inspect** representative instances in the Analysis Dashboard. 6. **Replay or trace** an affected user session, workflow, request, or server transaction. 7. **Identify** the likely technical or process cause. 8. **Correct** the issue. 9. **Verify** that the KPI returns to its expected range. 10. **Document or automate** the response for future occurrences. ## Examples ### Abnormal Object Manager response time GermainUX detects that one Object Manager is slower than its historical baseline. Investigate: * Server and component * Task utilization * Active MTS processes * Error volume * Database response * Integration activity * Affected screens and users * Recent releases or configuration changes ### New crash spike GermainUX identifies a new crash category and an abnormal increase in its frequency. Investigate: * Stack-trace category * Affected Object Managers * First occurrence * Recent deployment * Related error codes * Affected users and sessions * FDR and core evidence ### Workflow slowdown A Service Request process remains within its fixed SLA but is significantly slower than its historical baseline for one team. Investigate: * Slow process steps * User and team * Screen and view * User validations * Repeated activity * Related browser and server errors * Session Replay ## Troubleshooting ### Too many anomalies Review: * Baseline quality * Comparison period * KPI stability * Maintenance exclusions * Segmentation cardinality * Minimum data volume * Recent releases * Normal seasonal behavior ### No anomalies are detected Verify: * The KPI receives data. * Smart Insights is enabled. * The correct measure is selected. * Enough historical data exists. * The configured application and environment match. * Filters are not excluding all data. * The analysis period contains activity. ### Expected business peaks generate alerts Use a business-period comparison that includes the same expected peak and exclude special events that should not become part of the normal baseline. ### A detected anomaly has no user impact Determine whether it still represents a capacity, reliability, compliance, or future-risk issue. If it does not require action, reduce its priority or remove the alert while preserving the insight for analysis. ## Related Documentation > [card] [Dashboard & Reports](https://docs.germainux.com/main/dashboard-and-report.md) > > Dashboard & Reports > [card] [AI](https://docs.germainux.com/main/ai-driven-insights.md) > > Insights & Recommendations > [card] [Analytics](https://docs.germainux.com/main/analytics.md) > > More Analytics Features > [card] [Automation](https://docs.germainux.com/main/automation.md) > > More Automation Features ## Get Help > [card] [Contact GermainUX Support](https://docs.germainux.com/main/support.md) > > The GermainUX team helps you get up and running faster, empower your team, turn data into actionable insights, and optimize performance to deliver measurable business outcomes. > [card] Can't find what you need? > > Search all GermainUX docs with **Ctrl + K**, or use the feedback buttons at the bottom of this page to tell us what is missing. The content of this document is proprietary to GERMAIN SOFTWARE. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.