Although mentioned above, I wrote a more detailed explainer of nested collections. Let me know if this solves your problem with sub tags. Although I used ‘projects’ as an example, you could swap that out to ‘tasks’, ‘woodworking’, etc.
Nested collections with extended properties
User Story: you’re in a company and are part of many different project teams with various responsibilities. You’re part of the iOS App Launch project, New Website project, and User Research project. On Anytype, how do you keep all related documents and tasks together, particularly in a team setting with many other collaborators?
If every project had its own type/collection at the same hierarchy as Bookmarks, Images, Tasks, etc. this would cause bloat very fast in teams running many projects. Additionally, the project collections all have much more in common to each other than Video, Files, and Chat collections. In fact, all project collections might all have very similar properties—if not the exact same.
Collection 2.0 Experience
-
You have a Projects collection with global properties: Owner, Project Team, Objective, and Description. This is a parent collection.
-
You then nest three collections within that parent Projects collection called App Launch, New Website, and User Research.
-
All nested collections will inherit the parent properties from the Projects collection, and then they can add their own unique collection properties. The iOS App Launch nested collection might include its unique properties such Design Assets and Marketing Assets. These properties are not necessary on all Projects, hence it’s applied only to this specific nested collection.
-
If you are on a page in the New Website collection and you create a new sub-page inline, it will automatically apply the New Website collection to it. This helps keep related objects in the same collection.
Benefit
-
It adds some organisational capabilities to collections in general (to the sidebar and general navigation). There could be an ‘all collection view’ where you view all collections in the space. Could also add ‘grouping’ or ‘labelling’ so that certain collections are known to be for specific teams or use cases.
-
Keeps related objects together and minimises orphaned files. E.g. If the project gets cancelled, it’s easy to delete the entire collection (and all its objects).
-
It maintains company standard operating practices by having the same properties (and maybe even templates) inherited from a parent collection enforces a defined benchmark. E.g. every project has an owner, objective, KPI, etc.