Skip Headers
Oracle® Fusion Applications Developer's Guide
11g Release 6 (11.1.6)

Part Number E15524-11
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Feedback page
Contact Us

Go to previous page
Go to next page
PDF · Mobi · ePub

21 Getting Started with Flexfields

This chapter discusses the basics of using flexfields to enable customers to add custom attributes to a business object in an Oracle Fusion application.

This chapter includes the following sections:

21.1 Introduction to Flexfields

In your role 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 programming.

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.

Those performing in the role of an implementor (of a flexfield), either on behalf of the developer organization for a developer flexfield or on behalf of a customer for a customer flexfield, 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 role of implementor is defined in Section 21.2, "Participant Roles." The difference between a developer flexfield and a customer flexfield is explained in Section 21.1.1, "Descriptive Flexfields" and Section 21.1.2, "Extensible Flexfields." 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.

There are three types of flexfields, all of which enable implementors to configure application features without programming. These configurations are fully supported within Oracle Fusion Applications:

To better understand flexfields and the differences among descriptive flexfields, extensible flexfields, and key flexfields, it is important to understand flexfield structures and contexts.

21.1.1 Descriptive Flexfields

Descriptive flexfields provide a way for customers to add custom attributes to business objects, to define how the attributes are validated, and to define display properties for the attributes. These attributes can be standalone attributes. That is, they do not necessarily need to have anything to do with each other and do not need to be treated as a combination. The segments of a descriptive flexfield that are made available to end users are exposed in the user interface as individual fields.

Descriptive flexfields are entirely optional; customers can choose to configure and expose them or not, as they wish. For example, one customer could configure the parts flexfield to store depth, height, and width, and another customer could configure the parts flexfield to store size and color. Some customers might not need any additional attributes.

You create a descriptive flexfield for one of two purposes:

  • For use by customer implementors — a customer flexfield.

    In this case, you define and register the descriptive flexfield in your application database, but all configuration is accomplished by the implementor, including creating contexts, creating segments, and adding validation. End users see these additional attributes in the UI and can enter values for them. End users cannot modify the configuration; they can only enter values for attributes that are already configured.

  • To support functionality that you build into your application — a developer flexfield.

    For this purpose, you define and register the descriptive flexfield, and then preconfigure (seed) the contexts and segments, value sets, and validation to satisfy a specific purpose. The descriptive flexfield becomes part of your application, and you can code references to its seeded configuration. You might also enable implementors to extend the developer flexfield, allowing them to configure it as they would a customer flexfield.

Even if implementors never change a flexfield after it has been configured, they can take advantage of useful flexfield features such as automatic segment validation, automatic segment cross-validation, multiple segment structures, and more.

21.1.2 Extensible Flexfields

An extensible flexfield is similar to a descriptive flexfield, but with the added ability for customers to add as many context-sensitive segments to a flexfield as they need. In addition, customers can associate more than one context with any particular row of data.

Extensible flexfields also enable implementors to configure contexts as either single row or multiple row. That is, either one set of the context's segments is stored for a business object instance, or multiple sets of the context's segments are stored for the instance. For example, a job position requires only one set of educational requirements, but can require more than one certificate or license.

Extensible flexfields also enable implementors to combine the contexts into groups known as pages, which serve to connect the contexts so they will always be presented together in the application user interface. Hierarchical categories can be defined for extensible flexfields, and implementors can associate any combination of contexts with a given category. For example, the Electronics and Computers category hierarchy might include a Home Entertainment category, which in turn might include an Audio category and a TV category, and so on. The Home Entertainment category might have contexts that specify voltage, dimensions, inputs and outputs. Contexts are reusable within a given extensible flexfield. For example, the dimensions context could be assigned to any category that needs to include dimensional information.

Just as with descriptive flexfields, you create a flexfield for one of two purposes:

  • For use by customer implementors — a customer flexfield.

  • To support functionality that you build into your application — a developer flexfield.

For more information about customer and developer flexfields, see Section 21.1.1, "Descriptive Flexfields."

21.1.3 Key Flexfields

Key flexfields are configurable multipart intelligent keys, where each element (segment) of the key may be individually meaningful, as well as the combination as a whole. For example, key flexfields might represent part numbers and account numbers.

A key flexfield is implemented in the user interface as a collection of fields that can be displayed in various UI formats. Key flexfields are never optional; customers must configure them for their Oracle Fusion applications to operate correctly.

The ability to individually tailor key flexfield structures to the end user can be essential. For example, Oracle General Ledger uses a key flexfield called the Accounting Flexfield to uniquely identify a general ledger account. It maintains the multiple accounting codes used throughout Oracle Fusion Applications, and provides different Accounting Flexfield structures for users of different sets of books. Oracle General Ledger determines which flexfield structure to use based on the value of a Set of Books user profile option.

This flexfield is preconfigured to include six segments: company code, cost center, account, product, product line, and subaccount, and valid values are defined for each segment, as well as cross-validation rules to describe valid segment combinations. However, customers might structure their general ledger account fields differently. By including the Accounting Flexfield, Oracle General Ledger can accommodate the needs of different customers. One customer can configure the Accounting Flexfield structure to include 6 segments, while another customer includes 12 segments, all without programming.

21.1.4 Value Sets

