Our Planning solution & feature request (for trigger "when linked to entity" -> multiple options)

Hi there,

This morning we had a partner meeting and Chris asked me to share our solution in here. I hope it’s an inspiration.

2 questions to follow up on:

  • @Chr1sG If you see something that could be set up more easily I’d love to hear about it.
  • In this video I’ll show you one of many possible use cases why it can be a great advantage to trigger an automation based on one of the possible linked entities.

In this video you can see what I’m talking about further on.

A brief explanation to start with. We have set up a scheduling system where we work with 2 different ways of scheduling → Planning & deadline.

Planning: A task should be done within a certain period of time. Sometime in this week, next week, this month or next month.
Deadline: A task must be done at a fixed deadline.

In the database Planning period we have the 4 entities, as described above at planning.

  • Those different planning options have (amongst others) a startdate, enddate, duration, month, quarter and year.
  • Every single week / month the startdate and enddate is updated. This will update the duration (via formula).
  • And when duration is updated, month, quarter and year is also updated.

When some sort of planning information is manually being updated, we automatically set all the other information logically known.

For example. When the quarter is Q3 - 2023, we know the year should be 2023. But we don’t know which specific month or deadline it should be. But when we update the deadline, we know the month, quarter, year etc.

The only issue is that we have more databases than just tasks that needs to behave exactly the same as tasks (talking about planning). We also have development tasks, content, personal development, etc.
In order to behave the same they should all have the same automations as we have inside the Task database.

But what would happen if it would be possible to have the automation trigger When entity linked to beingd triggered not by one fixed option, but by on of the mentioned options? Like it is possible when an entity is updated.

When I do a quick calculation for this specific use case it would save us probably 16 automations. :nerd_face:
4 automations in 5 database can be to converted to 1 automation in 4 database.

Maybe you know an even better solution for what we have build here. But I’m convinced it’s extremely usefull to have the possibility to have more options when linked to an entity.

Let me know what you think of it.


1 Like

There are a few comments I would make to the general discussion:

The updating functionality that @Marloes is looking for (as described in the video) currently requires automations that ‘bounce off each other’.
In other words, if a user picks a specific date, then the relevant week/month/quarter can be determined, so far, so good. However, if a user just picks a month in general, then the quarter can be determined, but not the specific date. This kinda means that updating a date, will cause the month and quarter to be updated, and because the month is updated, the quarter is updated again (admittedly to the same value). There can be some significant challenges where there is interplay between automations in this way.

The ideal solution is for there to be granularity options when setting the date field, as well as semantic overloading.
In other words, the user can choose a date field value to be as precise/imprecise as they wish. They can set a date field to be ‘April 2023’ or ‘Q3 2023’ or ‘This week’ or ‘Next Tuesday’.
Then, for any given view, it would ideally also be possible to choose to display with a specific granularity, e.g. show all tasks by quarters, or all tasks this week, etc.
Unfortunately, this gets quite technically complicated, since Fibery is rather too strict in typing to accommodate this fuzziness.

Until we have a perfect solution, I am actually working on a little custom integration that would allow you to automatically have a database of periods (days, weeks, months, quarters, years etc.) which you could link to (instead of a date field) where the semantic overloading was automatic, i.e. if you set the value to 19/04/23, it would be labelled as ‘Today’ until midnight tonight, at which point it would become labelled as ‘Yesterday’.
Also, I am considering adding numerical offsets, so that you can create views which are limited to ‘This week +/- 1 week’ for example.

Finally, the desire to trigger an automation on multiple ‘Entity linked to…’ options is a valid one, but one thing that complicates this is that the current automation rules allow you to reference the entity that was linked (as well as the entity being linked to) in the action formulas.
If we allowed ‘polymorphic’ linking, then this would be lost - i.e. if the trigger is when an entity of any database is linked to the ‘This month’ entity, it would be feasible to define some actions that operate on ‘This month’ but the options for what changes the automation could make to the entity that was linked would be severely restricted, since there aren’t many fields that are guaranteed to be shared by all possible databases that might be linked.

I hope that makes some sense.


Hi @ChrisG

Thanks for your detailed response. Let me start by replying on the part about "trigger an automation on multiple ‘Entity linked to…’ ".

While it may be a nice solution, I can imagine that it has major implications on the formulas as you point out. I think the consequence of my feature request is more detrimental than the benefit. I will therefore move this post to the “Show your space” category. Since I also show a part of our planning solution.

Furthermore, you indicate that you are working on a little custom integration yourself. @YvetteLans and I have discussed this. If you are open to it, we would like to help you create this integration. We are willing to make our solution available for the whole community as a template if we can optimize and simplify it in cooperation with you. We expect that the flexibility our solution gives will be of interest to a lot of users.

If you want, let’s talk about the easiest way to inform you about all the details of our solution.

I’ll be happy to hear from you!


Hi @Marloes,
I hope to have a basic custom app that you can test next week. I would love to hear what you (and anyone else) thinks it does well/badly, and we can iterate together :slight_smile:


@ChrisG That’s amazing! As of Saturday, I will be on vacation for 1.5 weeks, but Yvette will definitely look into this (and so will I as soon as I get back :smiley: ).