Seconded. Not being able to move around folders as you need is a bad look on the customer facing side. I need things ordered a certain way and alphabetical is not ideal.
Steve Bussey
Team•
Dec 15, 2025
I’ve been thinking about this recently. The big blocker we have on our side is the usage of packages (especially mirrored) and how that would impact the ability to sort. (Because we need to preserve the sort across the packaging, but we also want to keep the destination base’s ability to sort.)
We may end up doing this but saying that mirrored content cannot be sorted in the account.
Skyler Reeves
•
Apr 29
@Steve Bussey , this is a major pain point for me also—and one of the top 3 reasons I haven’t fully adopted Supered nor been able to get my clients to.
The mental model that comes to mind for me is how sorting works across linked databases in Notion (or even multi-homed tasks in Asana or Linear) where sorting is a property of the view, not the content itself.
When you create a linked database in Notion pointing at a source but with a new view, the view instantiates with the source's default sort. But from that point forward, the sort is entirely local and autonomous. The view was never "owned" by the source, so source sort changes are simply irrelevant to it.
Supered could apply the same separation if the data model supports it:
The package (source) owns the canonical content and its default sort order
The destination account inherits the sort at creation but has its own separate local view-level sort
Scenario
Behavior
Package first deployed to destination.
Local sort seeded from source default.
Source sort changes after deployment
Irrelevant. Local sort is fully autonomous unless reinstalled.
New card mirrored from source after deployment.
Slots into position per local sort rules.
Destination manually reorders folders or their contents.
Updates local sort; no impact on source.
In Notion, the sorting isn’t a property of the database itself, but rather a metadata layer owned entirely by the destination view.
That said, this would likely require there to be some additional level higher than the “Base” that the package installs into. Which seems viable since you’re already doing it with Sections and the Account itself.
Steve Bussey
Team•
Apr 29
From an underlying data perspective, this is just not compatible with packages and how they install into bases. I will think through an option here, but I’m still leaning towards this not being cleanly possible.
Without packages, this is a 2 hour task. So the fundamental issue is really about data hierarchy and less about the ability to do ordering.
2 packages installing into same base
A package installing into a base that already has content in it (same problem as above, just stated differently)
Mirrored packages add additional complexity because it’s very important that these are updated as the partner package is updated (it’s not an option to allow manual ordering w/ mirrored packages)
One option for 2 packages installing into same base (or a package installed into an existing base) is “go update it after the fact”, but then this is not compatible with mirrored packages.
I think that ignoring this for packages is not an option because it has been requested by many partners who use packages for distribution.
Frank Frost
•
Jul 17, 2024
It becomes very difficult to manage folder hierarchies when we are installing multiple packages in an instance —— Alphanumeric ordering isn’t sufficient to order cards for multiple packages being installed
Heather Park
•
Nov 10, 2023
Or starred, maybe? So that they'll be alphabetical by default, but then you can star your most frequently used?
Log in to comment and vote
Comments7
Jason Gardner
Dec 15, 2025
Seconded. Not being able to move around folders as you need is a bad look on the customer facing side. I need things ordered a certain way and alphabetical is not ideal.
Steve Bussey
Dec 15, 2025
I’ve been thinking about this recently. The big blocker we have on our side is the usage of packages (especially mirrored) and how that would impact the ability to sort. (Because we need to preserve the sort across the packaging, but we also want to keep the destination base’s ability to sort.)
We may end up doing this but saying that mirrored content cannot be sorted in the account.
Skyler Reeves
Apr 29
@Steve Bussey , this is a major pain point for me also—and one of the top 3 reasons I haven’t fully adopted Supered nor been able to get my clients to.
The mental model that comes to mind for me is how sorting works across linked databases in Notion (or even multi-homed tasks in Asana or Linear) where sorting is a property of the view, not the content itself.
When you create a linked database in Notion pointing at a source but with a new view, the view instantiates with the source's default sort. But from that point forward, the sort is entirely local and autonomous. The view was never "owned" by the source, so source sort changes are simply irrelevant to it.
Supered could apply the same separation if the data model supports it:
The package (source) owns the canonical content and its default sort order
The destination account inherits the sort at creation but has its own separate local view-level sort
Scenario
Behavior
Package first deployed to destination.
Local sort seeded from source default.
Source sort changes after deployment
Irrelevant. Local sort is fully autonomous unless reinstalled.
New card mirrored from source after deployment.
Slots into position per local sort rules.
Destination manually reorders folders or their contents.
Updates local sort; no impact on source.
In Notion, the sorting isn’t a property of the database itself, but rather a metadata layer owned entirely by the destination view.
That said, this would likely require there to be some additional level higher than the “Base” that the package installs into. Which seems viable since you’re already doing it with Sections and the Account itself.
Steve Bussey
Apr 29
From an underlying data perspective, this is just not compatible with packages and how they install into bases. I will think through an option here, but I’m still leaning towards this not being cleanly possible.
Without packages, this is a 2 hour task. So the fundamental issue is really about data hierarchy and less about the ability to do ordering.
2 packages installing into same base
A package installing into a base that already has content in it (same problem as above, just stated differently)
Mirrored packages add additional complexity because it’s very important that these are updated as the partner package is updated (it’s not an option to allow manual ordering w/ mirrored packages)
One option for 2 packages installing into same base (or a package installed into an existing base) is “go update it after the fact”, but then this is not compatible with mirrored packages.
I think that ignoring this for packages is not an option because it has been requested by many partners who use packages for distribution.
Frank Frost
Jul 17, 2024
It becomes very difficult to manage folder hierarchies when we are installing multiple packages in an instance —— Alphanumeric ordering isn’t sufficient to order cards for multiple packages being installed
Heather Park
Nov 10, 2023
Or starred, maybe? So that they'll be alphabetical by default, but then you can star your most frequently used?
Erin Kasmarick
Nov 4, 2023
Yes, please. For my OCD self. Thanks!