As a developer, it is often impossible for you to anticipate all the database columns and UI fields your customers might need, or how each field should look as end user needs change. Flexfields enable customers to configure their applications to meet their business needs without having to perform custom development.
The basic premise of a flexfield is to encapsulate all of the pieces of information related to a specific purpose, such as the components of a student's contact information, or the features of a product in inventory, or a key identifying a particular purchase by a particular person for a particular company on a particular date. A flexfield is a set of placeholder fields, called segments, that are associated with a business object. A segment captures a single atomic value, which is represented in the application database as a single column. In the application UI, a flexfield's segments can be presented as individual table columns, as separate fields, or as a concatenated string of values.
Implementors configure a flexfield by specifying the prompt, length, and data type of each flexfield segment. Configuration includes the specification of valid values for each segment, and the meaning of each value. Configuration also involves defining structure and context. The concepts of structure and context are defined later in this section. For information about flexfield configuration, see the "Using Flexfields for Custom Attributes" chapter in the Oracle Fusion Applications Extensibility Guide. See Section 22.2, "Participant Roles" for the definition of the implementor role.
There are three types of flexfields, all of which enable implementors to configure application features without programming, and these configurations are fully supported within Oracle Fusion Applications:
Descriptive: Descriptive flexfields give customers the ability to extend the data model with additional attributes. A descriptive flexfield provides a set amount of segments for a business object, which the customer can optionally use to add custom attributes to meet their business needs, define how the attributes are validated, and configure how the attributes are displayed. For more information, see Section 22.1.1, "Descriptive Flexfields."
Extensible: An extensible flexfield is similar to a descriptive flexfield, but with the following additional features:.
The number of configurable segments is not fixed. That is the number of segments is extensible.
Attributes can be grouped into contexts so they will always be presented together in the application user interface.
Hierarchical categories enable you to reuse contexts for similar entities.
Extensible flexfields support one-to-many relationships between the entity and the extended attribute rows.
For more information, see Section 22.1.2, "Extensible Flexfields."
Key: Key flexfields enable customers to use their own coding scheme or naming scheme customers to identify their business entities by giving implementors the ability to configure business entities to be identified using flexible, multi-part, intelligent key codes. Each element (segment) of the key may be individually meaningful, as well as the combination as a whole. For example, key flexfields can be implemented to represent part numbers and account numbers. Key flexfields are never optional; customers must configure them for the product to operate correctly.
For more information, see Section 22.1.3, "Key Flexfields."
To better understand flexfields and the differences between descriptive flexfields, extensible flexfields, and key flexfields, it is important to understand flexfield structures and contexts.
Structure: A flexfield structure is a specific configuration of segments. If you add or remove segments, or rearrange the order of segments in a flexfield, you produce a different structure. In some applications, different end users need to see individually tailored segment structures for the same flexfield; for example, the correctly formatted local postal address for customer service inquiries, which would change based on the user's locale.
Your flexfield can display different segments and prompts for different end users based on a data condition in your application data, such as the user's role or a value entered by the user. All types of flexfields allow for multiple structures. All the segments that you might need to use to create all the anticipated structures must be defined as part of the flexfield.
Contexts: Descriptive and extensible flexfield segments are context-sensitive — they are varied or made available in your application by implementors to reflect the needs of the organization for which the application is being configured.
Segments are made available to an application as groups of attributes called contexts. Each context is defined as part of a flexfield, and is comprised of a set of context-sensitive segments that store a particular type of related information. The database columns on which segments are based can be reused in as many contexts as desired. For example, an implementor can define a Dimensions context, which might consist of segments that represent height, width and depth. The implementor can also define a Measurements context, which contains segments that reuse the same underlying height, width and depth columns, and which also includes segments for weight, volume and density.