How to create a dynamic link that shows a view filtered by current entity?

Use case:

I want to create a step by step guide in the description field of a meeting entity.
The guide is used by the facilitator to fill in meeting information.
I do not want to embed fields, but want these to be accessible through a link in the description text.
The link needs to open in a new panel at the right, and need to be filtered by the current meeting where the link is clicked.

In the screenshot above, I show an example link that works (meeting 40 is part of the link, which corresponds with the meeting ID). However, this needs to be a token or URL parameter such that the current meeting ID is fetched and made part of the link.

Can something link this be accomplished currently in Fibery?

I don’t think Rich Text fields currently support any kind of “macro” capability that would allow you to reference the “current entity”.

But this would be awesome :star_struck:, as would be the ability to reference any field within the current entity.

I think the closest you could get right now would be an Automation that uses the existing “Append/Prepend/Overwrite” actions, which allow referencing the current entity (and even scripting):

1 Like

If you create an embedded view in a rich text field (type << and the name of the view, then pick the view type and choose to create) it will be automatically context-filtered to show only related entities.
However, this won’t be a link to a view, it will actually show the view.

But once that view is created, you can actually get its url (open in full screen and copy from its ID) and mention it anywhere you like, including in the rich text field it was created in(!)

And it doesn’t matter if you delete the original view.

1 Like

@Chr1sG, do you know if it’s possible to reliably synthesize that embedded-view URL from just the Type and Public Id of the entity?

It seems like the Type Names in View URLs are not necessarily the same as what one can gets from scripts (?)

It isn’t possible to ‘synthesize’ a view simply by formulating a URL.
A view only exists if it is actually created, so even if you could reliably predict what a view’s URL might be, until it is made, the URL won’t point to anything.

1 Like

What about synthesizing the URL for an Entity view?
Can all the components of the Entity View URL be reliably determined from the schema?

If an entity with a particular public ID in a specific database exists, then yeah, you can reliably get to its entity view by using

http://<workspacename><spacename>/<databasename>/<public ID>

But if there is no entity with that public ID, you don’t create one by typing that URL :slight_smile:

Bear in mind that there will be conversion of certain characters in the case where they can’t be part of a URL. For example, if the space is Project management then the spacename will become Project_management

FYI the script utility function getEntityUrl basically does the job for you.

1 Like

Here is another example of a common use case (currently I try to create this for my teams): A team or project dasboard not with embedded views, but with dynamic links. (This example I created using ‘Mention’-links which are static).

Alternative: not ‘current entity’ but Formula Field: ‘Lookup View (link to a view of a related entity)’
Most likely, as in this specific example below, this display is not the team entity itself, but for example a ‘menu’ database entity that relates to all other databases. Then we can consider the menu blocks in the example to be embedded views of fields with dynamic links to views using the related entity as variable in the link, a kind of Lookup field to a View of a related entity.

Have you tried experimenting with the method I described above?
Keep in mind that context filtering can be changed to utilise any direct or indirect relation between the db of the context entity and the db of the items being shown in the view.
So if you want, you can create a global ‘Menu’ database, and use this to create indirect relations between Team DB and Content DB, Project DB, Meeting DB, Agenda DB, Task DB, …
and then use these relations in the context filter for each of the views.


I tried, but end up always needing the URL to provide a variable for the currently viewed entity (Meeting) since the embedded view URL has that Meeting ID as static path segment.

Please let me know if I missed a key solution you referred to.

Entity display formats
What would work is implement entity display formats, requested as feature before where a link to one of the display formats of the currently viewed entity could be possible in the rich text fields, when the new inline entity references (Reference Reloaded) could support an option to select which display format of the target entity to link to.
This feature, the multiple layouts per database or per entity has been requested before in different approaches and descriptions, but basically they all refer to the ability to show the same entity in multiple ways with different URLs.

As a workaround for this particular use case, what I could imagine is an automation that prepopulates the Description field of an entity (such as Meeting) with text that includes a script which constructs and includes dynamic links to particular views.

This would mean that such links can’t randomly be inserted in a rich text field, but requires

  • for a trigger at creation time to be set up as a standard template when creating a meeting (or project, etc).
  • Alternatively, I could create automation buttons for the user to insert a desired template.

Thinking ahead, it may also be possible to create an automation that takes the description field in the currently viewed entity (Meeting) and converts every instance of a specific string into a corresponding dynamic link to a view, and overwrites the description field with the converted version.
This would be a bit similar to a Token system (per database, as long as Fibery does not allow automations to apply to multiple databases) where the user is aware of a list of tokens that will be automatically converted in the text upon save or upon automation button click.

By the way the database token system could be made more accessible for non-admins by including a simple automation in every database that checks a Script database and uses that text to construct its own script. It can also use a Token database that users can populate themselves to create a workspace wide token system that finds and replaces text tokens with dynamic data.

