Hi guys,
Trying to automate an entity name upon creation, using a formula in a MINUTES database that Automatically increments from the previous TYPE of entity. Eg, we have different types of meeting MINUTES in the same DB. When creating an entity, the user selects the TYPE (linked DB) but then I would like Fibery to determine the last number (eg SITE MINTES #05) and create the name for the next number sequentially for that MINUTE TYPE (SITE MINUTES #06 in this example). All the while leaving DESIGN MEETING #11 or any other types unaffected.
Tried creating a separate MINUTES # field to handle the number and combine the two but cannot seem to get it to auto-increment.
Hope this makes sense. Any assistance appreciated.
This is possible using a formula for the entity names in that database and setting the formula to [Type].Name + " #" + [Public ID]
Fibery does not have an incrementing field type but all databases have a Public ID field that you can reference. The public id increments as the database grows. The first entity is usually public ID #1.
(The key difference here is that an incrementing field would calculate only from currently existing entities, public ID’s belong to an entity even after it has been deleted)
Unfortunately this does not do the trick though, mainly because it reference the Public ID, precisely because of the limitations you pointed out. If we had a database for every meeting type this could work (provided we never make a mistake when creating an entity)
But also because it ignores the types, which needs to have their own sequence.
We’ve created a semi-automated way for now by using another ‘Minutes #’ field and joining the two in the name. This way at least the name reflects the type - another DB which we use in another automation when creating the PDF report.
I thought that perhaps we could auto-increment the Minutes # field and so get a full automation going, but number fields can not have a formula, which I find a bit strange TBH.
If you have any other thoughts or solutions, by all means let us know!
Hi Hendrik,
It’s definitely possible, but before suggesting something, I want to check - when does the type of the Minutes get defined? Is it guaranteed to be set at the point of creation?
And might the type ever get changed?
What should happen if a meeting entity is deleted? Should its number be reused, or never again?
Hi @Chr1sG
It get’s defined at entity creation - so it’s type is guaranteed then.
Type should never need to change and I see no reason to allow for deletion.
However, an incorrect type could of course be selected by mistake, in which case, if deleted it probably means that the number should be available again. I guess it would be prudent to allow for human error (particularly because I will be using it…)
Thanks for assisting.
H
I suggest adding a number field, called Index (but you can hide it most places).
Then, create an automation which triggers on creation and updates the Index field as follows: [Step 1 Minute].Type.Entities.Max(Index) + 1
Then you can use a formula for the name something like Type.Name + " #" + ToText(Index)
Thanks @ChrisG
Though this is not working for me. Here’s what I did:
Created a new field called INDEX #
Created a new rule in the MINUTES DB - When Minute CREATED THEN UPDATE # INDEX (using your formula)
Instead of UPDATE I also tried ‘THEN CREATE’.
I placed the script in the ‘f’ window. Got the following errors:
a. Reference to undefined variable Step 1 MINUTE
FIX ATTEMPT: [Step 1 Minutes].Type.Entities.Max(Index) + 1
the DB is called MINUTES - again perhaps a bit of confusion with the plural naming convention thing - the interface also says when MINUTE created, though the DM is called MINUTES
Then got this error:
b. Reference to undefined field Type
I tried inserting Meeting Type there but no dice.
The MEETING TYPE is a relation from the MEETING TYPE DB.
And by I, I mean AI… I simply entered your code in the AI prompt and it spew out this. Works beautifully. One more step to semi-automated minutes creation. Bliss…
OK. Sorry, didn’t pay attention to the fact that Meeting Type is a db and not a select field.
Try this: [Step 1 Minutes].[MEETING TYPE].MEETINGS.Max([INDEX]) + 1
If, not, try writing a step at a time and see what the autocomplete suggests
Names are strings, so there’s no easy way to add 1 to a string.
Until we have the ability to convert text to number, a numerical index field is the only way to go
That was also my understanding. Though I though it might be possible with code to harvest the last two digits of a string, convert it to number - all in the code - add the requisite number and convert it back to the name string.
I’ll accept the limitation as long as I have to, though I would love to set up the workspace as cleanly and efficiently as possible.
Just a small niggle on the minutes creation, I messed about with the above and got some results but not functional. Though now I get the Add INDEX box as well as the Add MEETING TYPE box when creating a new entity (perhaps it was also there before?!). I don’t want to see the latter because it gives opportunity for user error. It’s automated after all.
How can we achieve this please - i.e. only have the Add MEETING TYPE option when creating a new entity?
Well, technically it us possible to get a number from a string using the method here:
It’s just rather ugly!
So you could extract the number from the name and store it in a (hidden) read only field, and then use this field in an automation to set the name.
But then you have an editable name field, which similarly opens up an opportunity for human-induced error
One alternative that we didn’t talk about is to use a method to auto-number the minutes based on their creation date order.
Might that work?
It should give each Minutes entity of the same type a uniquely numbered name (calculated incrementally based on creation date).
As long as you’re not regularly adding/removing minutes, maybe it’s good enough.
Thank you @Chr1sG !
That works (in the create Name with formula) without the #INDEX field, but with a few limitations.
It produces a decimal, which is obviously not what we want (tried to fix it in the code but I trembled too much since I don’t know what I am doing)
Something weird going on with the sorting - see image.
Re your caveat about a not regularly adding or removing minutes, what does this mean? How often can I do it? What is the implication?
Finally, since you so creatively found a way via the date function, would it not be possible to COUNT the amount of minutes of the TYPE we are creating, and +1 in the formula?
