Skip to main content
ComponentsGermainUX Engine Service: GermainUX Analytics Feature availability for Siebel: GermainUX 2023.2 or laterEngineJS ProfilerMobile AppRPA Bot RecorderRUM JS
Availability2014.1 or later

Detection mechanisms

Combining methods for coverage

Select Siebel KPIs to analyze

Starting with outcome-linked KPIs

Examples

Sample outlier scenarios

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
  • 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. 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. See Outlier and Anomaly Detection.

​
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.
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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:

​
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

​
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
  • 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.

Dashboard & Reports

Dashboard & Reports

AI

Insights & Recommendations

Analytics

More Analytics Features

Automation

More Automation Features

​
Get Help

Contact GermainUX Support

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.

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.