Results for “cs_sr_uwq_emp_count_v”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

CS_SR_UWQ_EMP_COUNT_V is a read-only database view owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It is delivered as part of the CS (Service) product family and is designated VALID in the ETRM registry. The view is purpose-built for the Universal Work Queue (UWQ), the consolidated agent desktop used by service representatives to manage inbound work items across channels. Its specific function is to resolve the population of open Service Requests (incidents) that are assigned to the currently logged-in resource, so that UWQ can display an accurate count of pending work against that user.

Unlike the primary UWQ result views, which return rich rows for grid display, this view is optimized for aggregation. It exposes a narrow projection of incident attributes from which UWQ issues count-style queries filtered by resource, status, or severity. Because the view is defined over a secured base object, it transparently inherits row-level security, ensuring that a representative sees only those incidents that the security model permits.

Underlying Base Objects

The view is defined over a single documented base object: CS_INCIDENTS_B_SEC, which is itself a view rather than a physical table. The _B_SEC suffix indicates that this object is the secured projection of the CS_INCIDENTS_B incident header. Security policies applied at that layer restrict the visible rows according to the Service Request security profile of the querying user, so CS_SR_UWQ_EMP_COUNT_V does not need to re-implement any filtering logic itself.

The defining query is a straightforward selection from that base object. It applies two predicates: STATUS_FLAG = 'O', which limits the result to open incidents, and RESOURCE_TYPE = 'RS_EMPLOYEE', which restricts the population to incidents owned by an employee resource rather than, for example, a group or organization. The remaining SELECT list simply renames or passes through the incident identifiers needed by UWQ. No joins, unions, or aggregation clauses appear in the view text; counting is performed by the consuming query rather than inside the view definition.

Key Columns

• INCIDENT_ID — The unique surrogate key of the Service Request header. Used by UWQ to link a count back to an individual record when a drill-down is requested.
• INCIDENT_NUMBER — The user-facing Service Request number displayed to agents.
• INCIDENT_STATUS_ID — Foreign key to the incident status reference data; supports status-based grouping or filtering of counts.
• RESOURCE_ID — The resource to whom the incident is assigned. In the view text this is sourced from INCIDENT_OWNER_ID and aliased as RESOURCE_ID, making it the effective filter column for "logged-in user" queries.
• RESOURCE_TYPE — The type of the owning resource. The view hard-codes this to RS_EMPLOYEE in its WHERE clause, so every returned row carries this value.
• OWNER_ID — A second alias of INCIDENT_OWNER_ID, retained for backwards compatibility with UWQ code paths that reference the owner rather than the resource.
• INCIDENT_SEVERITY_ID — Foreign key to severity reference data, enabling counts to be broken down by urgency.

Common Use Cases and Queries

The principal scenario is the UWQ agent dashboard, where the count of open, employee-owned incidents is retrieved for the session user. A representative ad-hoc query mirrors that pattern by joining to the resource table to translate a login into a resource identifier and then counting the rows returned by the view.

For a direct count for a known resource:

• SELECT COUNT(*) FROM apps.cs_sr_uwq_emp_count_v WHERE resource_id = :resource_id;

To break the count down by severity for a given agent:

• SELECT incident_severity_id, COUNT(*) FROM apps.cs_sr_uwq_emp_count_v WHERE resource_id = :resource_id GROUP BY incident_severity_id;

To resolve the resource from an FND user and count in a single statement:

• SELECT COUNT(*) FROM apps.cs_sr_uwq_emp_count_v v, apps.jtf_rs_resource_extns r WHERE v.resource_id = r.resource_id AND r.user_id = :user_id;

Because the view already restricts results to open incidents and employee resources, consumer queries should not reapply those predicates unless explicitly overriding intent. Any custom use should respect the secured base object, as row visibility is governed by the incident security profile rather than by privileges on the view itself.