Featured relations should be managed through types, not templates


Currently featured relations are per template, not types. So when you turn an block into an object, or convert an object into a different types, featured relations don’t get applied. I would like to be able to manage featured relations per type too.


Ideally you would be able to set featured relations per type from the library. You should still be able to overwrite these preferences with a template or in individual objects.


Being able to set featured relations per type would make it a lot easier to manage. If you wanted to change all featured relations of a type, you could just do it from the library for instance instead of needing to do it for every object individually every time you wanted to change something.


You can use templates currently, but they don’t get auto-applied a lot of the times and you would still need to manually change featured relations for every object every time you wanted to change something.




I think “types” and “template” can have the featured relation in the same time.
And the priority of “templates” should be higher than that of “types”.


Currently types they can’t, but it would be nice if they could.

1 Like

I understand the thought but this (IMO) would obscure the distinction between Types and Templates. Types are essentially Pages with unique Names, Icons, Layout…and are otherwise non-descript.

I think Templates should have the most elasticity, so they can be applied to any of your Types.

What if you had different Relational needs, for one Type, depending on the circumstances? You do that, by having multiple Templates available when you create your Type. If the Type had pre-determined Relations every time, you’d lose that flexibility.

Besides, this is already doable. Once you have a custom Type, you can create another exactly like it in the Set view.

That it easily solvable by making templates overwrite everything including featured relations. So you could for instance make due dates and priorities featured by default, but then create templates which would overwrite this to do whatever you want.

Hmm, I’m not really sure I understanding what you’re saying here.

Anyways, I too feel like it should probably be up to templates to manage this. A nice compromise would be to be able to set a default template which would be applied every time you create an object unless you choose another template. This only works now in some places and also doesn’t work if you have multiple templates.

The problem I would still be left is the problem of essentially needing to change individually all of my objects that used the same template previously if I decided I wanted to change one small thing like adding or removing a featured relation, but maybe something like synced templates could be a better way to solve this.


I’m really with @Filip on this one.

The main problem I see is there are too many places that I could add a new relation to an object, and they just mixed together into the final object I created.

So when I look at a relation in the relation panel of an object later on, it’s hard to tell from where a relation is added, some relation added from Set view without value are even not displayed here.

This makes it difficult to find out where should I go if I want to modify a relation, I have to remember (or try hard to find) if a particular relation was added to this object only, or was added from Set, or was from its original type, or was from template T, so I can go and change it there.

It’s OK if these relations will never change once they are set but it’s quite unlikely the case in reality.

(Just my thoughts from a short-term user so far, others or the dev team may have a more clear vision of this :stuck_out_tongue: )


One way to fix some of your concerns is to, for instance, leave relations in the type group in the relation panel if that’s’ where the relations are coming from. Same for sets.
Currently they are moved up after you add them to the object.

I like it the current way… I could decide if I want relation to stick with type or template.

Regardless what one prefers, sub type feature will eliminate this issue and continue providing elasticity, whichever hierarchy user develop for their own organisation.

1 Like