Search Results csf_r_request_tasks_u1

Overview

CSF.CSF_R_REQUEST_TASKS is a transactional table within the CSF (Field Service) schema of Oracle E-Business Suite. It records the individual task-level units of work associated with a scheduled field service request. Where CSF_R_SCHED_REQUESTS captures the parent scheduling activity, CSF_R_REQUEST_TASKS breaks that activity into the discrete tasks to be dispatched, executed, and reported against by field personnel.

The object resides in the APPS_TS_TX_DATA tablespace and is registered under FND Design Data as CSF.CSF_R_REQUEST_TASKS. Its status is VALID in both 12.1.1 and 12.2.2. Oracle classifies this object as Oracle Internal Use Only: it is not supported for direct access except through standard Oracle Applications programs, and any custom read or write should be treated as a risk-bearing integration.

From a data-modeling perspective, the mined foreign-key structure suggests a hub-leaning classification under Data Vault heuristics. The table predominantly acts as a key-bearing entity whose identity is anchored by REQUEST_TASK_ID, with dependent context recorded in the same row rather than in a fully normalized satellite. This classification is a modeling suggestion only and should not be read as an Oracle-documented designation.

Key Information Stored

The table is defined with six documented columns. The most significant are summarized below.

• REQUEST_TASK_ID (NUMBER) — The primary key of the table and the sole column of the unique index CSF_R_REQUEST_TASKS_U1. It is the surrogate identifier for a single request task and is the column most commonly carried into dependent tables.
• SCHED_REQUEST_ID (NUMBER) — A foreign key to CSF_R_SCHED_REQUESTS, linking the task back to its parent scheduled request. This column is the driving predicate for the non-unique index CSF_R_REQUEST_TASKS_N1 and is the natural entry point for retrieving all tasks belonging to a scheduling record.
• TASK_ID (NUMBER) — Identifies the task to be processed. When a trip is processed, this column stores the ID of the first task in the trip, which means a single row can represent a multi-stop workload.
• RESULT_FLAG (VARCHAR2) — Stores the result of the execution of the request, providing the completion or outcome status of the task.
• SECURITY_GROUP_ID (NUMBER) — The security group identifier, with a foreign key to FND_SECURITY_GROUPS. This column enforces multi-tenant data isolation in the Multi-Org Access Control model.
• OBJECT_VERSION_NUMBER (NUMBER) — Optimistic locking column, incremented by one on each update. Readers capture the value at read time and the application verifies it has not changed before committing, preventing lost updates from concurrent processes.

Note the distinction between the surrogate primary key (REQUEST_TASK_ID) and the documented business-key candidate exposed through the unique index CSF_R_REQUEST_TASKS_U1. The metadata documents no alternate unique index beyond this one.

Common Use Cases and Queries

The dominant access pattern is retrieval of all task rows for a given scheduled request, using the CSF_R_REQUEST_TASKS_N1 index path. A representative query follows:

• SELECT request_task_id, sched_request_id, task_id, result_flag FROM csf.csf_r_request_tasks WHERE sched_request_id = :p_sched_request_id;

Operational reporting frequently pivots on RESULT_FLAG to track task completion rates, exception volumes, and dispatch throughput. A typical aggregation groups tasks by outcome over a scheduling window, joining upward to CSF_R_SCHED_REQUESTS for the scheduling dates.

Because CSF_R_MESSAGES and CSF_R_RESOURCE_RESULTS both carry REQUEST_TASK_ID, reconciliation queries join those tables to the request task to verify that every execution result has a corresponding message trail and resource outcome. Security-scoped reporting must include SECURITY_GROUP_ID as a filter predicate to respect Multi-Org boundaries. Update transactions must always supply the current OBJECT_VERSION_NUMBER in the WHERE clause, mirroring the standard Oracle optimistic locking pattern.

Related Objects

The following objects are the most significant dependencies, based on the documented foreign-key relationships:

• CSF.CSF_R_SCHED_REQUESTS — Parent table referenced by SCHED_REQUEST_ID; the primary join for reconstructing scheduling context.
• CSF.CSF_R_MESSAGES — References this table via REQUEST_TASK_ID; holds messages generated in the course of task execution.
• CSF.CSF_R_RESOURCE_RESULTS — References this table via REQUEST_TASK_ID; stores resource-level execution results for the task.
• FND_SECURITY_GROUPS — Referenced by SECURITY_GROUP_ID; governs data visibility across operating units.
• CSF.CSF_R_REQUEST_TASKS# — The underlying object referenced by this table designation, per the documented dependency listing.

All access should be performed through supported Oracle Field Service programmatic interfaces wherever possible, given the internal-use designation on this table.