Application User Interface
The Pimberly Application User Interface is hosted within a web browser page and is divided into three primary panels.
The first is the Console Selection panel on the left-hand side. This allows the user to switch between core modes of operation, e.g. Admin (where the application is configured), Products (allowing viewing and maintenance of product data), Media (viewing and maintaining image data), and Logs (access to Logs from imports and exports).
The second panel, under the Admin console, is a menu of all the configuration tasks available. Under the Products and Media consoles, it is navigation and filtering panel.
The third panel is the main working area, which alters depending on your Console and navigation selections.
An attribute is any property of a product, such as Price or Description. There are many types of attribute (for example, currency, text, true/false) and each type may have several input options (rich text, multi-select, checkbox, etc.)
Every attribute is configurable and there are no mandatory fields. The only required element of a product is a unique identifier.
Attribute Sets are used to organise attributes into logical groups to aid the user when viewing and maintaining product data. They are only visible within the Pimberly application and are not included in any data that gets exported out of Pimberly.
Each attribute must belong to one attribute set, but attributes can usually be moved from one attribute set to another if a mistake is made or if you need to change the make-up of your attribute sets. You can also move attributes within an attribute set (up or down) if required.
If your application contains many attributes, then multiple attribute sets can make navigation between the attributes simpler. However, it isn’t necessarily good practice to create lots of attribute sets just for the sake of it.
Some examples of typical attribute sets are Media, General, Pricing, Dimensions.
There must always be one ‘Default’ attribute set, which is usually called ‘Basic Attributes’. This contains any attributes that are common across all product types and schemas. Typical Attributes in the default attribute set are Description and Part Number. Any attribute that might only be required for certain product types or other conditions should not be included in the default attribute set.
Category Trees are hierarchical sets of product categories. They can represent the categorisation of products from different perspectives of the business or of one or more channels or websites. Any single product can be associated with one or more nodes within a Category Tree and can also be associated with nodes across multiple category trees.
For example, the business might have an internal merchandising category tree, which includes Menswear->Tops->Shirts, and a website hierarchy which includes Men's->Formal->Shirts and Men's->Sale.
A product's categorisation is often exported in the data sent to e-commerce platforms.
Assignment of a product at a certain level of product type, e.g. Colour, doesn’t get inherited by the parent or child products. Usually, categorisation is only at one product type level but could be at multiple if required.
A channel can provide data using different mechanisms, such as flat file over FTP, data extract via REST or custom export types to Magento, SAP Hybris, etc. The channel defines the data to be exported via a set of mapping rules, which can allow for data transformation into the destination format.
Only products that have been ‘released’ for this specific channel can be exported via the channel. Attributes can be configured to allow data to be held specifically with reference to a given channel if required.
The workflow automation capability within Pimberly allows for automated release to one or more channels, once certain conditions are met.
DAM, which stands for Digital Asset Management is a function integrated into the PIM that helps clients store their product assets, such as brand logos, product logos, product images, and media files.
The decision tables feature enables users to configure actions based on specified conditions in an easy-to-use format.
Within a particular decision table, rules can be set up in a similar manner to workflows and assignment rules: an action is triggered as a result of one or more specified conditions being met.
ETIM (European Technical Information Model) allows companies to structure disorganised data; it can give any electrical or tech type item a clear straightforward description. Every product is assigned to one specific article class and defined with all its relevant features.
Enterprise resource planning (ERP) refers to a type of software that organisations use to manage day-to-day business activities such as accounting, procurement, project management, risk management and compliance, and supply chain operations.
As standard, a company’s ERP sits behind a PIM platform helping customers manage their product information in one central repository with the ERP powering product pricing and stock level attributes.
Feeds provide data to Pimberly from external sources. They can be set up to pull data automatically from an (S)FTP server, HTTP(S) or to allow third-party systems to push data to Pimberly through our REST API.
Feeds allow the user to receive product information from suppliers, data aggregators (eg. CNET) as well as from any existing internal systems. They can update in real-time, periodically, or be scheduled to run at specified times.
File Transfer Protocol (FTP) is a standard network protocol used for the transfer of computer files between a client and server on a computer network. As well as the standard FTP protocol, Pimberly also supports SSH File Transfer Protocol, or SFTP.
GS1 provides unique numbers to identify, capture and share information on any product, asset or location. Their barcodes and unique number structure allow companies within the retail, online, foodservice to complete, real-time inventory picture of all products.
For companies who trade internationally, or who are looking to do so, locales within Pimberly allow you to store translations of attribute values, or values in alternative currencies.
You can hold this data against the product, creating a central source of information that is easily accessible for individual users to publish on international markets. The same can be applied to imagery, allowing you to create locale variations depending on where this information is being published.
Lifecycles comprise a Lifecycle Template, linked to a schema, and a number of Lifecycle Stages, and represent the various stages of a product's route to being made available for sale. For example, a new product may need to go through Enrichment, Photography and Marketing stages, before reaching On Sale and eventually Discontinued stages.
Each stage can define requirements which must be met before a product can move to the next stage, and stages can be used to prevent a product which isn't fully enriched being released to channels.
Product Types are used to define the relationship between one or more other products. Product types often describe a hierarchical relationship, such as parent/child or set/members, etc.
NB: Each product in Pimberly must belong to one product type.
The Attributes held against each product type will often be different from the attributes of a different product type. For example, in a style-colour-size relationship, the manufacturer, material, and washing instructions might be held at the style level, the colour description and price at the colour level, and the SKU code, full description and size at the size level. We can use the product types within the schema to define which attributes are applicable for which product types.
Although it is possible to define deeply nested relationships between product types, it is generally best practice to keep to a maximum of three levels as the import and export processes can reach up to three levels. Where more than three are required, this is still possible, but the import and export processes will require more attention.
Product lifecycle management (PLM) refers to the management of data and processes used in the design, engineering, manufacturing, sales, and service of a product across its entire lifecycle and across the supply chain.
A schema is a container for a range of products and the rules associated with those products. Each schema holds a taxonomy, which is usually a hierarchy of product classes, within which the rules for which attributes are applicable at that level of the taxonomy for each of the defined product types.
Every product must belong to one schema and within this, one node of the taxonomy.
Attributes can be used within multiple schemas but any instance of a product within one schema is independent of another product in another schema, even if they have the same attribute(s) defined.
Certain rules are held at the schema level, such as product coding structures and user permissions.
It is best practice to have one schema unless there are strong reasons to have multiple. This is because of the additional complexity introduced with multiple schemas when trying to merge products between schema.
Scopes provide the ability to hold variations of an attribute value intended for different sales channels. Through scoping, you can hold variant data dependent on where you are pushing this information, whether that be branded websites, key clients, or reseller channels like Amazon and eBay.
SSO (Single Sign-on)
SSO allows user authentication to be federated to a third-party identity provider, such as Microsoft Azure Active Directory. When using SSO, users are redirected to the identity provider during login, enter their credentials, and are redirected back into the application.
Each schema holds a taxonomy, which is usually a hierarchy of product classes, within which the rules for which attributes are applicable at that level of the taxonomy for each of the defined Product Types are defined. Any single Product must belong to a single node of the Taxonomy.
As well as allowing you to configure the appropriate attributes to be displayed, you can also use the taxonomy to aid searching and filtering of products, for example, filtering the product list for products in the Trousers node of the taxonomy for example.
Any decisions made regarding the applicable attributes at different levels can be changed with care later.