Edition Teams - Creation
Workflows and Edition Teams are one of the advanced features of Sales Layer. If it is not available in the platform it is because either the account, or the specific user, does not have permission to use this functionality.
The workflows, as the name suggests, allow you to create workflows in which supervisors can review editors' work. In this way, it is possible to manage and control user access to certain products or to certain fields.
This feature of the software allows for a great deal of customization. You can use it to do things as diverse as having people from different countries working only on those fields that apply to their languages, grouping them in an Edition Team.
To create an Edition Team, go to Manage Users, from the dropdown menu underneath your username and then to Edition Teams. Once there, click on Add a New Team and give it a name.
You also have to choose which table the team will be working with, whether it be products, variants, the Custom Entity tables, etc. It’s important to be aware of the fact that teams are configured to work for only one table at a time, nevertheless, you can always create more Edition Teams if needed.
Note: If you don’t have the option to create Edition teams it might be because you don’t have that feature in your account (reserved for Enterprise accounts) or you only have one user in your account (you should create another one first).
From here you have the option to further restrict which items from the selected table the Editors will be able to work on, these can be based on:
- Restrictions by attribute sets
- Restrictions by search criteria (following the principles of the Sales Layer Search Bar Tutorial)
- Restrictions by Tags (if you have created some)
Once you have chosen which products the Team can work with, you can then set up which fields the Editors can modify (selected under Editable fields). The rest of the fields will be visible but not editable.
You can also decide to hide some fields from the editors (selecting them under Invisible fields).
In the case of a translator, for instance, you could have those fields in the original language set as visible, but not editable, and those in the language they are translating to set as both visible and editable. If you want, you can hide every other field.
Certain fields, such as Product Reference and Name, are mandatory so they cannot be marked as invisible. Therefore the option to do so is not available.
The product reference field will not be shown as an editable field for editors because it is considered the minimum information required. Also, for this reason, it cannot be marked as invisible. As for the name field, it will be displayed as an editable field but it cannot be marked as invisible.
Finally, you need only choose which user will perform the roles of Supervisor and Editor in the team. Here there are two important nuances to be aware of.
If we choose only Editors but leave the Supervisor empty, what we would be doing is simply limiting the data the Editors have access to, according to the criteria established when we create the group. Therefore, any changes made by the Editor would not need to be reviewed and would be approved automatically.
As well as users we can also set an input connector to be an editor. In this way, everything that the ERP adds or modifies would be subject to the approval of a supervisor. Please note that default formulas can also be included in the connector configuration, to work with the most accurate and controlled product information.
Finally, you can choose if the editors are only able to work with existing products or if they are allowed to create new items as well.
Note: It is important to note that in order to use the import function via Excel, you need to have permission to create new items active in the editing group. Make sure that group members have this permission if they need to import in this way.
Note: In relation to bulk actions, some permissions may be restricted, such as changing statuses, changing categories, and Attribute Sets or deleting them, making bulk modifications, or adding tags.
SEQUENTIAL WORKFLOWS
The edition groups allow the combination of two or more workflows on elements of the same table. In that way, it will be possible to identify the different workflows created on the same table and select a sequence in the validation chain.
In order to organize a specific hierarchy you will have to indicate each edition group through the Dependence field.
Through this parameter, you indicate the team on which the next edition group depends and which enables it to start editing. The Dependence field, by default, contains the groups applied to the same table since it is not possible to create dependencies between different tables (Products, Variants, etc.).
As an example, we could have a team that is in charge of filling in all the basic fields in the main account language and another one that is only in charge of translating the multi-language fields. The second team will not be able to translate until the first group has finished. To respect this hierarchy, we simply insert the first group in the Dependency field, and so on with as many groups as you wish on the same table. Thus, when a group has filled all the fields, and these changes have been approved by the supervisor, the editor(s) of the next group will be able to start with the translations.
Warning: Editors belonging to a sequential edition group cannot import/create items even though they have this option active. Only users in a group without any dependency are able to import and create items.
