An important product detail lives in a spreadsheet. Instructions for serving a particular customer are buried in an old conversation. A piece of information needed to check an order depends on someone remembering to look it up. As an operation grows, those details need a defined home and clear rules for using them.
PrestaShop 9.2, released as a stable version on September 30, 2026, includes the Extra Properties system for attaching additional fields to platform entities. Its business value is in structuring information that has no suitable place in the existing data model. That does not mean every operational problem should become another custom field.
1. Start with the missing information
Before creating a field, describe the real situation: what information is missing, who knows it, when it needs to be recorded, and who will use it. Then check whether the platform or an installed module already provides an appropriate feature.
A public product characteristic may belong in the product specifications. A purchasable option such as size or color may require a combination with its own SKU, inventory, or price. An internal note is not necessarily a customer-facing product attribute. An approval stage requires more than somewhere to type a comment.
Creating a second field for information that already exists introduces another opportunity for disagreement. Start with a small inventory of the data your team uses, its owners, and its destinations. That separates a missing data field from a workflow or integration problem and prevents the new feature from becoming another parallel record.
2. Understand what Extra Properties provides
The system defines a field, its data type, and its relationship to an entity such as a product, combination, customer, or order. Depending on the definition and installation support, properties can integrate with back-office forms and grids and selected Admin API operations.
This gives additional data a shared foundation. It does not mean that every new field automatically appears everywhere in the storefront, is collected from customers at checkout, or becomes available in the ERP. Decide where the information is captured, displayed, and consumed.
There is an important maintenance qualification: the official documentation marks the Extra Properties code as @experimental in PrestaShop 9.2. The platform release is stable, but this component designation allows exceptional compatibility changes. Account for that distinction when planning module maintenance and future shop upgrades. A stable platform release does not remove the need to check the status of individual extension interfaces.
3. Evaluate practical operational examples
The following examples are illustrative modeling proposals, not features of an announced AGTI module:
| Business need | Entity to evaluate | Decision required |
|---|---|---|
| Indicate that a product needs reinforced packaging | Product | Who maintains the value and how dispatch staff see it |
| Record a purchasing branch code in a B2B process | Customer | Who owns the code and which system is authoritative |
| Record an internal order-checking indicator | Order | Who may update it and which actions depend on it |
The first example may be a simple boolean if there are only two clearly defined states. The second needs a consistent format and an update process. The third must distinguish a descriptive field from an actual workflow that controls the checking stage.
In every case, the value only helps when it reaches the person or system expected to act on it. A packaging instruction that dispatch staff never see remains isolated information, even if it is stored inside the platform. Identify the point of use as carefully as the point of entry.
4. Choose the type, scope, and validation deliberately
The type should reflect the meaning of the data. A yes-or-no flag, a date, and a textual reference have different requirements. For a closed set of answers, a choice list can prevent multiple spellings of the same condition.
Also decide whether the value is shared, translated, or store-specific:
| Scope | Intended use to assess |
|---|---|
common | A value shared across the applicable contexts |
lang | Content whose value depends on language |
shop | Information that can vary between stores |
Scope availability depends on the entity and its underlying structure. Do not assume every entity supports every scope. In multistore operations, distinguish the context of the stored values from the stores in which a definition is visible.
Specify limits, permitted values, and empty-value behavior. A default must not imply that a check occurred when nobody performed it. The documentation also distinguishes marking a field as required in a form from validating it on the server: an effective non-empty requirement needs an appropriate constraint, such as NotBlank where applicable. Test the actual entry paths rather than relying on the appearance of the form.
5. Decide where the field belongs and who maintains it
A useful field needs a clear label, filling instructions, and a sensible location. If it sits far from the workflow where the information becomes known, staff may leave it empty or update it too late. Decide whether it belongs in a form, a listing, an integration, or several of these places.
Properties created through the back office and properties registered by modules have different ownership responsibilities. A module should remain responsible for the definitions it manages. Manually changing a structure controlled by code can create a conflict at the next installation or upgrade.
Decide deliberately whether the value may be exposed to the public storefront. Exposure settings do not replace an assessment of each integration's access, and they should not be interpreted as granular employee permissions. Internal information needs an intentional destination rather than automatic publication for convenience.
6. Separate storage, presentation, and automation
Recording a value, displaying it, and performing an action based on it are three separate pieces of work. A reinforced-packaging property does not, by itself, change packaging selection, shipping calculations, or document generation.
Likewise, an extra field does not automatically become a catalog filter. A customer property is not automatically collected through the public registration form. A value exposed through the Admin API will not be consumed by an ERP integration that has not been adapted to read it.
Map the full path: source, validation, storage, reading, and operational use. When systems exchange the value, identify the authoritative owner and decide how conflicting updates should be handled. Otherwise, the new field may simply move an inconsistency from a spreadsheet into the commerce platform.
7. Test one small, observable workflow first
Start in staging with a clearly bounded need. Enter new values, inspect existing records, and validate the language and store contexts your operation actually uses. If an integration is involved, test reads and writes through its real access path, not merely the presence of the field in the back office.
Ask someone from operations to perform the task. They should understand the label, know when to fill it in, and find the value at the moment they need it. Also test what happens with an empty field or an invalid value.
Plan definition changes and eventual removal. The documentation distinguishes removing a definition from dropping its storage column and values; these actions are not equivalent. Schema changes and data migration therefore need their own plan, rather than destructive experiments on the production shop. Confirm what should happen to historical values before changing the model.
8. Use fields to support a process you already understand
A well-described decision can fit into a short specification: name, entity, purpose, type, owner, entry point, reading locations, integrations, and acceptance criteria. Include what must not happen automatically, especially when the value relates to an operational approval or another system's responsibilities.
If the team cannot yet say who produces the information or how it will be used, creating the field will not resolve that uncertainty. Once those answers are clear, Extra Properties can be assessed as part of a consistent solution with fewer scattered records and clearer ownership.
AGTI can help determine whether your requirement is already covered by the platform, an existing module, or a targeted customization. Discuss your store's workflow with AGTI.
Technical references
- PrestaShop 9.2 stable release announcement.
- Extra Properties overview.
- Managing Extra Properties from the back office.
- Registering Extra Properties from a module.
Sources checked on October 19, 2026. This article explains evaluation criteria. It does not demonstrate a particular installation or assume that its themes and integrations have already been adapted.