More Flexible Board Columns/Rows

As I’m evaluating Fibery, I’m missing some key features for product roadmapping that will keep me from migrating to it. This is mainly in regard to the Board view (aka swimlane, card), which I have found is significantly more consumable for stakeholders compared to a timeline view and is a critical feature needed to replace roadmapping tools.


  • As a Product Manager, I cannot migrate to Fiberly for roadmapping purposes because of limitations in the Board view

Tools to Reference:

  • Roadmunk
  • Coda

Features Missing:

  • Cannot group by calculated values (see Coda)
  • Cannot group by lookup fields via relations (see Coda) EDIT: This is incorrect, it seems my issue was trying to lookup a Text value and group on it (see screenshots in example follow-up post), which isn’t supported. So, limitation is actually "Cannot group by Text Values.
  • Cannot group on dates (unless I create a Dates type and maintain it to include all dates)
  • Cannot group on part of a date (assign a due day to a task, then show it grouped by Month+Year, Quarter+Year, Week+Year, etc) (See Roadmunk)
  • Cannot group on one portion of a Date range (group by Month+Year of End Date) (See Roadmunk)
  • Cannot assign things without dates to placeholders for presentation (See Roadmunk for Soon and Later status). Typically you want to group by some level of a date, but also show upcoming things that haven’t been assigned to a period of time yet


  • Open the Fiberly OKR template/app
  • Edit the Objectives type
  • Add a field for “Date” with a type of Date and set as a Date Range
  • Apply a date range to each Objective
  • Edit the “Objectives by Quarter” view
  • Click on the dropdown for “Column”
  • See that you cannot group on the Date field you just setup (with roadmunk i can assign things like Epics to a Month, then can generate another view for Epics by Quarter, or Epics by Year that use the same field)

Value to Fibery:

  • Clearer Value Compared to Notion: Provide additional differentiation compared to Notion. Notion already is behind Fibery on this type of view, but the nuance that you can group by some things but not all is hard to describe. You really need to say you can support grouping by all things, while Notion doesn’t
  • Match Coda on Features: Coda can group by All The Things! Feature complete compared to Coda is where I think Fiberly should be at the very least. Seriously, try the Coda Card view. They made this capability generic, then they limit whether you can drag cards between the columns based on the column type (regular vs calculated).
  • Ditch Your Roadmapping Apps: Treat dates as a configurable entity for presentation, rather than a dumb piece of text. Your OKR template is useless if I have to manage every level of date detail I want. See Roadmunk for how this should be done. Their approach enables you to maintain a date range field, then you can group the items by either the starting or end date, at any level you set.

Bottom Line

  • Fiberly must support grouping by lookup fields that you could group on directly. This seems like an oversight and is an inconsistency in the product. Why can I group on a field when it is directly associated with an item, but when it comes in as a lookup I can’t?
  • Fiberly must support grouping by every single field at a minimum to compete against general productivity tools (Notion, Coda, etc)
  • Fiberly should support more flexible Date grouping, since you are a bit more focused on project management and roadmapping

Screenshot Examples
Roadmunk Screenshots all Demonstrating Views of the Same Date Fields

Screen Shot 2021-01-29 at 2.02.25 PM Screen Shot 2021-01-29 at 2.02.08 PM


Hey Nick,
Thanks for the feedback!

