When considering Akeneo you will hear the term workflow mentioned a good deal and for good reason. Having a solid product data enrichment workflow is essential for any undertaking involving a Product Information Management software (PIM).
When most people hear the term workflow, they think of a task-based tool where they can assign work to team members to track their progress along the way. These tools also typically have granular notifications and dashboards for insights into projects and their status.
That is not what you should expect with Akeneo. Rather, a workflow in Akeneo is a collection of features that when employed will net more efficient product data enrichment. You can think about workflow as the flow of the product from creation, typically in an ERP system, to its end destination such as an e-commerce website, online marketplace, print catalog, etc.
We will introduce all the features and practices that together make a workflow in Akeneo PIM.
WORKFLOW IN ACTION
When speaking of workflow we are talking about maximizing the following features in Akeneo:
- Completeness – defining when a product is “complete” and ready for publishing
- Permissions – application of a user group(s) to applicable areas in a PIM
- Channels – selection of products and information to export
- Categories, Attribute Groups, & Locales – various methods to define, group and translate products
- Projects – A way to track the enrichment for a subset of the product catalog
COMPLETENESS IN ACTION
Completeness is both a goal and a metric in Akeneo: a goal in that all products should be assembled, organized, and augmented; a metric in that completeness is a key performance indicator (KPI) which some or all products are measured against—how complete is this product and its data?
The first step toward completeness is to establish product families. A family is a template or assembly of product attributes that, when completed, defines a product. The process of adding attributes to a family and then populating those details for each product such as size, color, dimensions, etc. moves that family toward completion.
In summary, completeness tells you how close your product data is to the standards you have set.
PERMISSIONS IN ACTION
Permissions are granted to user groups and user roles—they do not apply to individual users. In short, every user dons a role. And most users also belong to a group of users organized around a set of products and/or tasks.
For example, Tim is a user and, upon his account’s creation, is assigned the basic user permissions (role) on the Marketing team (group). Notice user roles and groups often mirror a business’ structure.
What does that mean in terms of permissions?
Tim’s user role defines what he can do in the PIM. Can Tim create or edit attributes, add and/or remove users, and generally have access to Akeneo’s core settings? You pick. User roles are entirely customizable.
Most Akeneo setups employ a hierarchy for user roles—an administrator role and a user role. Standard practice in technology. The administrator role possesses permissions that the standard user does not.
CATEGORIES, ATTRIBUTES GROUPS, & LOCALES
Let’s take the concept of permissions further by applying it to categories, attribute groups, and locales.
Categories in Action
Akeneo categories are used strictly to categorize items rather than define or grant attribution to products as is the case in other systems. Categories are typically used to build web navigation as seen in many common e-commerce implementations. But while fitting for e-commerce teams, other teams within your organization probably view and categorize your products differently.
Thankfully in Akeneo, you can have as many different taxonomies, or “category trees” as you’d like. An engineering team can categorize a widget as “X” while the e-commerce team can categorize the same as “Y”. This way, a single product can live in many categories.
Applying Permissions to Categories
You can add user groups to the permissions section of a category to give that group access to the products most pertinent to their responsibilities.
For example, if you have a team that only focuses on enriching product data for electronic products, you add the “Electronics Team” User Group to the “Electronics” category and those users will only see that subset of products in the catalog.
Categories are also how you enable the Akeneo approvals process. You do this by adding a user group to the “allowed to own products” permissions setting. This means that any users in the “allowed to edit products” will need to have their enrichment efforts approved by users in the Manager user group. This is an excellent quality control measure that is baked into the Enterprise Edition of Akeneo PIM.
Attribute Groups in Action
Since user groups help shape what users access in Akeneo, you can reduce a user’s options and simplify their work. Imagine a product with 200+ attributes and having to scroll around the page to find the attributes you need to enrich. If you are on the marketing team and are only responsible for ten of those attributes, you can apply the marketing user group to only that attribute group so that when you go to enrich products, you are only presented with those attributes that are pertinent to your work. While attribute groups are a great way to group like attributes together – Marketing, Technical Specifications, Media etc., you should always think about how your teams work internally, who works on which attributes, and create your attribute groups accordingly.
Locales in Action
locales are the final place where user groups can be applied to effect what product data users can access. A common use case, your business may rely upon an external translation service to handle translating product data into different languages. With permissions, you can give limited access to those external agencies.
Channels in Action
Channels in Akeneo are an often misunderstood feature. In summary, a sales channel (e-commerce, marketplace) does not equal a channel in Akeneo. Depending on your business and PIM implementation, channels may not play a role in an overall workflow.
To explain, products are not segmented by channel by default. An approach would be to build a category tree for each channel and organize your internal teams by those channels (or vice versa). Either way, the key is to use a channel to limit the data and products requiring upkeep. Furthermore, if you have an e-commerce channel and a print channel that have different values for the same attributes, you should make those attributes scopable. Scope, combined with permissions as discussed below, limits the user to the correct values that you’ve made editable via the channel.
Projects in Action
A project in Akeneo most resembles a typical project management feature. A project is essentially a filter and calculates completeness based on the percentage of attributes that require enrichment.
A project can only be applied to one channel and one locale at a time. Therefore, you will need to create a project for each channel / locale desired. By creating a project with a due date, all users that have edit permission for that project’s attributes are automatically included and can expect in-app notifications at the time of project creation and three, five, and seven days before the due date. Projects are a great way to track the completion for things like new and seasonal product launches and overall tracking of product lines.
As you can see, workflow in Akeneo is less about tangible workflow management and more about creating an efficient product enrichment process. Product enrichment is done in parallel instead of having to wait for someone else to complete their work before you can get started.