I’m not sure I quite get the use case here.

In general, relation views allow you to define context-filtered views of related entities. These relation views will be the same for all entities of a given type. If you consistently need the same view(s) for every entity, then relation views are the way to go.
Rich text fields are intended to contain information/views which varies from entity to entity. They’re not designed to lend themselves to replicating content for all entities in a database.

Trying to combine these two functions is rather tricky. How would you expect a rich text field to simultaneously contain fixed views (which should be the same for every entity) and yet allow for entities to have differing contents/layout (per entity information)? There is a tension here that is not easily resolved.

FWIW it seems like the image you shared could be best achieved by having a handful of alternative views for each relation field

Because of this

the automation would need to generate every possible view you need

I think my topic description was not clear enough about this:

I just want to have a link in a rich text field that points to a view filtered by the currently displayed entity, but that link needs to be dynamic in the meaning that it either has a token or takes a value from an URL parameter, so that the link can be used in any rich text field of the same entity type and will still result in a pre-existing view that’s filtered by the currently viewed entity.

Another way to put it is:

I don’t like to display relationships fields in the Meeting entity, but I want users to still be able to access similar views of related entities through a dynamic link in the rich text field of a Meeting, which they can place anywere they like.

Why? Because the static layout of fields in entities is often too restricting and/or space consuming. E.g. if access to related entity listings need to be grouped in a customized, more meaningful way.

As a more advanced example of the abovementioned case of the Team X Menu screenshot, the goal is that these blocks with links are prepopulated automatically in each newly created Team entity.

Feature request: Dynamic Views
I understand that views are not able to be synthesized by formulating a URL, so in this case this would be a feature request, that Fibery also provides views based on dynamic contextual values.

Alias entities as Entity Display Formats
For now, the idea of Menu entities comes closest, meaning instead of direct links to views, I would create links to a automatically pre-created Menu entity (through an automation), which can function as an Alias of the origin entity since it has exactly the same database relations and displays those fields. Another automation can append to a rich text/description field links that point to this newly created Menu item. I need to experiment still how to use multiple alias menu items to display different configurations of fields, in order to mimick the desired ‘Entity Display Formats’ functionality.

So you expect to have a url which, when copy-pasted from one entity to another, will automatically update itself to point to a different view (so it is not context filtered based on the first entity but on the second)?
I am not aware of any tool that supports such a concept. Have you encountered it before somewhere else?

Reading this:

and this:

makes me think that the fundamental issue is simply that you’re not happy with the layout restrictions of entity view, and maybe you actually do just need context-filtered relation views, but ones which initially present as ‘collapsed’ (=clickable links) and can then be ‘expanded’ as needed.

As far as I see it, this just seems unrelated to rich text fields (whose purpose, as I say, is as containers for per-entity information) but you are maybe trying to solve it with rich text because it does currently have some flexible layout options.

I’ll reply later to your comments in your last message.
Just a question in between: Would it be possible to have an automation that creates a relation view at the moment an entity is created, and capture the URL of that?

If you’re willing to utilise scripting and the Views API, then yes, you can create views when an automation runs.

See . | Fibery & Fibery API

1 Like

Another approach for a dynamic link to view that can be filtered by the current entity:

If the current entity is automatically ‘flagged’ as the current entity using a flag field, then I can create a link to any view that by default filtered to show only flagged enitty relations. To prevent issues with multiple users doing this at the same time, the flag field can contain also a value for the current user.

The automation would overwrite the flag field value of the current entity and removes any existing flag of the current user.


Option 1: A rule that assigns a flag value to the currently viewed entity, although that creates a lot of processing overload.
Option 2: A rule that is triggered when that pre-existing view is accessed through URL of the view that contains a parameter like ?current=10 (which still shows the same view), which rule overwrites the entity ID 10 its flag value. It will probably take a few seconds for the view to automatically be updated.
Option 3: A button that overwrites the current entity flag, removes previous flag values, and overwrites a dedicated rich text field with a link to the flag view, as a temporary direct link. This field will be erased from the previous entity when the button is clicked again.

I did not test this yet, but if it works then we have a way to mimick dynamic views.

What you’re describing is what is already done with smart folders. Have a look at how the context views for smart folders work (and inspect the URL for per-db smart folder views).
You could find a given (smart folder) view’s id and then use an automation, to populate the rich text field with a link to this view, context filtered based on the current entity’s public ID.

Oh, and in case you didn’t know, you can skip the entity name and view name when constructing a URL, the public ID is sufficient in each case

Copy pasting the smart folder view’s URL gives a link to the result below.
The Smart folder view link buttons in the left navigation column work obviously, but pasting the link apparently leaves out information that the smart forlder view link appends when opening in a new panel. Or did I misunderstand it?

1 Like