✓ Only the fields that applyCoffee machineItemNameEANBrandWaterTankAccessoryItemNameEANBrand
Create features
Set the definition
Dependency
Edit the item
Features and Configurations is where the Perfion data model is built. A Feature is one property you hold for items, such as Item Name, EAN or Color, and each has a Feature type that decides what it can hold. A Configuration is the data model for a selectable feature: it sets which features a Product, a Brand or any other selectable feature carries, and in which order. With item dependency, extra features appear only on the items they apply to. You manage both in the Features menu, which you will find in both the Perfion web client and the Windows client.
Written for product data teams · By Vipin Kumar, Founder and Solution Architect · Last updated BPAS · Exclusive Boyum Practice. India's No.1 Customer-referred Boyum IT Partner.
At a glance
Perfion name
Features and Configurations
Where
The Features menu, in both clientsWeb clientWindows client
Set up by
AdministratorsSuper Users have every section except Features
11feature typesAaString¶Text#Number◷Date◑Boolean▣Image⎘File↗Link☷Table⌕Search⇄Related Value
How It Works
How the Perfion data model works, from feature to finished item
Features and Configurations sits underneath everything else in Perfion. It turns “we sell kettles, coffee machines and spare parts” into “a coffee machine has these fields, in this order, on these tabs”.
Create the features
In the Features menu, an administrator adds each Feature under its data type, such as String, Number or Image.
Set the definition
A unique name, captions and unit per language, and value settings such as Localizable, Inheritable or Selectable.
Build the configuration
Decide which features a selectable feature such as Product carries in its Configuration, and in which order.
Add item dependencies
Some features apply only to items with a given value, such as one category or one brand: item dependency.
Users manage the data
In the grid and the item editor, each item shows the features that apply to it, arranged by Top View Group and View Group.
Refine the model
Perfion · Features
Feature libraryFilter features
▸Boolean3
▸Date2
▸File2
▸Image4
▸Number9
▾String14
▸Text5
ItemName
EAN
Brand
Category
Product configuration
ProductBase Value
ItemNameLocalizable
EANUnique
BrandInheritable
CategorySelectable
Coffee MachinesItem dependency
WaterTankNumber
PressureNumber
AccessoriesItem dependency
CompatibleModelsString
Brand
An illustration of the Features menu, not a screenshot: the feature library on the left, and the configuration it builds on the right.
Fixed Fields vs Perfion
A fixed set of item fields vs Perfion: what a spreadsheet holds, what a data model holds
Most product data starts in a spreadsheet or a fixed item card, with the same columns for every item. Perfion lets you design the model around your products instead.
Fixed item fieldsItemColourTank (l)BladesBurnersVoltsKettleRed230Mixerred3230CooktopRED2Coffee m.Black1.8230Every field on every item. Three spellings of one colour.
vs
Perfion data modelMixerColourRedBlades3Volts230CooktopColourRedBurners2Coffee machineColourBlackTank1.8 lVolts230Only the fields that apply. One value for Red.
A fixed set of item fields, as kept in a spreadsheet or a fixed item card, compared with Perfion Features and Configurations as described in Boyum IT Solutions' Perfion documentation.
Product data need
Fixed item fields
Perfion Features and Configurations
Adding a new attribute
A new spreadsheet column, or a custom field someone has to add to the item card.
An administrator adds a Feature to the library and to the Configuration. No new spreadsheet column.
Fields per product type
Every item carries every field, whether it applies or not.
Item dependency shows features only on items with a given value, such as a category or a brand.
Repeated values
Typed by hand, so the same colour can be spelt three ways.
Selectable features: users pick from a list kept in Feature Data. Edit a value once and every item it is assigned to shows the change.
Languages
One column per language, or a separate file for each market.
Localizable features hold values per language. Captions, units and help text are set per language too.
Parent and child items
Values copied down to each variant by hand.
Inheritable features pass a value set on the parent to its child items.
Table-like data
Extra columns: Ingredient 1, Ingredient 2, Ingredient 3, and so on.
Perfion data model capabilities: eight things the administrator controls
Each capability shows what it does in Perfion and what it is worth to the business.
Operational Reality (Capabilities)
Every Feature has a Feature type that decides what it can hold: Boolean, Date, File, Image, Link, Number, Related Value, Search, String, Table and Text. A String holds one line of up to 256 characters; a Text holds long text as plain text, HTML or Rich Text. Image features take BMP, GIF, JPG/JPEG, PNG, TIFF/TIF, EPS, PSD, PDF (first page), SVG, WEBP and AVIF.
Features listed by data type in the feature tree
Find a feature by name or Perfion ID
A new feature can start from an existing one and take its settings as suggestions
Executive ROI Value
AaString¶Text#Number◷Date◑Boolean▣Image⎘File↗Link☷Table⌕Search⇄Related Value
Values held as the right type can be checked, sorted and published without a clean-up round first.
Less fixing before every catalogue or upload
One feature library, reused across product lines
Operational Reality (Capabilities)
With Selectable checked, users pick values from a list instead of typing them. The lists live in Feature Data. Allow Hierarchy builds trees with virtual items, such as categories, and Custom Ordering sorts a list by hand. Related features can share one list: InteriorColor can reuse the list from Color.
Edit a value once; every item it is assigned to shows the change
Hierarchies for category structures
Export a list to Excel, edit it and import it again
Executive ROI Value
Feature Data · ColorRedRuby RedBlueBlackItem 1 RedRuby RedItem 2 RedRuby RedItem 3 RedRuby Red
Every channel gets one spelling of each colour, material and category, so filters and reports agree.
Fewer duplicate values to clean up
One list to maintain instead of many
Operational Reality (Capabilities)
With Localizable checked, a feature holds values in several languages; Item Name is the typical example. On the Captions tab, each feature gets a Caption, a Caption Alt and an Abbreviation for reports and other channels, a Unit such as cm, and Help Text shown in the item editor, in every active language.
Values per language on the same item
Abbreviations such as Ø for Diameter
Help text where editors enter the data
Executive ROI Value
Item NameENKettleDEWasserkocherFRBouilloire
A new market reuses the same model. Only the language values are added, not a new file.
No separate product file per language
Labels and units stay consistent in every output
Operational Reality (Capabilities)
With Inheritable checked, a value set on a parent item is inherited by its child items; Brand is the typical example. Where parents and children need their own values, such as Item Type, they can keep them. Allow Multiple holds several values for one item in one feature, such as Related Products, and Sortable lets users put them in order of importance.
Variants stay in line with their parent without anyone retyping the same value.
Less re-keying across variants
Cross-sell links kept in a set order
Operational Reality (Capabilities)
A selectable feature in a Configuration, such as Category or Brand, can be the root of an item dependency. Features tied to one of its values appear only on items with that value. Dependencies at the same level work independently, so either one is enough. Nested dependencies need both, such as Category Accessories and Brand Jura.
Fields per category or per brand
The same feature can sit in several item dependencies
Works with any selectable feature, such as Category or Brand
Editors see a short, relevant item card instead of a long list of fields that do not apply.
Faster enrichment per item
Fewer fields filled in by mistake
Operational Reality (Capabilities)
For data with rows and columns, such as ingredients with a name, an amount and a percentage, Swap Relation Direction lets users manage a table inside one feature on each product. Each row is created when it is added to a product, and appears in Feature Data with a reference to that product.
Ingredients, components or specification rows are held as structured data, not as pasted text.
Rows that reports can use directly
No fixed limit of Ingredient 1, 2, 3 columns
Operational Reality (Capabilities)
Copy decides which values come across when a user copies an item, and Default Values sets values that every new item gets. Each feature’s Top View Group and View Group decide where it appears in the item editor.
Item editor order: Base Value, Top View Group, View Group, then configuration order
Remote and Related Value features are never copied and take no default values
Compact sets one image and two alphanumeric features for card layout
Executive ROI Value
New itemStatusUnder EnrichmentdefaultWeight20 kgdefaultApprovedFalsedefault
New items start with the right values, and editors find each field where they expect it.
Fewer missing values on new items
Shorter training for new editors
Operational Reality (Capabilities)
Each feature sits in a Security Group, and users and groups get rights per Security Group. Feature Item Security changes rights by the value of a selectable feature: products with Status Under Enrichment stay editable, Published ones do not. Read Only stops all users changing a feature’s values, typically values owned by the ERP. Remote features show data live from an external system or from other Perfion features, and are read only.
Approved data stays approved, and values that belong to the ERP stay with the ERP.
Clear ownership between PIM and ERP
Fewer accidental changes to live products
Core Concepts
5 Core Concepts of the Perfion Data Model
The first three are about how the model is built. The last two are about keeping the data in it right.
01
How the model is builtConcept 01 · Describe a property once, use it on every item
A Feature Is Defined Once
The product data problem it solves
The same property sits in five columns with five names, so nobody knows which one is right, and every channel gets a different answer.
The concept explained
Product data starts with properties: a name, a length, a colour, a datasheet. In Perfion each property is a Feature, defined once in the Features menu with a unique name, a Feature type and its settings. Every item that needs the property uses that one feature with its own value. Change the caption, the unit or the rules on the feature, and the change applies wherever it is used. Because the name is unique and the type is fixed, a length is always a number in centimetres, never a mix of numbers and notes.
Everyday analogy
A form at a bank. The box marked “Date of birth” is designed once and printed on every form. Each customer fills in their own date, but nobody gets to rename the box.
In Perfion
Features are the basic building blocks of the Perfion data model. A feature name must be unique, use letters and numbers only, and not start with a number; camel case such as ItemNumber is recommended.
Swipe sideways to see the full diagramOne Length feature, defined once, used by every item that needs it.
02
How the model is builtConcept 02 · Decide which features each kind of item carries
The Configuration Is the Data Model
The product data problem it solves
Products, brands and suppliers are described in different files with different columns, so linking them is a manual job.
The concept explained
Features on their own are a library. A Configuration puts them to work. In Perfion, a configuration is the data model for a selectable feature. Product is the most common example: its configuration lists the features every product carries, such as Item Name and EAN, in the order they appear in the grid. The top node is the Base Value. Any selectable feature can have a configuration, so a Brand can carry its logo and website, and a product that picks a brand is linked to all of it.
Everyday analogy
A school register. The register decides the columns: roll number, name, class, guardian. Every student gets the same columns, and a new column is added once, for everyone.
In Perfion
A configuration is the data model for a selectable feature, and every selectable feature can have one. That lets you model Brands, Customers, Images and anything else that makes sense in your business.
Swipe sideways to see the full diagramProduct has its own configuration. Brand, a selectable feature on it, has one too.
03
How the model is builtConcept 03 · Different products need different specifications
Show Only What Applies
The product data problem it solves
A coffee machine and a descaling tablet share one item card with every field for both, so editors skip fields and leave gaps.
The concept explained
Not every product needs every specification. A water tank volume means something for a coffee machine and nothing for an accessory. Item dependency lets the model follow the product. Features can be tied to one value of a selectable feature, such as one category or one brand, and then appear only on products with that value. Dependencies at the same level work independently; nested ones need every condition to be true, so Perfion advises using them with caution.
Everyday analogy
A restaurant menu with a section for each cuisine. The tandoor section lists tandoor dishes and the Chinese section lists Chinese ones. Nobody prints every dish on every page.
In Perfion
Perfion calls this Item Dependency: it lets you build individual data models for individual groups of items, all inside one configuration.
Swipe sideways to see the full diagramUnder Category, each item carries its own features. Each product shows only what applies to it.
04
Keeping it rightConcept 04 · One value, held once, used everywhere
Pick, Don’t Type
The product data problem it solves
Colours, materials and categories are typed by hand, so “Red”, “red” and “RED ” become three values in every filter.
The concept explained
Whenever the same value repeats across many items, typing it invites variation. A Selectable feature solves that: users pick from a list instead of typing. The list is kept in Feature Data, where it can carry its own configuration, its own order and even a hierarchy. Because each item points to the list value rather than a copy of the text, a correction made once shows on every item it is assigned to. That is what keeps filters, reports and channels consistent.
Everyday analogy
The drop-down list of states on a delivery form. You choose “Kerala” from the list instead of typing it, so the courier never receives “Kerla” or “KL”.
In Perfion
Selectable values are managed in Feature Data. Super users and administrators can manage all of them; other users need access granted by an administrator.
Swipe sideways to see the full diagramTyped by hand, one colour becomes three. Selectable, it stays one value.
05
Keeping it rightConcept 05 · Each value has one home
Set Each Value at the Right Level
The product data problem it solves
A brand name is retyped on forty variants, and the price is edited in the PIM and in the ERP, so the two never quite agree.
The concept explained
A value should be set once, at the level where it belongs, and nowhere else. Some values belong to the parent product: with Inheritable on, a brand set on the parent is passed to each child item, and nobody retypes it. Some values belong to another system: with Read Only on, Perfion shows a value the ERP owns but stops users changing it, and a Remote feature can show data live from an external system. When every value has one home, there is one version of it.
Everyday analogy
A family surname. It is given once and every child carries it, while each child still has a first name of their own.
In Perfion
Inheritable and Read Only are settings on each feature. Brand is Perfion’s typical example of an inherited value, and Read Only is typically used for values owned by the ERP.
Swipe sideways to see the full diagramSet on the parent and inherited, or owned by the ERP and read only.
Best Practices
10 Best Practices for Features and Configurations in Perfion
Each practice says what a good data model looks like and what it costs to ignore it. Setting it up for your products is what BPAS consultants do.
01
01Name features by one convention
Data model · Feature names
The rule
Give every feature a clear, unique name in one style, such as camel case: ItemNumber, LongDescription. Use the Caption for the friendly label users see.
Risk if ignored
Names must be unique, letters and numbers only, with no spaces, and cannot start with a number. Formulas can refer to features by name, so a library of mixed styles is hard to search and easy to get wrong.
Get it right with BPAS
Not sure this is in place in your data model? Talk to a BPAS consultant.
02Choose the right feature type before data goes in
Data model · Feature type
The rule
Hold numbers in Number features with a unit, long copy in Text, and one-line values in String. Decide the type from what the value is, not from how it arrived in the spreadsheet.
Risk if ignored
A String holds one line of up to 256 characters. Numbers kept as text cannot use number rules, such as a number range in Validation, and do not sort as numbers.
Get it right with BPAS
Not sure this is in place in your data model? Talk to a BPAS consultant.
Values shared by a product family, such as Brand, are set once on the parent and inherited by every variant. Parents and children hold their own values only where they genuinely differ, such as Item Type.
Risk if ignored
Without inheritance, the same value is retyped on every variant, and a change to the parent leaves the children out of date.
Get it right with BPAS
Not sure this is in place in your data model? Talk to a BPAS consultant.
07Use item dependency for fields that only apply to some items
Configuration · Item dependency
The rule
Put category-specific or brand-specific features under an item dependency, so each product shows only what applies. Prefer dependencies at one level, and nest them only when a feature truly needs two conditions.
Risk if ignored
Every field on every item makes the item card long and the gaps hard to see. Perfion warns that nested dependencies can quickly multiply into very large and complex configurations.
Get it right with BPAS
Not sure this is in place in your data model? Talk to a BPAS consultant.
Illustrative scenario · not a client case studyA Business Like Yours
Illustrative scenario: an Indian kitchen appliance brand, run on one wide spreadsheet
A kitchen appliance brand sells about 2,400 items across nine categories through its own web shop, two marketplaces and a dealer catalogue. Orders, stock and invoicing are in the ERP. Product content is in a spreadsheet.
The Operational Challenge
One spreadsheet holds every attribute for every category, so a mixer grinder row has empty columns for water tank volume and burner type. Colours are typed by hand, and the Hindi and Tamil descriptions sit in separate files.
Each new channel gets its own copy of the sheet. Corrections made in one copy never reach the others.
Editors fill in columns that do not apply, or skip ones that do
The same colour in three spellings on the web shop filter
Marketplace listings rejected for missing or wrong values
Returns where the listed specification did not match the product
The Financial Transformation
In Perfion, each category gets its own features through item dependency, so a mixer grinder shows only mixer grinder fields. Colours and materials become selectable features with one list each in Feature Data.
Item Name and descriptions are localizable, with every language on the same item. Brand and warranty are set once on the parent and inherited by each variant, and item numbers from the ERP are read only.
Each item card shows only the fields that apply
One spelling of every colour, in every channel
Every language held on the same product record
ERP values kept as the ERP sends them
Illustrative figures for a typical Indian brand of this size. They add up, but they are not a client case study.
Cost line
Before (per month)
After (per month)
Difference (per year)
Editor time spent correcting and re-keying data
₹ 1,56,000
₹ 66,000
₹ 10,80,000
Rework on rejected or delayed listings
₹ 90,000
₹ 30,000
₹ 7,20,000
Returns caused by wrong specifications
₹ 1,20,000
₹ 50,000
₹ 8,40,000
Total
₹ 3,66,000
₹ 1,46,000
₹ 26,40,000
Illustrative saving a year₹ 26,40,000Same figures as the table, not a client result
Editor time
Listing rework
Returns
Before After
See your own categories as a Perfion data model, with only the fields each one needs.
prodRecord Live is a monthly webinar series on product information management, held on the second Wednesday of every month from January 2027. Each session takes one product data topic and works through it in plain English with time for your questions.
Who benefits from a Perfion data model: one model, three answers
One model
Promoter & CXOs
Can we launch faster, in more places?
A new channel or market reuses the same features and configurations, so expansion means adding values, not rebuilding the product file.
Product Data Manager
Is every product complete for its category?
With item dependency, each category carries exactly its own features, so a gap is a real gap, and Feature Data keeps every list in one place.
Product Editor
Which fields does this product need?
The item editor shows only the features that apply, grouped on tabs, with help text where a field needs explaining.
Vocabulary
Perfion Data Model Vocabulary and Definitions
From the features an administrator defines once, to the settings that decide how values behave. Each term shows what it means, why it matters, and a household comparison.
01
Feature
Data model · building block
Also called an attribute in other systems
Operational definition
A property you hold for items, such as Item Name, EAN or Color. Each feature has a unique name, a feature type and settings, and is defined once in the Features menu.
Why it matters in Perfion
Features are the basic building blocks of the Perfion data model. Everything else, from configurations to reports, is built from them.
Everyday analogy
A column heading in a register. It is written once at the top and every row fills in its own value.
What a feature can hold. Perfion has Boolean, Date, File, Image, Link, Number, Related Value, Search, String, Table and Text. String holds one line of up to 256 characters.
Why it matters in Perfion
The type decides how values are entered, checked and output, and is chosen when the feature is created.
Everyday analogy
Containers in a kitchen: a bottle for oil, a jar for rice, a tin for biscuits. Each is made for what goes in it.
The data model for a selectable feature: the features its items carry and their order. Product is the most common example; Brand, Customer or Image can have one too.
Why it matters in Perfion
The configuration order sets the grid columns, and with item dependencies it decides which features each item shows.
Everyday analogy
The columns of a school register: decided once, used for every student in the class.
Features placed under one item of a selectable feature in the configuration, such as one category or brand. They appear only on items that have that value.
Why it matters in Perfion
Each item shows only the features that apply to it. Several dependencies at one level work independently; nested ones require every condition.
Everyday analogy
A restaurant menu with a section per cuisine. Each section lists only its own dishes.
A configuration option that lets users manage table-like data, with several rows and columns, in a single feature on a product. Ingredients with name, amount and percentage are the documented example.
Why it matters in Perfion
Each row is created when it is added to a product, and shows in Feature Data with a reference to that product.
Everyday analogy
A recipe card with an ingredients table: one line per ingredient, with columns for the amount.
Features and configurations: questions product teams ask
Short answers, each with a link to the part of this guide that explains it.
A feature is one property, such as Item Name or Color, with a feature type and settings. A configuration is the data model for a selectable feature, such as Product: it lists which features its items carry and in which order. Features are defined once and can be used in many configurations.
Eleven: Boolean, Date, File, Image, Link, Number, Related Value, Search, String, Table and Text. A String holds one line of up to 256 characters; a Text holds long text as plain text, HTML or Rich Text. Search features hold API queries and are never used as a normal attribute.
Yes. Item dependency lets you place features under one item of a selectable feature, such as a category or a brand. Those features then appear only on products with that value.
No. Removing a feature from a configuration only hides it from users; all values stay in the database. Deleting the feature itself deletes all data related to it, and that cannot be undone.
Yes. A feature with Localizable checked holds its values in multiple languages. Each feature also has a caption, an alternative caption, an abbreviation, a unit and help text for every active language.
Perfion has a Read Only setting that prevents all users from changing a feature’s values, and it is typically used for values owned by the ERP. A Remote feature can also show data live from an external system, and is read only.
Yes. Features and configurations are part of Perfion itself, so this guide applies whichever ERP your product data comes from. What changes from one ERP to another is the integration that brings ERP data into Perfion.
See your own categories with the features each one needs, the lists that keep values consistent, and the settings that keep ERP data where it belongs. Choose the path that fits the ERP you run.