Sequential Name Formula?

[Hendrik]

Thank you for clarifying @ChrisG

@Chr1sG

[MEETING TYPE].Name + " #" + ToText([MEETING TYPE].Minutes.Filter([Creation Date]<[This Minute].[Creation Date]).Count() + 1)

Yes, this works. Though I meant just counting the entities and leaving the date out of it altogether (?) If Creation Date is static / fixed I guess this would not matter.
Trick up your sleeve to show double digits? SITE MEETING #01 instead of #1 - oh I see it’s the ‘zero padding’ thing you are talking about. How do we add zero padding? (don’t tell me to stop eating croissants)

@Chr1sG

Imagine you create a site meeting minutes. It will be called SITE MEETING #1.
Then you create another, and another. Eventually you have site meetings all the way up to SITE MEETING #20.
If you now delete SITE MEETING #5, then all those meetings with number higher than 5 will move down a place. You will now have #1, #2, #3, #4, #5, #6, … #19 instead of #1, #2, #3, #4, #6, #7, #8 …#20

Yes, I see. This is a very low risk in my case. Though I don’t like it. If, at some stage in future, we do have to delete / correct some entities we may well have forgotten this nuance and then, mass renaming attack!

I see Name by formula updates all names, past and present. Would be kinda neat if there could be a tickbox to ‘only affect future entities’ or even better, entities after a certain date. I am sure this could be useful.

Or is there already a way to use the formula to create the Name and paste it as a static string in the Name field?

[Chr1sG]

@Hendrik

Though I meant just counting the entities and leaving the date out of it altogether (?) If Creation Date is static / fixed I guess this would not matter

Imagine you have 3 records, called A, B, C. If you have a formula that says, “the number of this record should be 1 more than the total count of other records” then for record C, this means the number is 3.
But the same is true for A and B! Every record sees that there are 2 other records, so calls itself 3.

The only way to avoid this is to include something that puts them in order, which is why I used Creation Date.

@Hendrik

How do we add zero padding?

In general, you can do this:

Right("00" + NumberAsText, 3)
(which forces each number to be 3 digits long, e.g. 001, 002, etc.)

In your case, it would mean this:

[MEETING TYPE].Name + " #" + Right("00" + ToText([MEETING TYPE].Minutes.Filter([Creation Date]<[This Minute].[Creation Date]).Count() + 1),3)

@Hendrik

I see Name by formula updates all names, past and present. Would be kinda neat if there could be a tickbox to ‘only affect future entities’ or even better, entities after a certain date. I am sure this could be useful.

Or is there already a way to use the formula to create the Name and paste it as a static string in the Name field?

I think you should watch these videos

Formula fields

Automation formulas

so that you understand the differences between formula fields an automation formulas.

You need to decide if you want the name to be uneditable (which usually means making it a formula field) of if you want the name to be defined at the time of creation (but then subsequently liable to manual changes).

[Hendrik]

@Chr1sG

But the same is true for A and B! Every record sees that there are 2 other records, so calls itself 3.

Ok, so I think you’re saying that all Name fields will change in this case. I think I assumed we could create Name using formula but posting it as a string in the field - which is not currently the case. I think that option in future would be very useful.

---

@Chr1sG

[MEETING TYPE].Name + " #" + Right(“00” + ToText([MEETING TYPE].Minutes.Filter([Creation Date]<[This Minute].[Creation Date]).Count() + 1),3)

Awesome! This seems to work perfectly. Thank you!
Interestingly, it removed the MEETING TYPE field of all previous rows and only added these fields to the new items. I am able to change the TYPE field any time though so I might also hide this field to be safe.

@Chr1sG

You need to decide if you want the name to be uneditable (which usually means making it a formula field) of if you want the name to be defined at the time of creation (but then subsequently liable to manual changes).

These are not the defined options in my limited experience with this exercise. If you mean ‘directly uneditable’, then I would agree. In this case the name is indeed defined at creation - by a formula. And it is in fact editable after the fact - by editing (any) field the formula is dependent upon. That’s a variable. So there seems to be no way to truly fix an entity Name unless we create a formula that is not dependent on any (editable) field. I would love to see a ‘lock field’ option in future if a field is selected at created as part of a formula at creation (perhaps this is possible in a way I have not discovered?)

---

@Chr1sG

I think you should watch these videos so that you understand the differences between formula fields an automation formulas.

I will certainly, thank you.

Thanks again for helping Chris! Really appreciate it. This is one of a few key functions I am trying to building into our ‘Company Operating System’ and we will use it for many Databases. I am delighted that this is indeed possible in Fibery (even with some jiggery pokery)

PS: Simple auto-naming by convention would be a great as a standard function in Fibery - choose incremental ## / Date / Time / Season / Other DB etc with the key differentiator from other naming methods that it is uneditable because it is a ‘record’. Just a thought…

[Chr1sG]

@Hendrik

These are not the defined options in my limited experience with this exercise. If you mean ‘directly uneditable’, then I would agree. In this case the name is indeed defined at creation - by a formula. And it is in fact editable after the fact - by editing (any) field the formula is dependent upon. That’s a variable.

I think we’re possibly saying the same thing:

• you can use a formula in an automation to set the value of the name at the time it is created, but the name field is not read-only, so any user could change it after the fact (= editable)
• If you don’t want users to ever be able to change the name, then it needs to be a formula field, which means it is defined as a function of the entity’s (and related entities’) properties. Its value is therefore not set on creation and permanently immutable. Rather, it is defined by a formula, and its value might change over time if the properties used in the formula change value, but a user cannot make edits to it.

@Hendrik

I would love to see a ‘lock field’ option in future if a field is selected at created as part of a formula at creation (perhaps this is possible in a way I have not discovered?)

We have no plans to introduce field-level access control, which is what would be needed to make a field ‘lockable’ without affecting users’ ability to edit other fields.

[Hendrik]

Thanks @Chr1sG
Explanations appreciated. I’ll experiment some more.

---

H