There is a decent workaround for that already. You may setup several Action Buttons to fill many fields with a single click. For example, for Sprint Review you can add this button:
And when you click it it will fill two fields
You may ask your teammembers to add a meeting and then invoke relevant action to prefill it.
My vote is also for the Templates feature. People on my team are used to creating various templates for themselves in Notion.
We have this in plans for Q2
I came across the original use case for entity templates today, applying templates to meeting records, and wanted to share some observations and workarounds from my workspace.
The meeting use case is a great example of the need for dedicated templates because we typically want all meetings, regardless of type, stored in a single database. However, the meeting note template should vary based on the meeting type. To handle that, I’m experimenting with a workaround: creating a rich text field in a multi-select option that holds the appropriate template for each meeting type. I then use an automation or button to insert that template into the meeting notes. (This is similar to the reporting space solution where report types and prompts live in another database, I just prefer fewer databases)
This is a bit of a shift for me, as I’ve generally avoided using a “Meeting Type” select field. The Google Calendar integration doesn’t populate that field automatically, and I prefer to minimize manual input. I may explore using AI to help estimate and fill that field going forward.
The most common workaround is one I use where all entities in a database share the same structure — I use automations that apply a default template when an entity is created. I also include a backup button to reset and reapply the template. I’ve implemented this in my standups, wiki docs, and tasks databases.
@helloitse Have you looked at Notion’s meeting notes? (I’m not suggesting to switch, I’m just saying for ideas – I happen to have come to Fibery after purchasing a 1-year subscription to Notion so I’ve been using their transcription tool to try to earn back the cost of my subscription which I use for basically nothing else).
What they do is have 3 sections:
Yes, I have encouraged all my clients who were already in Notion to adopt their native meeting notetaker over the last year.
In my Google Calendar database here in Fibery, I’ve had separate rich text fields for AI generated content and my personal notes for a few years now.
Hey! I just saw this was added the roadmap, so I wanted to share my 2 cents.
I don’t understand the need for this, when it can be achieved already using automations.
You have two databases:
When a meeting type is linked to meeting, run an automation that pulls the rich text into the meeting. You can even make meeting type a required field to ensure it gets created each time.
I think this is not too hard to understand and set up for a new user, but I might be biased.
The part that is hard to set up right now is nested hierarchy templates.
I didn’t see on the roadmap how to handle something like “Set Deadline of Tasks to be X days before deadline of project”. I struggle to see how it’s possible with the current spec sheet, but I may be missing something.
I would much rather have looping available in automations that would make templating hierarchy easier to set up, and stay more flexible than “Template Entities”. And its a feature that opens a lot more doors than just templating.
If we want it to be more intuitive, maybe a button to “Turn on Templates” for a database, then it asks you which relations you also want to template, then it sets up the template databases and automations for you. I’ve found often that the templates need slightly different fields than the clones the moment things get a bit more complex.
My 2 cents, but do let me know where you think this falls short. I’ve been pleasantly surprised by the usefulness of things I didn’t think were needed in the past.
This was discussed a bit on the partner call this week. @danielbmarsh showed how he does templating, and it’s similar to what I mentioned above.
Most importantly, it uses a separate database for templates, rather than flagging a certain entity as a template.
I’ve explored both options in the past using current technology, and the former is far superior. From a flexibly and UX perspective.
So even if you don’t add for loops in automations, I’d urge the team to explore this approach to templates than marking an entity in a database as a template.
Again, open to discussion and thoughts.
This approach has many problems.
To be honest, I see very few benefits and many problems.
Thanks for your reply.
I’ve done this multiple times with current automations. Indeed its not super simple, but its possible without scripting. If we had “for” loops this would be much easier:
For task template related: create task in project + for subtask related: create subtask.
It might still need to be 2 separate automations… depending on what’s possible here.
I don’t want to waste your time, but I’m curious if you have examples for automation rules here that would be hard to set up, that are easier to set up for the architect with the currently proposed solution.
This is true, but a lot of the time they shouldn’t be the same schema. For examples “Days due before deadline” on the template and “Deadline” on the task. Maybe a button to “Also add to templates” when making a new field on a database.
Or for example you want to notify when an assignee is assigned, but you don’t want them notified when they are assigned in a template…
I really see a template to be a different “thing” to what is created from the template. Different thing → different database. This means some fields on the database will only be relevant for templates, and other fields will only be relevant for the actual instances whenever you’ll want anything with dynamic values.
I see how it can be harder overall for the architect when things get more complex, but I’d argue its just as easy when things are simple, and it allows for things to be set up in a more complex way down the line, where current specification does not.
There’s still in the spec that’s TBD, like dynamic properties, so I’m just really curious how you’ll balance simplicity with the ability to create complex templates (more than just a simple copy paste).
If you have questions let me know!
PS. Is it okay to discuss these things early, or would you guys prefer to wait until things are released / ironed out before starting discussion? To know for future.
