I have a problem. There’s a limit of 1000 entities in workspace template. This is an issue because one of the databases is “Status” and many automations use this database and specific entities from this database. Indeed I don’t need to import all tasks and projects from the template (ideally not actually because things can’t be truly deleted), but there are some databases (and their entities) that need to be in the template for it to work.
Hope this makes sense.
I am aware that another solution is to build it without the data, and keep a copy of it before the client data is added, but what usually happens is that new features are added as time passes, and then would force me to maintain two workspaces.
You could temporarily move the databases you want to include in the template to all be in one or two spaces, export only those spaces, and then move the dbs back out into the spaces where you want them to finally live.
I’m not sure what you mean. If you’re exporting a workspace template (from the workspace map) and you choose several spaces to include, then all databases in those spaces will be included, and all relations between those dbs will be included.
Of course, any relations to databases in spaces that are not included in the export will be ignored.
Just tested this and it doesn’t really work since the relation isn’t kept.
Here’s my setup:
Status → Project
I have more than 500 projects, but I need the status database as many rules and filters rely on a specific item in the status database. Where project is “Active”.
If I import them separately, the relation is gone, which breaks the rules and views. If i import together, the status item is gone which breaks the rules and views. I cant import together with the status items as the projects DB has more than 500 entities.
1,328. But it might also be relevant for the Tasks database which has 11,160 entities.
But note that I don’t need all the entities to be templated. I just need the State to be templated, and keep its relation (in schema) to the Projects database.
So then I don’t understand. If you export a subset of spaces in a template (via the workspace map) then all relations between the dbs in those spaces will remain intact, and automations should work as expected.
But it is this comment:
Do you need entities, or don’t you?
I suppose you need entities in the State db, but not in any other dbs.
At the moment, there is no way to include/exclude entities on a per-database basis, so I think you’re stuck.
I would think the easiest might be to export without entities, and then in the cloned space, recreate the necessary State entities, and fix any broken automations.
Then you can use the clone for any future templating.
This is true. But will take a lot of work as there are quite a few of automations… and when it is deleted it just shows “Deleted” without saying what it was before.
I’ll bite the bullet when the time comes, but this is something that will be quite common long term (at least for me).
Projects:
When its done, (100%) set the state to completed.
Set to active state when a due date is set.
Set activation date when state set to active.
Don’t allow to be set to active manually (where deadline is empty)
Clients:
Set stopped date when the state changed to not active
another 3 automations with stopped date
Yeah not too many actually. But if trying to sell a template, it’s not realistic to ask the customer to reconfigure before things actually work.
There also probably around 10-20 ish views that also have an “Active?” filter on them.
originally because we were going to invite clients into their client entity and didnt want them to have access the the state. we ended going a different route, but that was the main reason. and for projects the same (in this case we still give clients direct access to the project database).