🗓 Released June 5, 2022
✨ Collections become global entities
In the past few years, we've seen many customers scale from using Samples in just one or two teams, to dozens of teams with global reach. Because of this, we are thinking of ways to leverage shared resources (e.g. samples & looks) to streamline some of the day to day processes, while also allowing independence at the local or team level. The changes in this release are only the first steps in this effort.
Look out for this icon 🔀 to see how your configuration, data or workflow may be affected immediately upon release
Designers & Seasons become shared global attributes
Designers & Seasons will no longer be created at the department level but only at the Global level.
- 🔀 Migration note: Upon this release, all Designers at the department level will be aggregated and merged at the global level. The same goes for Seasons if you did not have the Global setting already enabled previously.
- When creating Designers or Seasons, there will no longer be the option to select a Department.
- When creating Designers, the setting to enable "Requires Return Disclaimer" will not longer be an option. This feature simply acted as a default setting when creating new collections. This setting will remain at the collection level (see the next section for details)
Collection Hierarchies become global with Department level activation
Collection Hierarchy—which by definition are a combination of Designer Season & Collection — will also become global entities with an activation setting per department. Activating a collection for a department allows it to be used when creating new samples using any method.
If importing, copying from master list, or receiving samples, the collection or created on demand at the global level, and then activated for the department. (NOTE: If the user is importing a collection that is not created/activated, they will need the associated user permissions to complete the import)
- 🔀 Migration Note: Today's department level Collections will be aggregated and created at the global level. Departments in which these collections existed will be linked to the global entity and enabled.
- Department independence: Members of individual departments are still able to create new collections as they need, but the only difference is that they will be saved at the global level and activated at the department level.
- Bonus Feature: The interface changes are designed to make it easy to create a new collection & enable for your default department (how it worked before), OR, enable for all departments that you have access to (new & improved workflow).
Since collections are becoming global entities, the setting to Require return disclaimer will also become global.
- 🔀 Migration Note: There may be cases were Department X has the setting on but Department Y as the setting off. In this case, the migration will carry over as ON.
- Bonus Feature: There is now a way to control the return disclaimer at the template level to mitigate this impact and to give users more control. (See section below called "Improvement to Return Disclaimer")
The option to define Retail Stockists for collections has been removed.
Archiving a Designer, Season or Collection changes
- Archiving a Designers or Seasons will only prevent them from being created in new collections from the Collections Manager.
- It will no longer hide those Designers or Seasons in the Create/Edit Samples screen, as it did before.
- In order to hide all collections for a particular Designer or Season, you must archive each Collection.
- Archiving a Collection will deactivate that Collection for all departments.
- When importing (through any method) Inventory or Master List Samples, archived designers and season will no longer be automatically unarchived. ONLY Collections will be automatically unarchived upon import.
- 🔀 Migration Note: To make the transition seamless, we will migrate Collections of archived Designers or Seasons to be archived themselves. This will make the Create/Edit Samples experience the same before and after the release. Though the actual final effects are the same, Collections which were not archived before, maybe become archived after the release.
User Permissions changes
Some user permissions are no longer relevant to the new structure so they have been removed and a suitable replacement has been added. The following permissions were only impacting the department level and why they are deemed irrelevant moving forward.
- Ability to delete a Designer (if unused)
- Ability to delete a Season (if unused)
- Ability to delete a Collection (if unused)
- Ability to archive or unarchive a Designer
- Ability to archive or unarchive a Season
- Ability to archive or unarchive a Collection
- Ability to edit Designers
- Ability to edit a Season
- Ability to edit a Collection
🔀 New Permission Scheme for Collections
Permission name | Level of Impact | What it does | 🔀 Migration plan |
---|---|---|---|
Ability to Manage new Global Collections | Global level only | This permission allows the user to create new global designer, season or collections. Note that the following compound actions will ignore this permission: Master List Copy to Inventory, Receive between departments. Users can also delete a Designer or Season but only if it does not exist on any collections. Users can delete a collection but only if not being used in Master List, Live or Unverified Inventory, in any Look, in any Request, in any Send Out. |
This will be allowed for all user roles upon release as there is no permission today to control this. |
Ability to Manage Collection activation for a department | Department | This permission allows the user to manage their own department's activation of global collections. The following actions will bypass this permission: Master List Copy to Inventory, Receive between departments, EOL recovery, Cascading from Master list |
Same as above |
Ability to Edit existing Global Collections | Global + cascade to all departments | This permission allows the user to Edit or Archive existing Designers, Seasons & Collections. Changes will impact each department using the collection. User can change the designer name only when not found on any open send-outs. User can change the Season Code & Season Year at any time. Season name can be changed only when not found on any open send-outs User can change the hierarchy (Designer, Season, Collection Type) of a Global Collection only when not found on any open send-outs. User can change the Requires Return Disclaimer setting for a Collection at any time. |
This will be enabled for anyone that had any of the deprecated permissions enabled. |
Improvement to Delivery Document Templates
New Return Disclaimer setting
As mentioned above, Requires Return Disclaimer can still be set at the collection level, but cannot be set at the department/collection level.
We have now added a feature to make this more flexible at the template level.
Delivery Document Templates (Proforma, DDT, Delivery Memo) have a new setting called Return Disclaimer with 3 options.
- Automatic based on Sample Collection (default) — The Return Disclaimer will automatically activate if the Send Out contains samples in a collection that has the Requires Return Disclaimer setting.
- Always On
- Always Off
🔀 Updated Return Disclaimer text in default templates
The provided return disclaimer text in the landscape & portrait default delivery memo templates has been revised. This text will be applied to any send out (open or otherwise) using either of these default system templates.
🔀 Sample List Sorting moved inside template
Sample sorting has moved inside the template and is no longer defined at the user level
Upon release, sorting will reset back to the default which is the Scan Order.
Workflows
Workflows affected
Affected means the steps or permissions that are required to accomplish a task may need to be adjusted or reconsidered.
Creating a collection from the user interface — Previously, a user could create a collection directly in their department. Now, they must create the global collection first, then activate it for their department. Or, if the collection already exists as global, simply enable it or their collection.
Creating a sample manually from the user interface — If the user wants to create a sample in a new collection, they must have the appropriate permissions to either create the global collection or activate a collection for their department. Also, the + button to add new Designers & Seasons directly from the Create Sample screen can now only be done by first clicking the + Collection button > Create New Collection.
Creating samples via excel — If the Collections field is unlocked, and the user attempts to upload samples for a new collection, they must have the appropriate permissions to either create the global collection or activate a collection for their department in order to complete the upload. Upon release, all users will have the appropriate permissions, it's only if they are turned OFF, will they be affected.
Creating a collection from the API — There are some breaking changes to the Collections endpoint. See the API changelog for details.
Creating a sample from the API — The new permissions will be considered depending on the user role assigned for each api key.
Workflows not affected (but notable)
Not Affected means the steps or permissions that are required to accomplish a task will not change
Creating a sample via FTP — FTP uploads are always executed with admin level permissions even when done via the Mapping interface.
Loaning or Transferring samples between departments & customers — The collections for samples being moved across departments or sites will be automatically created, activated or unarchived as needed regardless of the user's permission.
Copy master list to inventory workflow — The collections for samples being created based on a Master List sample will be automatically created, activated or unarchived as needed regardless of the user's permission.
EOL Recovery — The collections for samples being recovered will be automatically re-activated or unarchived as needed regardless of the user's permissions.