Fibery Navigation strategy


Part of the success of TP was the ability to create hierarchical views that were not based on entities but on how a team wants to view their projects/work. For example I might have project A and it has a navigation structure
Project A
|----- Dashboard - Overview of the project with recent comments, new items added, stale items,burndown etc
|----- Feature Team 1
|----- Epic Time Line
|----- Backlog View
|----- Current Sprint

As you can see, the navigation structure has nothing to do with the types of entity. We structure the views to make it easy to find things.
Currently in Fibery the views are based on types of app, and this doesn’t allow me to create the kind of tree view shown above.
When will fibery support this type of flexibility?


@Paul_Cleghorn In fact I think in Fibery you can have the same structure even more naturally. There is NO restriction on entities inside any app. Check the screenshot below. We linked several views to Fibery Team from different apps (vacations, kanban, retrospectives, etc). Same way you can create as many different views as you want for Project A with any entities.


In that case, I’m lost. I cannot create any top level parent…I’m just stuck with node based on the app I have installed. How do I replicate the following at the top level?


@Paul_Cleghorn It is better to map your organization/unit structure first. Do you have Projects and Teams inside? What “SAP Upgrade” means? Then all views can be created for all entities in your organization.

In your setup Grooming is a group of views and that is something we will add slightly later.


‘SAP Upgrade’ is a Project. Team A is a specific team who will do one aspect of the project. There are other teams as yet undefined. I show it for information really. The SAP project may be a child of a portfolio epic so is not an organization node.


There are two solutions right now (that are not exactly what you want maybe). And the third one is future potential solution.

Solution #1.
Projects and Teams in separate Apps. It will give more flexibility overall.

Solution #2.
Team Type inside Projects App. Thus you stick Team to a Project very tightly, but all flexibility is lost. For example, the same team will unable to work on other projects.

Solution #3 (potential in future).
We might add Folders as in Targetprocess and in this case it will be possible to setup what you want exactly with filters. However, so far we want to postpone this solution till more feedback


Thanks for the feedback. I for one would like Solution #3 (potential in future). as it’s one of the best things about TP, the ability to create truly bespoke views irrelevant of the entities.