I had a client encounter this and suggested I send out a reminder to our other Oro clients. I know there can be some confusion about using serialized fields in Oro.
Why use serialized fields?
The main reason is efficiency. A serialized field is stored as additional data on an entity (e.g., a product or customer) and is meant for purely descriptive information. The big advantage in Oro is that serialized fields can be created without need for a schema update.
What is a serialized field?
I think the easiest way to think about it is as a spreadsheet like Excel. If you are making a table and would like to be able to sort or filter by a field, you want to make sure it is its own field, i.e., shows up in the header.
However, that may not be necessary. For example, if you think of a table of addresses, you might want to sort by city, state, and zipcode. However, it’s pretty unusual to sort/filter by Suite #. Thus, you might choose to include that data in the address column and not break it out. That way the address is in a single cell and easier to copy and paste, etc.
When you do that, you lose the ability to use a vlookup on that bit of information, or sort or filter in an Excel table.
Oro Customer Support Description
Availability of a field in segments, reports and filters is determined by “Show Grid Filter” option during field creation.
Unfortunately, there is no way in the UI to enable it for existing serialized fields afterwards. Serialized fields and table columns are stored in different locations, which would require migrating the data from one location to another. It will essentially export values from one field and import them into a different field. As such export/import would update all products in the database, and will invoke the whole search index recalculation, it can be performed only from the code.
If you’re looking to add custom fields, Oro’s documentation explains most of the ups and downs of the various types.