Search Results hr_form_properties




Overview
Explore in AI Chat

Overview

HR_FORM_PROPERTIES is an Oracle E-Business Suite table owned by the HR schema and delivered under the PER (Human Resources) product family. Its documented purpose is to store configurable properties for configurable forms modules, making it a metadata-driven configuration store that allows Oracle EBS forms to be personalized, branded, or behaviorally adjusted without modifying compiled form code. The table sits beneath the configurable forms framework, where form-level attributes such as help targets, informational messages, and template assignments are resolved at runtime for a given application and form combination.

This is a control-plane table rather than a transactional one; row volumes are typically low and change infrequently, generally through setup or patching activity rather than end-user data entry. Under the heuristic Data Vault classification mined from its foreign key structure, the table is described as satellite-leaning. In modeling terms, this suggests treating HR_FORM_PROPERTIES as a descriptive satellite attached to the HR_FORM_TEMPLATES_B hub rather than as a hub or link in its own right, since its business content consists of attributes qualified by a template reference.

Key Information Stored

The table carries 43 documented columns in the 12.2.2 physical schema. The most significant of these are:

  • FORM_PROPERTY_ID — surrogate primary key, enforced by the HR_FORM_PROPERTIES_PK unique index. It uniquely identifies each configuration row.
  • APPLICATION_ID — identifies the Oracle EBS application (product) to which the form and its properties belong.
  • FORM_ID — identifies the specific form within the application, establishing the form-level context for the property set.
  • FORM_TEMPLATE_ID — the foreign key to HR_FORM_TEMPLATES_B, binding each row to a configurable form template definition.
  • HELP_TARGET — the help destination or target invoked from the form, supporting context-sensitive help integration.
  • INFORMATION_CATEGORY — classifies the informational content associated with the form, providing a grouping dimension for the INFORMATIONn attributes.
  • INFORMATION1 through INFORMATION30 — a wide set of generic attribute columns holding form-specific configuration values, messages, or parameter payloads.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE — standard Oracle WHO audit columns recording row lifecycle and user accountability.
  • OBJECT_VERSION_NUMBER — optimistic locking column used by the framework to detect concurrent updates.
  • ZD_EDITION_NAME — editioning column supporting Oracle EBS 12.2 online patching and edition-based redefinition.

Two unique indexes are documented. HR_FORM_PROPERTIES_PK covers FORM_PROPERTY_ID and ZD_EDITION_NAME, defining the surrogate identity. HR_FORM_PROPERTIES_UK covers APPLICATION_ID, FORM_ID, FORM_TEMPLATE_ID, FORM_PROPERTY_ID, and ZD_EDITION_NAME, which functions as the business-key candidate establishing that a property row is unique per application, form, and template combination.

Common Use Cases and Queries

Typical usage centers on diagnosing why a configurable form behaves differently across environments, auditing form personalizations after a patch, or reporting on the configuration landscape before an upgrade. A standard retrieval pattern joins the table to its template parent and filters on the application and form identifiers:

  • Locate all properties for a specific form: SELECT * FROM hr.hr_form_properties WHERE application_id = :app AND form_id = :form;
  • Resolve template context: SELECT p.*, t.* FROM hr.hr_form_properties p, hr.hr_form_templates_b t WHERE p.form_template_id = t.form_template_id;
  • Audit recent configuration changes: SELECT form_property_id, last_updated_by, last_update_date FROM hr.hr_form_properties WHERE last_update_date > SYSDATE - 30;
  • Inventory configured informational content by category: SELECT information_category, COUNT(*) FROM hr.hr_form_properties GROUP BY information_category;

Because the INFORMATIONn columns are generic, reporting on them usually requires business documentation or probing sample rows to interpret each slot. Comparison queries across environments are also common, since discrepancies in this table frequently explain behavioral differences between development, test, and production.

Related Objects

The most significant dependency is the documented foreign key relationship to the form template definition table:

  • HR_FORM_TEMPLATES_B — referenced through HR_FORM_PROPERTIES.FORM_TEMPLATE_ID; the primary parent in the FK structure and the anchor for the satellite-leaning classification.
  • HR_FORM_TEMPLATES_TL — the translation table for template definitions, typically joined for language-specific descriptions.
  • FND_APPLICATION — resolves APPLICATION_ID to an application short name and description.
  • FND_FORM — resolves FORM_ID to the form name and user form name.
  • FND_FORM_FUNCTIONS — contextualizes the form within menu and function security structures.
  • FND_USER — resolves CREATED_BY and LAST_UPDATED_BY to user accounts for audit reporting.

Collectively, these relationships position HR_FORM_PROPERTIES as a dependent configuration satellite within the Oracle configurable forms framework, queried primarily alongside its template parent and the FND foundation tables that supply application, form, and user context.