Search Results csf_params




Overview
Explore in AI Chat

Overview

CSF_PARAMS is a configuration table owned by the CSF (Field Service) schema in Oracle E-Business Suite, documented as "Parameters for Laptop and Palm." It stores runtime and client-configuration parameters consumed by the disconnected field service applications used by field technicians — historically the laptop-based and Palm OS-based mobile clients that synchronize with the EBS Field Service module. Each row represents a single named parameter with an associated value, forming a generic key/value configuration store rather than a transaction-bearing entity.

From a Data Vault modeling perspective, the metadata's heuristic classification places CSF_PARAMS as a standalone structure. This suggests treating it as a hub-like reference table (with PARAM_ID as the surrogate hub key) rather than a link or satellite, since it carries no documented foreign-key dependencies other than an optional security-group reference and no dependent child tables within the mined relationship set. A satellite on PARAM_ID would naturally hold the descriptive attributes (NAME, VALUE, the ATTRIBUTE1–15 flex columns) if the source were refactored.

Key Information Stored

The table contains 25 documented columns. The most significant are:

  • PARAM_ID — the surrogate primary key, enforced by constraint CSF_PARAMS_PK. This is the system-generated identifier and is not a business key.
  • NAME — the parameter name (business identifier), identifying which configuration setting the row represents.
  • VALUE — the parameter's value, stored as a string and interpreted by the consuming mobile client.
  • SECURITY_GROUP_ID — a foreign key to FND_SECURITY_GROUPS, scoping the parameter to a security group and supporting multi-org style data isolation.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the standard Oracle EBS descriptive flexfield (DFF) columns, providing extensible storage for additional parameter metadata without schema change.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — the standard "WHO" audit columns maintained automatically by EBS concurrent and form processing.

Although only the PARAM_ID primary key is documented, NAME together with SECURITY_GROUP_ID is the practical business-key candidate for uniqueness in most deployments. No alternate unique index is confirmed in the supplied metadata.

Common Use Cases and Queries

This table is primarily consulted to retrieve configuration values that govern field-service client behavior, such as synchronization intervals, attachment settings, or device-specific options. A typical lookup retrieves a single parameter by name:

  • SELECT name, value FROM csf.csf_params WHERE name = :p_name;
  • SELECT p.name, p.value FROM csf.csf_params p WHERE p.security_group_id = :sg_id ORDER BY p.name;

Reporting scenarios include auditing parameter drift across environments, comparing production versus test values, and documenting which parameters are customized. Because the ATTRIBUTE columns are often unused, a reporting query might filter to rows where any attribute is populated to detect extended usage. Administrators also use the table to validate that required parameters exist after cloning, since cloned instances may inherit stale values.

Related Objects

The mined relationship data documents a single foreign-key reference, but CSF_PARAMS participates in the broader Field Service and mobile-synchronization ecosystem. Significant related objects include:

  • FND_SECURITY_GROUPS — referenced by CSF_PARAMS.SECURITY_GROUP_ID; joining on SECURITY_GROUP_ID resolves the security classification of each parameter.
  • CSF_PARAMS_PK — the primary key constraint on PARAM_ID.
  • FND_FLEX_VALUES / FND_FLEX_VALUE_SETS — typical validation sources for the ATTRIBUTE_CATEGORY flexfield values.
  • FND_USER — resolves LAST_UPDATED_BY and CREATED_BY to the responsible user.
  • Other CSF_% configuration and synchronization tables in the Field Service schema, which consume these parameters during mobile client synchronization.

Because the table is standalone with minimal documented dependencies, it is best treated as a low-cardinality reference source in analytic models, joined outward to FND_SECURITY_GROUPS rather than expected to drive transactional facts.