Overview of Extensible Flexfields

Extensible flexfields are like descriptive flexfields, with some additional features.

• You can add as many context-sensitive segments to the flexfield as you need. You aren't restricted by the number of columns predefined and registered for the flexfield.

• You can configure a one-to-many relationship between the entity and its extended attribute rows.

  • A row of data can have multiple contexts associated with it.

  • A row of data can have multiple occurrences of the same context.

• You can configure attributes in groups to form a context so that the attributes in the context always appear together in the user interface.

• You can use existing hierarchical categories so that entities inherit the contexts that are configured for their parents. Contexts are reusable throughout categories.

• Application development has registered some extensible flexfields to support view and edit privileges. For such flexfields, you can specify view and edit privileges at the context level to control who sees the attributes and who can change the attributes' values.

When you configure a context for multiple rows per entity, the segments are displayed as a table.

Unlike descriptive flexfields, the extension columns corresponding to extensible flexfields segments are part of extension tables, separate from the base application table. Unlike descriptive flexfield contexts, the set of attributes in an extensible flexfield context remains constant and doesn't differ by context value. An extensible flexfield describes an application entity, with the run time ability to expand the database that implementation consultants can use to define the data structure that appears in the application. Extensible flexfields support one-to-many relationships between the entity and the extended attribute rows. To get a list of predefined extensible flexfields, use the Manage Extensible Flexfields task in the Setup and Maintenance work area.

The following aspects are important in understanding extensible flexfields:

• Usages

• Categories

• Pages

• Security

• Protected Extensible Flexfield Data

Usages

Similar to the descriptive flexfields, you can define multiple usages for an extensible flexfield, which enables several application tables to share the same flexfield.

For example, a flexfield for shipping options can be used by both a Supplier table and a Buyer table. In addition, you can associate a context with one, some, or all of the flexfield's usages. Thus, with the shipping information example, you can associate a warehouse context with the Supplier usage, a delivery location context with the Buyer usage, and a ship-via context with all usages.

Usages include security information for applying no security to user access or enforcing view and edit privileges. Some product-specific extensible flexfields have specialized usage fields beyond those for security.

Categories

You can configure multiple extensible flexfield contexts and group the contexts into categories. All extensible flexfields have at least one category. For some extensible flexfields, you can configure a hierarchy of categories. A child category in the hierarchy can inherit contexts from its parent category.

You can define categories for extensible flexfields, and you 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 product 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.

Pages

Extensible flexfields let you combine contexts into groups known as pages, which serve to connect the contexts so they will always be presented together in the application user interface.

Each application page corresponds to one extensible flexfield category, with a separate region of the page for each associated context.

Security

When you configure a flexfield, you set the privileges for a context at the usage level by selecting actions for the view and edit privileges of a context usage.

When an end user performs a search, the user interface displays only the attribute values of the contexts for which the user has view privileges. The user can perform a search using all attributes for all contexts, regardless of view privileges.

If end users access a context through a web service, an exception is thrown if they perform an action for which they don't have privileges.

All extensible flexfields have a base data security resource. Some data security resources for extensible flexfields are preconfigured with actions that you can use to specify access privileges. If no action is preconfigured, a security administrator can create actions and policies to support access control on the extensible flexfield attributes.

Some extensible flexfields have a translatable option; these flexfields also have a translation data security resource.

Protected Extensible Flexfield Data

Application developers may mark some data configurations in an extensible flexfield as protected, indicating that you can't edit them.

If an extensible flexfield is partially protected, then you can't edit the protected portions of the flexfield's configuration. For example:

• If an extensible flexfield context is protected, you can't edit its:

  • Context details

  • Context segments

  • Context usages

• If an extensible flexfield page is protected, you can't:

  • Edit the page details or delete the page

  • Edit the contexts associated with the page

Note:

• There's no restriction on page references to protected contexts. The pages you create may contain any context, whether protected or not.

• There's a restriction on category references to protected contexts. If a context is protected, you can't add it to or delete it from any category.