Allow filtering which objects can be selected in an Object (Relation) property

[AnyRakoon]

WHAT DO YOU RECOMMEND?

Allow filtering selectable objects in Object (Relation) properties by property values.

Currently, Object (Relation) properties can only restrict selection by Type.
The recommendation is to additionally allow property-based constraints (e.g. Select, Tag).

---

HOW COULD IT BE DONE?

Extend Object (Relation) properties with property-based selection filters.

Possible implementation:

• In Object property settings, add a “Filter by properties” option

• Reuse the existing query filter logic (Property → Value)

Example filters:

• Category = Location

• Status ≠ Archived

• Kind IN (Country, City)

No formulas, rollups, or calculations required.

---

REAL WORLD USE CASES

1. Location Modeling with a Single Type

A user models locations (countries, cities, places) as objects of the same Type.

Example:

• Property: Located in (Relation → Location)

• Desired behavior:

  • Only show objects where Kind = Country or City

• Current limitation:

  • All objects of that Type appear, regardless of role

Property-based filtering would allow clean hierarchies without creating multiple Types.

---

2. Authorities, Organizations, or Providers

A single Type contains different kinds of organizations.

Example:

• Property: Authority

• Desired behavior:

  • Only show objects where Role = Authority

• Without property filtering, unrelated organizations appear in the picker.

---

3. Low-Friction, Multipurpose Schemas

Many users prefer few, broad Types to reduce cognitive load.

Property-based relation filters would:

• Enable multipurpose Types

• Prevent accidental mis-linking

• Reduce the need for many narrowly defined Types

---

RECOMMENDED ALTERNATIVES

Current workarounds:

• Creating multiple specialized Types

• Duplicating relation properties

• Using naming conventions or emojis

• Relying on user discipline

These approaches increase complexity and reduce schema flexibility.

---

ADDITIONAL CONTEXT

This feature would:

• Reduce friction when selecting relations

• Enable cleaner, scalable schemas

• Encourage reuse of broad Types instead of Type inflation

• Build on existing query/filter logic already present in Anytype

Even basic property-based filtering (Select / Tag) would significantly improve relation usability.

[C.c]

Seems to be part of the following feature request

Advanced Filters / Queries

Is your feature request related to a problem? Please describe. Filters in its current state seems to be a boolean AND of all the filters added. What I would love is to be able to establish relations between the filters myself, so that I can then filter if say Linked Projects contains Something or Linked project is empty. Right now, it is not possible to this or that kind of filter Describe the solution you’d like A formula like bar above the list of filters where the user can specify how they…

[AnyRakoon]

No, its a different request. Mine is a filter specific for Object Properties in Types.

[C.c]

If you dig down the posts in that feature requests, starting from Post 28, you would see advanced filters on querying with relation, but if you have really checked, then with all respect, we can keep this as a separate request.

Have fun with relations.

Other related discussions/requests:

Many-to-many relations

Hi ! I’m designing a system to track Entities (e.g., projects, locations) and Elements (e.g., equipment, tools), where the same Element can be linked to multiple Entities—but each link needs to store custom attributes (e.g., a unique image, notes, or status for each Entity-Element pair). Current Approach I’m using a “join object” (inspired by relational databases) to represent the relationship: Entity type: Represents the main object (e.g., “Project A”). Element type: Represents shared i…

Multi-dimensional Relations

Ever since the introduction of “relations as objects” and also “inline sets” into Anytype, I was toying with the idea of incorporating more and more aspects of my life into Anytype but in doing so as I mentioned in my other posts, I felt some limitations and lack of features can get in the way of that. Browsing through the community, I came across some interesting and brilliant ideas (multi-type and inheritance) of what could be the next step for the “object, relations, sets” philosophy of Anyty…

Multi-Type Vs. Inheritance

Overview The two features that create the most excitement to me are Multi-types and Inheritance, two features hightly interrelated. In a comment by @ignatovv, he said that the Team wants to introduce Multi-Types and in the last Townhall a dev talked about working in some small feature requests as extendable objects after the open beta (iirc). In case the team had to prioritize one of these, which one would you choose? Inheritance: Inheritance, a widely recognized principle in software develop…

[Zaglim]

If I understand @AnyRakoon correctly, this is not making better queries, but about preventing unwanted representations.

To continue their example, consider the type Location, which has the properties Located in and Kind. The value of Kind can either be country, province, or city. Located in relates this Location with some other location. Examples:

• “Vancouver” (a city) is Located in “British Columbia”
• “British Columbia” (a province) is Located in “Canada”

This feature request is about protecting the user from accidentally making ludicrous relations, like “France” is Located in “Paris”. Or “Russia” is Located in “Dave’s house”. More generally, “A thing is located inside something that is smaller than it”. Conveniently, if the program is smart enough to block such relations, it is also smart enough not to suggest any city objects in the search result list when modifying the Located in for a province. Because a province cannot be in a city.

Adding this feature would be cool, but adds a lot of challenges. Each time I modify an object, AnyType would have to search every backlink for a restriction, and do validation check for each. And what happens if my change has invalidated a relation? Is it allowed with a warning? completely blocked? I imagine there could be gridlock situations, where I want to change between 2 valid graph states, but to do it I have to go through an invalid state. That should be allowed to happen if it is done atomically. But currently that’s not possible…

It’s a neat idea, but it adds a lot of complexity, and if it is ever resolved to add this kind of feature, I think inheritance from abstract types or plain subtyping is a better way to go about it (and I doubt that is worthwhile either… there is probably a lot of discussions on inheritance in this forum already, I might have a look around some time)