Search Results esc_level_name




Overview
Explore in AI Chat

Overview

APPS.CSF_ESC_TASKS_V is a reporting and integration view in Oracle E-Business Suite that exposes task records from the CRM Task Manager (JTF) schema together with decoded, human-readable escalation and status information. Its most distinctive characteristic is that it resolves coded foreign key values into descriptive names. In particular, the column esc_level_name is derived by joining the numeric escalation_level value on the task to the FND_LOOKUPS view using lookup type JTF_TASK_ESC_LEVEL. This makes the view the object of choice for users searching on the term "esc_level_name," since the escalation level description is not stored directly on the base task table.

The view is owned by APPS and is available in both 12.1.1 and 12.2.2. Because it joins translation tables and lookup views, it is intended primarily for read-only reporting, concurrent program output, and integration extracts rather than for direct DML. It returns one row per task, keyed by object_id and task_id.

Underlying Base Objects

The documented base objects underlying the view are FND_GLOBAL (PACKAGE), FND_LOOKUPS (VIEW), JTF_TASKS_B (SYNONYM), JTF_TASKS_TL (SYNONYM), JTF_TASK_REFERENCES_B (SYNONYM), JTF_TASK_STATUSES_B (SYNONYM), and JTF_TASK_STATUSES_TL (SYNONYM).

The primary driving table is JTF_TASKS_B, which supplies the core task attributes such as task_id, task_number, owner information, dates, and the raw escalation_level code. JTF_TASKS_TL provides the language-specific task_name and description, joined so that the user's session language is respected. JTF_TASK_STATUSES_TL and JTF_TASK_STATUSES_B are used in a scalar subquery to return status_name from the status translation table. FND_LOOKUPS supplies the decoded meanings for both the escalation level (lookup type JTF_TASK_ESC_LEVEL) and the reason code (lookup type JTF_TASK_REASON_CODES). FND_GLOBAL is referenced for session context, and JTF_TASK_REFERENCES_B supports task reference relationships.

Key Columns

  • object_id, task_id, task_number — Primary identifiers for the task record.
  • object_version_number — Optimistic locking version, relevant to integrations that update tasks.
  • owner_id, owner_type_code, owner_territory_id — Task ownership and assignment context.
  • task_name, description — Language-specific task text from JTF_TASKS_TL.
  • task_type_id, task_status_id, status_name — Task classification and decoded status.
  • escalation_level — Raw numeric/code value stored on JTF_TASKS_B.
  • esc_level_name — Decoded meaning of the escalation level from FND_LOOKUPS for lookup type JTF_TASK_ESC_LEVEL, filtered by enabled_flag and effective dates.
  • reason_code, reason_name — Raw reason code and its decoded lookup meaning.
  • closed_flag — Indicates whether the task has been closed.
  • parent_task_id, deleted_flag, actual_start_date, actual_end_date — Hierarchy and lifecycle attributes.
  • source_object_type_code, source_object_id, source_object_name — Originating document or entity linkage.
  • assigned_by_id, private_flag, publish_flag, planned_end_date, workflow_process_id, and attribute1–attribute5 (DDF) — Assignment, visibility, planning, and descriptive flexfield context.

Common Use Cases and Queries

A frequent requirement is to report tasks by their escalation level description rather than the numeric code:

  • SELECT task_number, task_name, escalation_level, esc_level_name, status_name FROM apps.csf_esc_tasks_v WHERE esc_level_name IS NOT NULL;
  • SELECT status_name, COUNT(*) FROM apps.csf_esc_tasks_v WHERE deleted_flag = 'N' GROUP BY status_name;
  • SELECT task_id, task_name, esc_level_name, actual_start_date, actual_end_date FROM apps.csf_esc_tasks_v WHERE closed_flag = 'N' AND planned_end_date < SYSDATE;

Typical scenarios include escalation monitoring dashboards, CRM service-request reporting, and integration extracts that must publish readable escalation codes. Note that the esc_level_name scalar subquery can return NULL when the escalation code is not an enabled lookup value or falls outside its active date range, so defensive filtering or NVL handling is advisable when the value is mandatory in downstream reports.