The option to have 0 decimal places is greyed out when using the money format for number fields. Is this expected behavior?
It is currently not possible to change a number field from being ‘decimal’ (having 1 or more decimal places) to being ‘integer’ having 0 decimal places.
It is possible to create an integer number field with money format, but its not possible to change an existing field to become an integer number field.
Got it, didn’t realize the format of field could not be changed after creation. Related issue for anyone else who gets here: Add ability to fully edit fields after creation - #10 by Simeon_Payne
Ouch. This one’s biting me bigtime. I can’t figure out a way to save Money decimals while only displaying whole dollars. 
It doesn’t make cents! 
So I’ll add my two cents… Frontend visualization should be separate from backend data storage. I often want to save transactions with decimals and then just view as ‘integers’.
See how SmartSuite handles this below. 
Can you clarify exactly what you mean. Do you want the data to be stored with two decimal places, but only shown as whole numbers in some specific situations/views?
Or is it that the field should always allow edits to be made with 2 decimal place resolution, but always be displayed with only integer resolution.
Sure Chris, thanks for asking. My argument is much bigger/broader than my previous comment (or your follow-on questions honestly), so let me take a step back and tell you what actually happened to me so y’all understand a very real user’s journey.
I was creating many fields to house financial data in the $K to $M range. I knew I wouldn’t need to see pennies on screen, so I specified 0 decimals. But then later when entering exact dollars and cents per some detailed profit/loss statements, I started noticing the math wasn’t matching Excel or Coda or Notion or SmartSuite. 
That’s when it dawned on me that all my input decimals were lost, since apparently Fibery’s decimal selector affects the raw backend data too(!) and not just the frontend formatting as expected.
So naturally I changed all the fields to 2 decimals and re-entered loads of data to reach perfect parity. 
Whew, beautiful. Oh but wait. Now the 0 decimal option is grayed out. I can no longer even view large dollar amounts without noisy decimation. 
And I can’t revert or recreate anything since I’ll lose all my relations, references, and calculations.
All that to say… Loosely-coupled beats tightly-coupled all day every day when it comes to precision & formatting. I don’t want to think about efficient data storage of integers vs floats vs doubles. I just want to populate raw data verbatim and then view it later however, like a boss.
Now, if Fibery can save server space & time by storing whole numbers as integers, fine, even great(!), but please don’t prevent me from adding or removing decimals ad hoc. As for visualization, I should be able to display any level of precision, regardless of how it’s stored.
Does that help? Thanks again for engaging so swiftly & sincerely.
There’s a solution! But its not the prettiest.
What you can do is set it with two decimals, then use a formula to round, the only down side is that this formula is then read only, so if you want to edit there will be extra clicks or the info showing twice. Here’s the set up:
If(
Float >= 1000000,
ToText(Round(Float / 1000000, 1)) + “m”,
If(Float >= 1000, ToText(Round(Float / 1000, 1)) + “k”, ToText(Float))
) + “$”
The weird thing is that I think the Round function actually can’t round to zero decimals… Round() function creating decimals even if places = 0 Not sure if this will be solved any time soon.
What i recommend in order to not have the same field twice with two visualisations, is to hide the raw number and add a button for “Edit price” which will then ask user for the number, and then edit it. It’s a bit less pretty than other solutions, but more custom as you can set the formula to be whatever you want. (Except for a number with no decimals apparently? 
There might be a solution im not aware to this on though) Lmk if you need more guidance on the button set up.
I just tested it, indeed the different types of floats can be set to different decimals without it affecting the actual data. The number of decimals in a float is indeed just visualisations, except for 0. So the dropdown contradicts itself in functionality without being clear to the user (which is where your mistake happened). I honestly would go for two different field types. “Float” and “Integer”. And floats can be set to have 0 decimals (while still being a float). This would help with being able to edit fields after creation. (Because under the hood its two field types baked into one).