An end user enters a value into a flexfield segment while using an Oracle Fusion application. The flexfield validates each segment value against a set of valid values — a value set — which is usually predefined by the implementor. To validate a segment means that the flexfield compares the value that the end user enters into the segment against the values that comprise the value set that is assigned to that segment.

Flexfield segments are usually validated, and typically each segment in a given flexfield uses a different value set. A value set can be assigned to more than one segment and value sets can be shared among different flexfields. For most value sets, when you enter values into a flexfield segment, you can enter only values that already exist in the value set assigned to that segment.

When a business component is generated for a flexfield, the value set metadata is used in the creation of the view objects. Value sets (and their view objects) are owned by a module, which can be an application, a Logical Business Area (LBA), or a sub-LBA in the application taxonomy hierarchy.

For information about value set configuration, see the "Using Flexfields for Custom Attributes" chapter in the Oracle Fusion Applications Extensibility Guide. For more information about the taxonomy hierarchy, see Appendix A, "Working with the Application Taxonomy."

21.1.5 Flexfield Integration with Oracle Business Intelligence

Oracle Business Intelligence is a comprehensive collection of enterprise business intelligence functionality that provides the full range of business intelligence capabilities including interactive dashboards, proactive intelligence and alerts, enterprise and financial reporting, real-time predictive intelligence, and more.

A descriptive or key flexfield can be included in Oracle Business Intelligence by business-intelligence enabling the flexfield. However, because the polymorphic view objects that are used to model flexfields are not compatible with Oracle Business Intelligence, the flexfield must be flattened into a static form that Oracle Business Intelligence can work with. You accomplish this by slightly modifying the process when you register the flexfield and incorporate it into your application.

For more information, see Section 22.12, "Preparing Descriptive Flexfield Business Components for Oracle Business Intelligence" and Section 25.2.3, "How to Prepare Key Flexfield Business Components for Oracle Business Intelligence.".

21.2 Participant Roles

Responsibility for flexfield development activities is divided between owners and implementors. These are not formal development roles; they are used only in this documentation to clarify and group the flexfield development activities.


The owner (of a flexfield) is the developer (or development team) who determines that a particular flexfield is needed or would be useful within a particular Oracle Fusion application, and makes a flexfield of the appropriate design available. The owner then incorporates the flexfield into an application. With key flexfields, the owner can be either a producer or a consumer, or can assume both roles.

  • Producer: The flexfield producer is the developer who determines that a particular flexfield is needed or would be useful within a particular application, and makes available a flexfield of the appropriate design. With key flexfields, the producer's product owns the combinations table for that flexfield, which is described in Section, "Creating the Combinations Table."

  • Consumer: A key flexfield consumer incorporates a flexfield into an application. The consumer typically stores a segment value or combination ID (CCID) on a product database table, and works with the structural and seed data and the business components that have been configured by the flexfield producer.


An implementor (of a flexfield) is an individual who sets up all or part of a flexfield-enabled application for deployment. Implementors typically work for or on behalf of customers to install, configure, or administer their applications. In the case of developer flexfields that have been created to support functionality that has been built into the application, the developer also assumes the role of implementor.

21.3 The Flexfield Development Lifecycle

The process of developing a flexfield and incorporating it into an application differs for each type of flexfield. In general, the process comprises the following activities:

  1. Define and register the flexfield metadata.

  2. Create business components for the flexfield. For key flexfields, also create business components for the key flexfield combination filters as described in Section 25.4, "Working with Code-Combination Filters for Key Flexfields."

  3. For descriptive and key flexfields, link the flexfield business components to the application's business components.

  4. Incorporate the flexfield into UI pages.

  5. Define sample flexfield data and use it to test the flexfield.

  6. Use the Tester role of the Create Flexfield Business Components wizard to create a model that you can use to test the flexfield.

  7. Optionally, share the flexfield business components with other developers using an Oracle Application Development Framework (Oracle ADF) library.

After you have completed the flexfield development process and delivered the application, implementors can use the Manage Flexfields task flows to configure each flexfield. These task flows determine how the flexfield's segments will be populated, organized, and made available to end users within the application. For information about planning and implementing flexfield configuration, such as defining structures, contexts, attributes, labels, behavior, and associated value sets, see the "Using Flexfields for Custom Attributes" chapter in the Oracle Fusion Applications Extensibility Guide.


You must use the specified tools throughout the development lifecycle to create and update the flexfield metadata and product tables. Do not use database tools unless you are instructed to do so. If you use database tools instead of the specified tools, you risk destroying data integrity and you lose the ability to audit changes to the data.

Because Oracle Fusion Applications tables are interrelated, any changes that you make using the specified tools, such as building business components or UI forms, can update many tables at once. If you do not use the specified tools, you might not update all the necessary tables. In addition, most of these tools perform validation and change tracking.

If tables are not properly synchronized, you risk unpredictable results throughout Oracle Fusion Applications products.

21.4 Flexfields in the Application User Interface

Flexfield segments can appear in a user interface as either label/widget pairs or as table fields. After an extensible flexfield is configured, it appears in the UI as one or more regions. Configured descriptive and key flexfields may appear in the UI in either a form layout, a tabular layout, or in a form or table layout in a popup component:

All segments of a single flexfield are grouped together by default. The layout of the form or table and the positions of the flexfield segments depend on where you place the flexfield on the page. Flexfields may also be presented in a separate section of the page, alone in a table, or on their own page.