Function to get the URI of an entity

When triggering Slack notifications that a new entity was created, edited, etc. (e.g. a support email, etc.) I want to add the link to the entity in the end.

I can manually concatenate the link to the entity, but as our workspace is supposed to be malleable and spaces can be renamed, this will break said formulae whenever it happens.

Is there a function or entity property available in formulae to get an URI to the given entity ideally using the UUID?


Hello, @njyo

Please find below the example of template with link to entity.

<% const utils = context.getService(`utils`); %>

Url is <%= utils.getEntityUrl(Entity.Type, Entity["Public-id"]) %>

Please note {!Public-id!} is used for hidden initialisation of field Public-id.



Thanks a lot, @Oleg!

Here my script for posterity (for whoever may come by this later):

<% const utils = context.getService(`utils`); %>

📥 Email from {{From}} with subject: {{Name}}
 <%= utils.getEntityUrl(Entity.Type, Entity["Public-id"]) %>
1 Like

This deserves to be a built-in function, that would not require research plus three lines of code every time it is needed – something like {{%EntityUrl}}


Absolutely agree @Matt_Blais!

And, ideally, I’d want the format be:

So that even if a database gets moved to a different space, it’ll still work.


1 Like

Unfortunately, I believe UUID is actually not guaranteed to be unique within a workspace, only within a given database.

I guess it could be

1 Like

Oooof. I guess better than nothing, @Chr1sG. :slightly_smiling_face:

Though, I thought the whole point of UUIDs would be that they should be universally unique? Guess it’s not guaranteed… :thinking:

And with the whole idea of Fibery to be malleable, I hope this (presumable early-day design decision) one day can be rectified. :heart_eyes_cat:

I think there’s little to no chance that the underlying tech design that UUID is only unique within a db is going to change.
At the moment, I’m not aware of a strong case for changing (and enabling permalinks of the form <instance><uuid> instead of <instance><dbid>/<uuid> doesn’t seem like a big enough need imho).

As long as changes to the DB (renaming, moving, etc.) do not change the database ID, I guess it’s ok.

1 Like