In some apps, I have type A that is a parent to type B, which is in turn a parent to type A.
It would be nice if it was possible to represent this in some way (like in whiteboards, smart folders, and/or the newly released hierarchical lists 
)
1 Like
Actually, I also have some apps where type A is a parent to type A, e.g. org chart. It sort of looks OK in whiteboard view, but itâd be good to be able to visualise this in hierarchical lists as well 
@Chr1sG If I understood you second post correctly, I think that is already possible with the smart folders and the new hierarchical lists.
However, there are still a few issues and limitations to this. Iâve documented some of these in this clip. I was hoping the hierarchical lists would address this, but Iâm thinking the problem is not as easy to solve as appears.
[UPDATE: should have watched your video before posting. I hadnât realised that I needed to select the recursion symbol when configuring the list. It works fine, thanks]
Yeah, I had been using it in Smart Folders, but it wasnât working in hierarchical lists. Think it might just be a bug for me:
It looks like a bug, we should fix it
1 Like
No, just PEBKAC (problem exists between keyboard and chair).
I hadnât clocked the need to enable recursive nesting with the little icon 
Thanks @mdubakov, I know you have a lot of priorities
I was wondering if there will be a possibility to also look into representing the more complex entity relationships like this:
I am able to setup the relations and add the entries, but when it comes to setting up the smart folders, it seems having the âcontactâ entities at both levels (i.e. under âOrganizationâ and âOrganizational Unitâ) is not supported:
Is this at all possible?
1 Like
Hi!
Will send the text here as well, maybe that would be helpful for other users to check.
The paradox if anything is that an entity can have two parents in such situations.
And itâs like with many to many - a lot of questions rendering. By the way, we can formulate the limitations of our hierarchies as follows: there is only one parent for an entity. This also explains why only the top type can be self-nested.
Your certain case is also limited by our lack of polymorphic relations, as far as I can see your child Entity can have only one parent at the same time, but there is a possibility for another one as well, so we treat it like it has (can) two parents at the same time. Curious case to think about.
We understand that such cases were pretty common, but we just donât have a good solution in mind. So now we are collecting all of them and later will have a fresh look at it
4 Likes
Iâm very glad to hear about Polymorphic relations again, I really think they will help a lot of problems I am having in Fibery as well with trying to create folder-like hierarchy, but instead of being able to just add an extra individual item on a lower level, I need an *entire level because I have to create a whole new child Type to do that.
3 Likes
Just wanted to add another example of this type of nested relation in the area of project management (as defined by PMBOK):
- A project is a temporary endeavor undertaken by a company or organization (such as the creation of a new product, service, or result)
- A program is a group of projects that are similar or related to one another, and which are often managed and coordinated as a group instead of independently
- A portfolio is a group of different programs and/or projects within the same organization, which may be related or unrelated to one another
Portfolios will be the top layer, but then both programs and individual/stand-alone projects would be nested inside the portfolio. The programs in turn would have some nested projects. Iâve modeled it in Fibery like this:
It would be great to be able to view this type of relation in the UI.
1 Like
Am I correctly interpreting that only top-level types within a hierarchical list are allowed to be recursive? Would it be possible to allow nested types to have recursive relations as well?
Iâve got two types, ideas and tasks (itâs sort of a simplified GIST approach). Ideas can have sub-ideas and sub-tasks. Tasks can also have their own sub-tasks. Currently Iâve got a list that shows nested ideas, but I can only make it show the first level of sub-tasks.
Unfortunately not (but youâre not the only one hoping that this will change 
)
If tasks could have either an idea as a parent or another task as a parent, then tasks canât be shown recursively in a hierarchical list at a sub-level.
Polina said it best:
1 Like
Ah, that makes sense. Thanks! Definitely hope it can change it the future
I can relate to that also from the PRINCE2 perspective.
There is the workaround as used in other SWs and Excel sheets in Excel managed organizations
Using the basic setup of:
Portfolio
â Programme
---- Project
You create an âemptyâ programme for the cases of projects being directly in the portfolio.
You just need to agree on the broadly accepted name of such âemptyâ programme.
@Polina_Zenevich and @Chr1sG I was wondering if there was any updates on this idea/request. It is one of the things that has been really bugging me. In fairness, I donât know if any other apps do this (or do this well).
However, it seems to that fiberyâs relations allow you to setup the nesting relationships within the data model but then that power is not available in the UI/Views (i.e. smart folders and hierarchical views) based on this fundamental design limitation:
While this makes sense, I wonder why this issue canât be resolved through some rules/process which establishes one parent. For example, I believe the simplest case would be to first start with the current database relation as the primary parent and if no relation is defined to the same database (i.e. relation is null), then we would go up one level and use that relation as the parent relation (if it exists). And so on up the levels until you get to the first level at which point if no relation exists, it gets captured under a âno parentâ bucket.
I think this would be a logical approach, although there may be edge cases that could benefit from later allowing this rule to be customizable in some way.
Example
So in this example:
where we have three databases where each database can have records of the same type nested under each other (i.e. Portfolios could have Sub-Portfolios and Program could have Sub-Programs and Projects could have Sub-Projects). In addition, you could also have projects be either part of the program or discrete projects under a portfolio:
Approach/Process
With the approach I suggested above, I believe you start by building each databasesâs nested structure first (which is what fibery does for the first level):
Then in step 2, you start from highest level and move up and try to map all the root/level 1 items in the lower level databases:
So in the above example, after creating the individual nested structure for Portfolio, Program and Project, you then go to the Project tree and for every Project that is at the root of tree (i.e. has no parent Project), you will see if a Program relation is specified. If yes, then we insert/nest the Project (and any associated sub-Projects) inside that Program. If not, you will see if a Portfolio is defined and nest the Project there. If all fails, then the Project would be added to the âNo Portfolioâ list (again with any nested sub-Projects). After Projects are done, then you move one level up to Programs and do the same process with all the root level Programs.
I believe with this approach you will be able to get something like this:
This doesnât assign a one true parent to any entity (I think that would diminish fiberyâs flexibility and I donât see why that would be necessary). However, it allows unlimited visual nesting by using a rule to determine each items parent based on the levels defined in the view.
I am sure I am missing important implementation details but would be curious to get fibery teamsâ thoughts on if something like this is doable. If it can be accomplished for Smart Folders and Hierarchical Views, I think it would also be a very useful addition to the Whiteboard to allow things like org charts.
2 Likes
Youâre suggestion is totally logical, but for your example, there is nothing to stop a Project being linked to a Program and a Portfolio at the same time.
So if Project D is linked to Portfolio Alpha (as well as being linked to Program 03 - Year 2) where would it show in the hierarchical list? The obvious answer is under both of them, but at the moment, the underlying tech doesnât allow an item to appear twice in the same hierarchical list view.
So any time that there is recursion at a level other than the top level, or where there are multiple âupward lookingâ relations, you are prevented from choosing to display those databases (in hierarchical list view or smart folders).
2 Likes
I could be wrong, but I think my approach would actually mean that Project D would actually only appear once under âProgram 03 - Year 2â and the process would ignore any relations to the Portfolio database. That is because in Step 2, I start from the highest level (level 3 Project) and try to first find their parent in Programs database. If I find a Program where the Project can be nested, then the process stops. In this way we preserve the one object/one parent paradigm by applying a rule/sequence on how the parent is found. If no parent is found all the way to the top-most level (e.g. Portfolio in this case) then the View will just add that entity to the âNo Portfolioâ list (which is what it does currently.
I do see your point that a user might specify conflicting relations (i.e. a Program that is in a different Portfolio). I think you can solve that by using automations and by adding conditionals to the entity view that would allow you to hide fields and/or filter relation fields based on another field (i.e. if you choose a Portfolio, the list of Programs is limited to Programs under that Portfolio).
While my suggestion above guarantees (I hope) an item only would appear once, I hope you are able to actually have the same item appear multiple times in the future as I think it might be useful in some cases (e.g. a person works in two departments/faculties/etc.). When this is a possibility, I think you should be able to control whether items can appear more than once or would be nested per the suggested method.
1 Like
https://help.fibery.io/en/articles/3310832-hierarchical-relations
I totally agree that this will be a useful addition.
I think your logic is fine for the example you showed, but potentially the biggest challenge is that Fibery users (by virtue of the toolâs inherent flexibility) can make some really interesting spaces with relationship networks that would present insoluble problems to any logic.
Take something like the Usability Testing template. How should your logic apply in this case?
or even worseâŚ
Whatever the dev team decide to do, it has to work without any assumptions about how a user might have arranged relations in their spaces.
1 Like
@Chr1sG I totally agree that whatever solution that is considered, it would have to be evaluated for unforeseen impacts. And I donât doubt the issues you are raising, however, I am not seeing how the two cases you provided would conflict with the suggested logic.
I donât use these two templates, but I just installed them to see how they are configured.
For one, as far as I can see, unlike the example I shared, neither app have any databases that have relations to themselves (i.e. have entities that could have sub-entities of the same type):
As you know, as it stands you cannot currently have any self-nesting beyond first level of hierarchical list. This is primarily what I am trying to address with this suggested logic. And if this type of nesting is not desirable in a particular case, I think there is already a switch to turn it off (currently implemented for first level only):
The second thing I wanted to achieve was being able to have:
- Projects that are part of a Program or
- Independent Projects under a Portfolio (I would have to make sure the Program field for the Project is null)
As far as I was able to see, this behaviour doesnât affect either of the apps you referenced (there were actually no hierarchical lists in those templates but I created some based on the smart folders):
Test Management
Usability Testing
Could you elaborate on how the approach Iâve been suggesting would break those existing apps or constrain hierarchical views in them?
1 Like
Sorry, I guess I wasnât clear 
When I presented the two examples, I was just trying to imagine that a user could have developed a space with similar complexity and included self-relation for one or more of the lower levels.
In your example, you wrote:
This is based on an implicit assumption that Program-as-parent relation takes priority over Portfolio-as-parent relation. When looking at the hierarchy diagram, that is a reasonable deduction.
However, taking the Usability Testing as an example (and assuming that Attempt is self-related) I am struggling to see how your logic could work reliably.
Based on your ârulesâ:
- Build each databaseâs nested structure
- Try to map root items
If a hierarchical list is to display all databases, I canât see how Fibery can determine whether an Attempt should be prioritised to be mapped under a Participant or a Task?
I guess the answer is that the user is required to choose a single âhierarchical pathâ (either Test â Participant â Attempt or Test â Task â Attempt) and that resolves it. Maybe thatâs OK.
But this is a constraint that is acceptable/valid for one-to-many relations.
I am aware though that any changes made to support self-relations need to be compatible with (future) support of many-to-many relations:
Implementing specific logic for self-relations might hinder that future development.
To be honest, I totally want to see self-relations at lower levels, so I hope the dev team can figure it out without painting themselves into a corner.
2 Likes