Glossary
Account
An account is a company account. It is the highest level of the hierarchy. It is used to manage users, teams, tables, and all the data of the company.
A personnal account is referred to as a user account. A user account is linked to one or many company accounts.
Table
Product-Live allows to create Tables. Tables can be viewed in the bottom left of the application, like a tab in a spreadsheet document.
These tables can be used to store different types of data. For example you can store products, orders, offers, suppliers...
Best practice
- Table's title must be in the plural, try to use the minimum of words (1 is the best)
- Table's key must be in the plural and in capital letters
Scope
You can create as many tables as you want
Items
Each lines in a table is called an Item.
Each Item as associated with one an only one:
Levels
A level is the answer to the question "What does each rows in the table represents?", or with the technical question "What does each items in the table represents?".
For example in a table named "Products" each line of the first level represent a "Product". So in this example there is one level named "Product".
Best practice
Level's title must be in the singular
Multiple levels allow to model one to many relation between items. If you work in the clothing sector, you know that the products are represented by a model, each model being declined in several color models, each of the color models being declined in size color model.
It must be read as: one item at the level Model as two declined items in red and green at the level Model color, and these items are declined in size S and L at the level Article.
Technically levels allow to create one to many relationship between items with a cascade on delete constraint: if an Item is deleted, his children are deleted too.
Moreover an Item with a Level index greater than 1 must have a parent Item.
If this not what you want, you must consider using a multiple tables architecture.
You can see that properties associated with items are defined by level. Properties in bold are Identifiers that uniquely identify items for each items. You will see later in the document what an Identifier field means.
Another example would be to model orders and order details. Then you can create a table order, with a level 1 : order and the level 2: order detail. This way an order can be associated with one or many order detail.
You can read more about items with combinations in the Multiple levels guide.
Scope
- A table must have at least one level at index 1.
- You can create up to 5 levels.
Partitions
A partition allows to isolate items (lines). An item can be associated with one and only one partition. For example, it can be used to model:
- Items life cycle: i.e. active and archived items
- A head quarter with several brands that must share the exact same data structure.
- Business steps in a process with permissions on user groups to define which user group can view which partitions
Partitions can be accessed here:
Be aware that the number of total items per table has an inpact on:
- The performances of the filters and sort options.
- The file size of the files generated for export and imports. For example 100k Items with 150 properties is usually a 100 Mo file.
In addition none of the users should be able to access or to filter/sort all Items, so use the best practices below:
Best practice and scope
- Limit your partitions to 150 000 items. You can achieve by:
- Creating partitions based on items life cycle (active, archived, archived 2015...)
- Creating partitions to model business steps in your process
- Use Permissions to limit access on items by user groups.
Properties
They are four types of properties that can be associated with items.
- Identifier to uniquely identify items by level
- Classification to create hierarchical categories with which can associate fields specific to categories
- Field to create any other properties. You can choose between several data types: text, list, image...
- Conditional formatting to create compliance rules and automatic statuses
Below a more complete description of each properties type.
Identifiers
Identifiers are used to uniquely identify each items. When an item is created at least one of the identifiers must be filled. Examples of Identifiers for a product table would be:
- EAN 13
- SKU
- ID
- Product code
- Reference
It allows to model uniqueness constraints: within a Table for a given Level, each Identifier value is unique. If a user update a value that violates a uniqueness constraint, it will not be saved and a message is prompted.
So use Identifiers only if the value is absolutely unique for each Items of a Level.
You can create up to 5 identifiers by table.
Classifications
A classification is a hierarchical structure of categories. It allows to:
- Classify your items in categories.
- Associate Fields to categories.
- Filter the items associated with one categories to display specific fields
Scope
- An item can be classified in only one category in a Classification.
- You can create up to 5 Classifications by Table, then an Item can be classified in up to 5 Classifications.
- The maximum depth of the Classification tree is 5.
Fields
Fields represents properties on items. A field must have a data type, a data type defines how the property is edited and also define how the data are represented in the Items xml file.
A field is uniquely identified by its key. The key is used in Items xml file. The best practice is to use a word in english, formatting in capital letters separated by _ and shorter as possible. Be careful a data type cannot be changed. Trying to create two fields with different data type will generate a warning, and the second field will be ignored. If you want to update a data type, you must create a new field with a new key, in production this will save you a lot of problems.
The order of the fields here has no effect on the position of fields in the interface. The position of the fields is not defined here, it is defined in Screens which are presented later in this documentation.
Best practice
As you will see in the captures below, a description is displayed above each cell when edited. This is the description of the field, use it to be precise and concise on what you expect from the user on that field.
Fields can have these data types:
Single line text
Long text
HTML text
Number
For numbers data type you can set:
- Prefix: use it for currency or unit
- Suffix: use it for currency or unit
- Precision: number of decimal places displayed
Numbers are formatted depending on the localization of the browser.
Example: 1 000,99 in Europe will be 1,000.99 in US.
Single select
Multiple select
Quantified multiple select
Same as multiple select but you will have to set a quantity for each value.
Quantified multiple select with comments
Same as multiple select quantified but you will have to set a comment for each value.
Date
Date time
Image
Attachment
Dynamic-Lists
Dynamic lists allows to set restrictions on options that can be selected on a Single Select or Multiple Select field, or categories that can be selected on Classification, depending on values of other fields.
For example it can be used to:
- Limit options that can be selected on a single select field depending on the category set for the item.
- Create cascading select (options available in field 2 depends on option selected in field 1).
- Create more complex rules (example: for a product the type of pallet that can be selected depends on the weight and the supplier).
It is a planned feature and is not available now. If you are interested in testing this new feature let us know.
Formulas
It allows to automatically fill a cell. It will be the same engine that the Rules engine but execution will be synchronous.
- Calculate dimensions
- Auto generate texts from attributes
- Calculate all taxes included price from a price without tax column and a tax column
- Calculate status based on other fields
It is a planned feature and is not available now. If you are interested in testing this new feature let us know.
Matrix
The Matrix defines:
- Which Fields are common to all items.
- Which Fields are specific to categories for each Classifications.
For example if you have a Products table, you can model that some Fields are common to all Items (Title, Description, Height, Width...) and other Fields are specific to categories (for example: Collar shape and Sleeves length are specific to the Dress category).
Best practice and scope
- A Field is either common or specific, but cannot be both.
- If a Field is specific, it can be associated with one or many categories within the same Classification.
- A Field cannot be specific to two Classifications, therefore if it is associated with a category of a Classification, in cannot be associated with the category of another Classification.
- In the life cycle a Field can be updated from common to specific, or from specific to common.
Conditional formatting
Conditional formatting allows to automatically highlight a cell on conditions.
A good usage to present this feature is a Products table in which you want to define rules like "This field must be required", "This field must be less than 300 characters"...
For this you will create a Conditional formatting name "Data compliance" and define:
- The different statuses possible and the color associated (Valid=green, Invalid=red, Recommended=orange)
- The rules associated with each of the statuses
In the frontend, the Conditional formatting column will be displayed like below and cells are highlighted with colors depending the rules you define on it.
When the user edit the cell, depending on the rules a message a displayed to correct the problem:
And when user want to know what is left to be done an item, he can click on the cell of the conditional formatting column to get the summary:
In this panel, the user can also click on the attribute title to be directly redirected to the concerned cell:
Scope
- You can create up to 5 Conditional formatting columns by table
- The rules that can be associated with Fields are defined in the API
- You can also create inter-fields rules, for example: If this Field is not not empty, then this other field is required
Sections
Sections allows to visually group properties. They are displayed in the grid and in the detail view.
Screens
On a screen you define:
- The order of sections
- The order of columns relative to sections
- The size of columns
- If the column is editable or not.
- If the column is fixed.
You can also define the height of the lines. For example, if you need to display only media, it is a best practice to set a higher line height to get this render:
You must use screens to:
- Mirror existing systems, then each screen name has the name of the mirrored system (ERP, PIM...)
- Create screens by Teams, for example: Product Content Manager, Sales, Marketing...
- Create screens for partners, for example: Suppliers, Retailers with only the fields that you want to share
You can then define permissions for each team to access a screen.
You can read more about permissions here.
What you need to remember is that Screens are defined by administrators and define rights on columns.
Users can hide/show columns within columns defined by administrators, you can read more about it here.
Next
Learn the basics of how to model your data.