Search Results create_follow_up_task

Overview

CSFW_TASKS_PUB is the public PL/SQL API package for the Oracle EBS Customer Support / Service (CSF) task management framework. It exposes a controlled, AUTHID CURRENT_USER interface through which callers create, query, and maintain service tasks and service requests (SRs) that are stored against the shared JTF_TASKS_B task model. In Oracle EBS 12.1.1 and 12.2.2, the package is owned by APPS and classified as a public (PUB) API, meaning it is a supported integration point rather than an internal library. Its principal business purpose is to let agent-facing forms, self-service pages, and external integrations raise follow-up tasks, create standalone or source-linked tasks, open service requests, resolve scheduling end dates, validate customer install sites, and update task flexfield (DFF) attributes, all while enforcing the referential and validation rules of the task and service-request schema. Because the package is documented in the ETRM as being referenced by zero other packages, it functions as a top-of-stack entry point: consumers invoke it directly, and it in turn operates on the underlying base and interface tables.

Key Procedures and Functions

The package exposes eight documented procedures and functions:

• GET_FOLLOW_UP_TASK_DETAILS — returns descriptive details for a given follow-up task, including task name, status, priority, associated customer name, originating request number, and planned effort unit of measure. It also returns standard error identifier and error message outputs.
• CREATE_FOLLOW_UP_TASK — creates a follow-up task record deriving from a parent task, accepting task attributes, planned dates and effort, notes, note type and status, and a full set of descriptive flexfield attribute columns (attribute_1 through attribute_15 plus context). It returns the new follow-up task identifier and error outputs.
• CREATE_NEW_TASK — creates a new task, accepting task name, type, status, priority, an assign-to-me indicator, planned start date, planned effort and UOM, notes, and a source object identifier, returning the new task identifier and error outputs.
• CREATE_NEW_SR — creates a new service request for the task context.
• GET_END_DATE — resolves the end date used in task or schedule calculations.
• VALIDATE_INSTALL_SITE — validates that an installation site is a legitimate, active site for the party being serviced.
• UPDATE_TASK_FLEX — updates the descriptive flexfield (DFF) attribute columns and context on an existing task, the procedure directly relevant to the "update_task_flex" search.
• UPDATE_SCH_DATE_TASK — updates scheduling date attributes on an existing task.

Tables Accessed

The package reads and writes through APPS synonyms across several EBS schemas. Task data is persisted in and read from JTF_TASKS_B, with task type validation against JTF_TASK_TYPES_B and resource assignment data drawn from JTF_RS_RESOURCE_EXTNS. Service-request context is supplied by CS_INCIDENTS_ALL and contact-point data by CS_HZ_SR_CONTACT_POINTS_S. Customer and party validation relies on HZ_PARTIES, HZ_PARTY_SITES, HZ_PARTY_SITE_USES, and HZ_RELATIONSHIPS. Install-site and item context is validated against CSI_ITEM_INSTANCES and CSI_I_PARTIES, with item categorization from MTL_ITEM_CATEGORIES. Effort UOM handling uses MTL_UOM_CONVERSIONS, required skills are resolved from CSF_REQUIRED_SKILLS_B, and utility lookups reference DUAL.

Usage Notes

CSFW_TASKS_PUB is typically invoked from the Customer Support agent forms and self-service task pages, which call the create and update procedures to persist agent actions without writing directly to JTF_TASKS_B. Because UPDATE_TASK_FLEX is the documented touch point for DFF attribute maintenance, customizations that need to populate or change task flexfield attributes programmatically should call this procedure rather than issuing DML against the task table. All procedures return error identifier and error message out parameters, so callers must check these values and handle failures through the standard EBS API error pattern. Integrations and concurrent programs should invoke the package as APPS with the appropriate runtime user context, since AUTHID CURRENT_USER means privilege resolution follows the invoking schema.