Hi Fibery team! I’ve encountered a significant limitation in Table View sorting that makes organized workflows difficult.
The Current Problem: Currently, Sorting in Fibery is global. If I set a sort by Creation Date, it applies to everything. If I group my table (e.g., by “Task”), I cannot have the Groups sorted by Creation Date while having the Entities inside those groups sorted by Task Name.
The global sort “overrides” the internal logic of the groups. If Creation Date is the primary sort, entities inside a group will be scattered by date, even if I want them alphabetical.
The Proposal: Allow Independent Sorting for different levels of the Table View:
Level 1 (Groups): Ability to sort groups by a specific field (e.g., sort groups by the latest activity or creation date).
Level 2 (Entities): Ability to define a different sort order for the records inside those groups (e.g., alphabetical by Name).
Why this is important: In complex projects, the logic for organizing “folders/groups” is often different from the logic for organizing “items.”
I want to see my most recent Campaigns (Groups) at the top.
But inside each campaign, I want my Ads (Entities) sorted by their ID or Name for easy navigation.
Currently, I have to choose one or the other, which makes the Table View feel messy regardless of the choice.
Are you saying that for a table view with grouping via a self-relation, you want the first level items to be sorted differently that the second, third, etc. levels?
Because in general, different sorting options for levels and grouping is possible:
Independent sorting (as on your video) works when grouping by a different database. However, the issue arises when we use single-database grouping or self-relations.
Because the sort is global, if I set Creation date as the primary sort, the items inside my groups are scattered by time and lose their alphabetical order. If I set Name as the primary sort, my groups are no longer organized by their creation date.
So what should happen if there are multiple levels of self-related items? Do you want sorting to be definable per level? Or just ‘top level’ vs ‘lower levels’?
If the former, how do you imagine the UI could look like for this? At the time of configuring the view, there is no way of knowing how many levels might exist
I’ve visualized a potential UI solution that would make hierarchical sorting intuitive and easy to manage.
the Sort Menu should mirror the structure of the Table View. If grouping or levels are present, the Sort module should automatically display these levels as distinct sections.
How it works (as seen in the attached screenshots):
Level Inheritance: The Sort menu “inherits” the hierarchy. For example, if I group by AB Child, a section for “Level 1” (the groups) appears.
Independent Rules: For each level, we can define its own sorting logic.
Level 1 (Groups): Sort by Creation date (Newest first).
Level 2 (Entities): Sort by Name (Alphabetical).
Clear Visualization: This UI clearly shows which sort applies to the group headers and which applies to the records inside.
But one of the great features of recursive grouping is that there can be a limitless number of levels.
Your example seems to assume only Level 1 and Level 2.
What if the hierarchy is
Task 1
- Task 2
-- Task 3
--- Task 4
…
etc.
?
I assume therefore that you only want a distinction in how things are sorted between ‘Level 1’ and ‘All other levels’, right?
To address the “unknown depth” issue while keeping the UI clean, can be a “1-Level Default + Add Sorting for Next Level Button” approach.
The Logic:
Default State: The Sort menu shows block:
Level 1 (Root) (plus filters for this level)
Add Button for Sorting for deeper Level. (if you click - it adds (reveals) level and sorting as on screenshot) + adds button for creation for next level sorting if needed.
Exactly! To keep it simple and handle the “limitless depth” concern, I propose a progressive UI where levels are added manually by the user as needed.
The Logic (as shown in my previous mockups):
Initial State: The Sort menu only shows Level 1 (Root) and a button: “+ Add Sorting for Level 2”.
User Interaction: If the user clicks the button, the sorting options for Level 2 are revealed, and a new button appears: “+ Add Sorting for Level 3”.
Inheritance for Deep Levels: To handle the infinite nature of the relation, any level that doesn’t have a specific sorting rule defined simply inherits the settings from the last defined level. (or as it will be more coviniet to develop )
We don’t show Levels 2, 3, or 4 unless the user explicitly asks for them.
It was this bit that confused me
The view configuration does not (and cannot) know anything about the number of levels that might actually be present in the view.
I now get your idea of letting the user choose how many levels deep to configure (no matter how many views are present).
Out of interest, how often do you encounter needing to sort differently for the same type? What are some use cases that you can think of off the top of your head?
(in your first post, you talked about sorting Campaigns differently to Ads, which feels like not a good example, since they are different types for which the functionality therefore already exists)
Here are three use cases where sorting the same type differently is essential :
1. Priority-Driven Roadmap (Tasks → Sub-tasks)
Level 1 (Parent Tasks): I want them sorted by Priority or Deadline so I know what to focus on first.
Level 2 (Sub-tasks): Inside those parents, I want sub-tasks sorted by Creation Date or Name.
Problem: If I sort globally by Priority, my sub-tasks get messy because they often share the same priority as the parent, but I need to see them in the order they were created to follow the workflow.
2. Content Production (Main Topic → Sub-topics)
Level 1 (Main Topics): Sorted by Status (e.g., “In Progress” at the top).
Level 2 (Sub-topics): Sorted alphabetically by Name.
Problem: A global sort by Status makes the sub-topics list unpredictable, making it hard to find a specific sub-item if there are 10+ of them.
3. Financial/Budget Tracking (Main Expense → Line Items)
Level 1 (Categories/Main Expenses): Sorted by Amount (Descending) to see the biggest spenders.
Level 2 (Detailed Breakdowns): Sorted by Date.
Problem: I want to see the “Expensive” groups first, but inside those groups, I need a chronological log.
If your subtasks have the same priority as their parent, then you can sort by priority, then sort by creation date.
Maybe similar is true for the second example…?
For example 3, are you sure that these items should be in the same db? I would have thought that ‘category’ and ‘line item’ are ontologically different things, no?
Thanks for the suggestions! I see your point about nested sorting (Priority → Creation Date), but it works when we have priority for the task and sub-task the same.
When Sub-tasks have their own priorities (Independent from Parent):
A Level 1 Task might be “Low Priority” in the global roadmap. However, once a team member starts working on it, they find 5 sub-tasks inside. Two of them might be “Urgent/Blockers” (to finish the task) and three are “Minor.” * The Problem: I need to see those “Urgent” sub-tasks at the top inside that specific parent. (Also we need to sort by Creation Date )
Why Global Sort fails: If I sort globally by Priority, my “Urgent” sub-task (Level 2) might jump to the top of the entire table, losing its context, or it will be forced to follow the “Low Priority” of its parent. We need to rank the “Big Picture” by one criteria and the “Action Steps” by another.
And yes - if you can make two DB - it will work, but if you choose a “Single DB” approach for speed of capture and simplicity of the setup - this problem appears
Yes, and my suggestion would cover that I believe. Try it.
No, they will always nest under their parent. Grouping takes priority over sorting.
Well, therein lies the problem. Why does a level 2 task have Urgent priority, but is grouped under a parent with a Low priority?
It might make more sense if the Priority of a parent be (automatically) updated to always be at least equal to the highest priority of its children.
Overall, I think this should be fixed:
What does it mean if a subtask is Urgent but belongs to a parent which is not?
In general, a subtask’s priority may indeed not depend on its parent, but a parent’s priority ought to depend upon its children.
I think personally it makes most sense to only be able to configure the group sorting and the item sorting: “Item (group)” and “Item”. (Shown as two DBs, like we have now when you have different DBs) Then everything that is not the bottom level has one sort, and the bottom level can have a different sort.
This could also relevant for filters and fields I think. If I want non-bottom levels (groups) to have less fields than the their children, right now this is not possible when you have recursive elements.
Also since all your examples are only 2 levels, I think for recursiveness, if it needs to be defined per level that will be not feasible. Since someone can then add another level by editing data, and now that level has no sort (or fields of filters if we add this behaviour) in the views you configured.
Here is another screenshot:
In this database, I’ve hit a wall: without creating a second DB, I can’t sort main tasks by ‘Creation Date’ while having sub-tasks sorted by their own ‘Internal Priority’.
Even if a task isn’t ‘Urgent’ on a global level, once we actually start working on it, I need its sub-parts to be completed in the specific sequence I’ve assigned to them. Currently, global sorting makes it impossible to have both.
And the idea that the global task should simply inherit the priority of its subtasks is not a viable option here.
I think tasks is a common issue. This is also what I’ve been thinking of. Sometimes I thought it would be nice to group tasks by the state field as the top level, and then group them by parent task (self-relation).
Just checking I understand the use case in the example you just shared:
You want
Task 1, Task 2 and Task 3 to be ordered by Creation Date, but their linked subtasks to be ordered by Priority. Correct?
If so, apply sorting
Sub Task Priority
Creation Date
Given Tasks 1, 2 and 3 don’t have a value for Sub Task Priority, they will sort by Creation Date
)