The part about dates goes together with the Partial date entry topic. There is a workaround (auxiliary Types) that we described in option 2, but we realize it’s a :poop: solution. Your post motivates us to look for a better one (:

Cannot group by calculated values

Fibery grouping works (or doesn’t work) regardless if the Field is calculated by a Formula or entered manually. So relations and selects are fine, numbers and text are not.

Cannot group by lookup fields via relations

Well, Fibery does support grouping by lookup Fields. Could you please provide the setup that didn’t work for you (here on via Intercom)? We’ll take a look.

It seemed easier to show what I was trying with screenshots. I think what I’m seeing is the same unclear limitation for lookups as I’m seeing for other fields.

I created a Date type. It would have to have all dates in it, but would have fields as part of the type for different levels of detail. See the Dates table screenshot.

I modified the OKR example to be associated with one Date. See the OKR type relations and lookups screenshot.

I then went back to the Board view and the dropdown allows me to group by Dates, but not the lookup text field values like “Q1-21”.

Also tried sharing the app as a template here: OKR Tracking

While the dates comments are more complicated, I wanted to reiterate my less-complicated issues here:

  • First, support grouping by all the things, then apply limitations on the moving of the items where it is complicated to do so.
  • As-is, it isn’t clear why some things are showing up and others aren’t. There isn’t any feedback. It would be better in its current state to show all the fields, grey out the ones that can’t be selected, then provide feedback on why it can’t be selected.

So, I looked at that issue. I can see how they are somewhat related, the main issue I’m raising here is about generalizing the Board visualization. Instead of a Kanban-like board for moving things around, think about it as a grid visualization that can operate as a Kanban board in some cases.

The linked issue is more about setting more general values for the date field I believe, while mine is more about taking the existing date or date range field, and supporting the visualization of the date at different granularities in the Board view. I can see how the linked issue could make it easier to set the values in some contexts for high level planning, but I’d be fine with the existing date/date range field if they could just be visualized in the Board view. For the date range field you’d have to allow the user to select the start or end of the date range to use for the column/row, then the level of detail to use for both versions of the date field (single date or date range).

It really comes down to needing to produce a high level roadmap that can fit into a slide deck type format and still be understood. There is no view Fibery has at the moment that can do that without a bunch of manual effort.

Here’s a template I just made that achieves what you’re describing (I think).

The concept is pretty transferable, so it doesn’t have to be just used for grouping by date.

It works like this:
For the fields that are not currently choosable as a column in the board view, you need to create a helper type with entities for each of the possible choices you wish, and then use auto relations to connect them to the entities that you wish to be grouped (making use of formulas as needed).
That way, this ‘helper’ type shows up as a possible column choice in the board view.

Of course, it requires a bit of time to set up the helper entities, but in the case of grouping by quarter, you’d only need to set up 4 new entities once a year :slight_smile:
And with copy-paste etc., it’s pretty quick to do anyway.

1 Like

I then went back to the Board view and the dropdown allows me to group by Dates, but not the lookup text field values like “Q1-21”.

Indeed, the issue here is with the text part, not the lookup part — try creating a Board for Dates grouped by Quarter-Year, it won’t be possible either.

Supporting date and text Fields as rows/columns is trickier than it sounds, trust us (;
We’ll brainstorm possible solutions in the near future though — let’s hope we’ll come up with a good idea :crossed_fingers:

1 Like

Just want to add here that I have made use of the TIMELINE function in reports, which, combined with the MONTH function allows some really useful views of the data to be created.
I totally understand that supporting text as row/column grouping can be hard, but I would have thought that numbers and dates wouldn’t be too tricky - by offering binning chosen by the user, I would have thought it to be possible (although without the dragging feature that is possible with most other types).

I think your approach is better than mine for now. I had tried to model the dates themselves as a type, but that would be a lot more work and would break other stuff (date selection). Instead, the auto-mapping of just the summarized date types is less work. It also appears the same approach could be used for a date configured to be a date range as well, but would need double the number of automapped relationships.

Issues with Date Work-Around

  • Even as an accepted work-around, Fibery really lacks basic date functions. (See @Chr1sG’s formulas to make this work).
  • Dragging between columns won’t work, since it relies on auto-mapped relationships from the Date field. Roadmunk would update the date being used for presentation to the last date of the period you dragged the task to. This helps with high level feature planning/roadmapping.
  • You can’t easily adjust the granularity of the view (switch from Quarter to Month, or vice-versa), but a workaround is just to create a view for each

Should Dates be a Type?
One more architectural consideration in terms of how Dates are treated would be this… As a user of Roam Research, I’ve noticed that most other tools treat a Date type as this other concept that isn’t quite a thing. For example, with Notion or Coda I can assign a date to something, but to have a place to go see a specific Date and all things associated with that date, I’d have to apply a number of potential manual work arounds. With Roam, since Dates are a first class thing, you can go to any Date and see things related to it. So…, should Date in Fibery not be a built-in type in the same way a Person is a special built-in type?

Currently in Fibery, you can go to a Person that has things assigned to and you’ll see all of the things related to that person. However, you cannot go to a Date and see all the things that are associated with that Date. By treating Dates as a type, then all of the ways of summarizing dates would be calculated fields on the Date type.

I believe with this type-based approach, you could devise a generalized way of grouping in views for any related type, where you could allow the user to still drag between the groups.

If you look at the example:

  • You know what are the distinct values for the field that is grouped on (to know what the possible columns are) by following “Detailed Values” → “Grouped Value”
  • If you were to drag something from one column to another, you can look at the table and see there are potentially multiple actual values to assign to it. You just would have to specify ahead of time how to select the value to assign from the possible values associated with the group
  • So, if I drag “Generic Item 4” to the column grouped on “10”, it will warn me that can’t be done currently. However, you could define how to select the correct one. It could be the maximum value, which is what we’d probably expect for working with dates, but in this case you might want the minimum value. So, look at the “Detailed Values” table and you’ll see we chose to drag the item in “10”, which is associated with 10-14. So you’d update “Generic Item 4” to have a “Detailed Values” relationship to either 10 or 14, dependent on what was configured.

This may be a small point, but to the best of my knowledge dates are not a “first class thing” in Roam. Dates are just pages, with no unique functionality. It is the baseline functionality of Roam, which treats everything like a page/block, and has universal backlinks, that makes anything useful possible with dates (e.g. queries, etc.).

So if you tag a date, it is no different than tagging a page named “3/31/21” or whatever. The only difference is there is built-in functionality to translate a date picked on a mini-calendar into a text string that names a file for a date. After that the date has no special significance or functionality, again to the best of my knowledge. But I’m not much of a Roam-an. :wink:

If I’m right though you could do the exact same thing with any type in Fibery, if you wanted. Any type could become a “date”. Not that this is that useful, I know it doesn’t solve your problem, I’m just pointing out that sometimes you can have the illusion of a feature because you get the utility you need/want from it, even if it doesn’t actually do all that the feature you imagine would imply… If that makes any sense. :grinning_face_with_smiling_eyes:

That’s interesting, because I think in a lot of cases, if an item was dragged, from one quarter to another quarter say, then I don’t know if that’s the behaviour I would expect.
If I have a project starting on the 15th Feb, and it shows therefore in Q1, does it really make sense to move it to 30th June if I drag it to Q2?

I just mean that whatever behaviour the platform implements, it probably won’t be what the majority of customers want/expect.

Isn’t this what the Timeline view offers (as opposed to using the Board view)? Although I think that it too could be improved, with panning and continuous versus discrete zoom levels, but that’s another story :slight_smile:

What would you want to see?
All things that start on that date? All things that end on that date? or all things for which the date is between the start and end (í.e. is in progress)?
Again, I think I’d use Timeline (or Calendar) view to see this kind of perspective.

Overall, I do agree that being able to present date information (or any numerical field) via column binning on a board view is useful, absolutely.
But making it more than just ‘read-only’ is hard to implement though I think.
Your proposal whereby, when dragging, the user gets to choose what the ‘actual value’ is, introduces potentially as many problems as it solves, I worry.
For example, is this choice pre-determined by the admin, or by each user according to their personal preferences? Or is it something that is offered for selection each time an entity is dragged?
I fear that whichever implementation would suit you and your business might add friction to others and their way of working.

As a sort-of related example, I recently had entities which were cost activities (having start and end dates and a monthly cost field). I wanted to plot the data with the months as columns and the entities (showing their cost) under the relevant months. But if an activity starts halfway through a month, should it show under that month or not? If an activity starts on the very last day of the month, it feels nonsensical to show it.
Also, should the displayed number field (for monthly cost for that entity) get magically re-calculated on a pro-rata basis for the part months?
I ended up using the TIMELINE function in the Fibery reports to present the data, and I found it useful, but it of course is read-only…

Maybe it would be nice if the primitive date type had additional properties (like Date.Start.Quarter and Date.End.Month, etc) which could not only be referenced easily in formulas but also be available to be used in the same places where other fields types can be used (like rows/columns in boards, and filter options).

For what it’s worth, after creating and sharing my App (rather late at night) I realised that the formula fields I used could have been way simpler, but I totally understand why nobody likes having to create formulas to achieve something that they’d like to work out-of-the-box :slight_smile:


It sounds like you might be looking at this from a granular project management perspective, rather than a product roadmapping and portfolio management perspective.

Consumers of a product roadmap (most) don’t care about exact dates. They just want an up-to-date view of what we are planning to complete by a given period of time.

At a higher level of granularity you have to do something. My experience with roadmapping tools is many provide this kind of functionality, and I’d suggest to leave it configurable. Typically you are communicating that something will be done by a given date, so you configure the view to present based on the end date. If you drag something that was going to end in March 2021 to May 2021, you’d have to either leave it as-is relative to the period (if it was in the middle of the period, set it to the middle of the new period) or set it to the end of the period. ProductBoard does the former, Roadmunk does the latter.

I suggest trying out Roadmunk and ProductBoard. It is very intuitive in practice and a common Roadmapping feature. If Fibery is targeting Product teams, then I think it is important to understand key features that are expected.

Yes, it does provide the functionality, but in a format that is better for a product/project manager. I’m looking for something to take items that have specific date information that might start and end at different times but summarize it up for executive leader type people. They don’t care that one initiative completed 10 days before another and I have found that presenting that information just hurts with the consumability of the roadmap by people that aren’t living in the work.

I just tweaked one of the product plan templates to make the dates not line up perfectly. This is the same data, but one is going to be much easier to consume by other stakeholders or potentially even users.

I’m not sure if you’ve used Roam, but the answer is yes to your questions. The main point is to challenge what is a primitive type or not. Many tools treat a person kind of like a primitive type, which makes things awkward when you just want to @reference someone, whether or not they are a user of the tool. I do think a reasonable alternative for fibery is to use the calendar view to display many different types at once, which I think is a pretty nice feature. I think something like that might not be possible with Coda IIRC.

That sounds like a data modeling/analytics problem, not something that I’m looking to be fixed by this proposal. There are tools that handle moving up or down in granularity of dates well (tableau), but you first need to have the granularity to start with. You would have eliminated the ability to do that when associated a cost to a long date range.

Well, I fear that your fear of potential friction is going to make larger product teams unable to justify the cost of Fibery with the pricing :wink: .It is great for a small team, but will have to replace tools to justify it for a big team.

The bottom line:

  1. I consider this kind of date grouping behavior to be critical base functionality that exists in multiple competitors
  2. Those competitors were able to implement the feature, it works well, and people responsible for roadmapping will no doubt miss it
  3. The work-arounds could potentially be viable work-arounds if the friction was reduced (date formulas) and discoverability improved (no indicator why some fields aren’t allowed for display and how to fix it)
  4. Fibery will have to assess how critical missing roadmapping features are for meeting their goals
  5. If decided to address, then Fibery will need to figure out how to integrate it into their own product in a way that doesn’t cause you friction, instead of just duplicating something that a competitor implemented. (what i was doing was exploring one concept for how they could achieve that)