Maybe I am wrong, but I’m fearing I’m not:
Button formulas stopped working for me when inside Concatenate formula: they keep showing correctly the text in preview and button in formula editor, but not elsewhere.
Outside the editor, what you get is that deadly “(bolt) Action” sentence
Yes noticed and confirm exactly the same problem.
And it is very sad that the developers intentionally disabled such a possibility, such a workaround to combine several buttons in one column.
Since in my work 50% of the documents use this method, the readers of my documents are pleasant and comfortable to read the data in tables of this kind.
I hope I’m wrong, and soon we will see new features on this formula.
UPD: I received a reply from tech support about this problem. They reported that the formula is now unsupported as this formula is unstable and experimental, they recommend using the official list of formulas.
Dear @shishir and the Coda team please next time alert you to which formulas will no longer be supported in the future. Still, it’s sad that they disabled the workaround for the button formula. Which allows combine in one column saving space across the width of the table, with formulas: Concatenate Text + Button, BulletedList Button, Lookup formula ActivateRow button in another table, etc
Please do not ignore this, and return or allow the implementation of such functionality.
Thank you for your attention
Yeah, I also had this response. I am well aware of that it was an unsupported formula, and that the button column type has received some improvements, yet the possibility of place different buttons together, and furthermore, combine them with text, was essential for me to develop advanced UX.
They asked me to request officially that feature (Feature Request Form)
I suggest we all the people who used this make some noise. I am sure many advanced users got their docs broken with this change, maybe if some of this community vips, such as @Paul_Danyliuk or @Filmos make some noise our pledges are listen 
We see you. We hear you. Your buttons should come back to life within the next two prod pushes.
And we stand with you dear codians, keep doing your outstanding magic 
We were able to fix this to allow it to keep working for now, but if you are creating a doc that you rely on and cannot have it break, I would seriously consider finding a different solution and stay away from unsupported formulas.
This is still not supported and still could break with future updates.
Thank you for the update!
Please give us some official way to render inline buttons. Can’t say for everyone (although evidently it’s not only me who needs this) but I often find myself needing:
A variable number of buttons rendered inline, e.g. these are Concatenated from a table:
Different-colored buttons in different rows (no example at hand; I’m using colored labels instead because coloring a Button() is very risky):
A button inline with text either within a cell sometimes:
or as part of a canvas/cell function that may hide the button altogether:
Before clicking the button:
After clicking that button:
Adding a button to a table group to enable for custom logic. E.g. here a button is necessary to provide Add Row capability because the normal “add row” button would not automatically resolve the lookup (because we’re not grouping on a Lookup). Of course we could have a separate column for a button, but we’re constrained in horizontal space there:
Sometimes I’d like to not have a disabled button to keep the table cleaner. A disabled button with regular label would add visual clutter. Right now I have to render buttons with empty label to aid that, but imagine a long grey line here that would only distract the user. I’d rather not have this at all:
and many similar scenarios where this would be useful
All these use cases + rendering multiple buttons horizontally on a card in Kanban view.
An example would look like this
Without Button() formula, the above card would instead look like the one below. That big empty white space on the right side is useful for nothing except to enforce 60px social distancing between buttons in adjacent cards.
Since this is an integral part of my workflow, I am really grateful that the Button() formula is back (for the second time since it broke once in last November)
Also, if you want to clearly separate consultation UI from edition UI (something really necessary in my opinion, since there is little visual difference between editable fields and calculated fields, and because if you have many to many relationships you need some tricks and intermediate forms to provide user enough support) button formula comes in handy.
About first scenery, I tend to use this trick to show what text you can edit, and ease advanced edition access to user:
About the second scenary, I have no time right now to paint something easily understandable, but there are some cases, such us: delay row change until user presses accept button, assist with intermediate form where user can navigate hierarchy to find desired row, and so on and so on
Hi @BenLee - I saw in @Filmos post about undocumented formulas and the risk that the document can crash and require reverting to a previous version or resorting to tricks to navigate to a stable page and then perform workarounds to purge data and remove the problem formulas.
Is that required to use things like the button() formula? If so, IMO it’s pretty dangerous to even expose those formulas to users in the first place? I’ve discovered a need for the button formula but it’s surprising I would even need to worry about something like that since when I type button( in the formula editor, I see the function signature for it and it’s surprising that I could get myself into such a dangerous situation in such an innocent way.
What sort of guarantees do we have when using a formula like button? Would your team help to fix a broken document if such a case arose? Thanks as always!
They are not exposed. They are not on the list; they won’t show up in the formula editor suggestions until you’ve finished typing them out; they have this icon before them saying these are experimental formulas.
Basically if you didn’t know about them, you normally wouldn’t even try typing them, and if you found them by chance you’d be scared away by the experimental icon.
No one would fix your broken doc if it’s you who broke it by ignoring the warnings.
I didn’t notice the experimental sign, thanks for pointing that out.
If an experimental feature is buggy, behaves in unexpected ways, is deprecated, removed, or has breaking interface changes in an update - I think that’s fine. However in my opinion anything exposed to the user should guarantee that the document at least loads or that the user can somehow recover. Buttons can be broken, formulas can be broken, tables can have the wrong data, views, etc, but I should at least by able to modify the doc and attempt to fix the problem.
Maybe this would require a sort of “debug” mode of the document where no formulas are evaluated, no automations run etc, or maybe it would simply be a matter of making all the code paths production ready.
If Coda experimental features have no such guarantee, then in my opinion I think the app should give a much louder warning to the user that the feature should not be used in any production scenario, including when copying docs. There are plenty of docs used as examples here on how to implement things that contain these formulas, it’s quite easy to use something someone else set up that has these formulas without even knowing it. This is actually how I came upon the button formula.
Im trying to use the button() formula in my canvas, but can’t seem to get it to work. Im able to get it to work in a table/column but not in the canvas. Am I missing something?
No matter what I try for the 1st “value” argument, it doesnt seem to work for me
@Paul_Danyliuk, @Juan_Manuel_Perez_Lostao or @Evgeniy_Mamontov - any ideas appreciated!
The only way to get the button into a canvas is to first set it up in a table and then reference that created button in a canvas formula.
TL;DR: Button() formula can only exist in a table. The first argument has to be a column, either a button or an action object. Button().Concatenate("") would remove the weird padding and result in a normal-looking button. It’s going to be rich text though. But you can use it wherever you can reference text then.
Thank you! I knew there was something going on
I can’t find the Button formula, has it been removed?
I am rendering an input control, and when the text changes I perform a search on an external API (in a Pack action). I want to show the results in a list, with a button toggle so you can insert/remove results into a table
Hi matt,
Formula is still there. Remember it is a table formula, can only be used there. You should find something like this: Button formula finally (almost) down :( - #12 by Paul_Danyliuk
Although still existing, I’ve found now button no longer can be used multiple times in single field, so if what you are trying to achieve is to insert multiple buttons in single field, I’m afraid trick is not working anymore.
You will need to find a way to deploy each of the results in your list on a table record each one, so you can show buttons for all of them… hereby, rendering current Button() workings useless for your purposses, since in this scenario it will be easier and more robust to use a Button field.
