Asynchronous controls

Let’s say, there is a rather complex table I’d like to present to my colleagues.
I already made a few controls that change quite a few values/formulas inside the table so the viewer can get exactly what they need out of it.

Problem is, once they change the controls setting, everyone else now sees the same view, which in this case is not ideal. What I’d love to see is an option to set a control element “asynchronous”, which wouldn’t share its local value with the other users viewing the doc.

I assume it would be far from easy to implement, but it would be great to hear whether someone else would find that feature useful or how impossible it would be to implement :smiley:


I totally agree with the need for asynchronous controls. Controls should be able to be set as sync or async.

This would be a big help guys.

Main reason:

  • Having a control implies there’s no single best way for users to view a given table, and you want to give them the option to filter it different ways.
  • But then why should that filtering propogate to other users? By definition the controls are there for individual users to make the decision to override the table’s default sorting because they have unique needs/interests inthe data.

(aside - I also think a clearer title for this feature request would be “User-Specific Controls”)

In the meantime, here is a workaround where you create a filtered table of users and their controls.

But please, a toggle for whether a given control should be single-user or multi-user would be very helpful!


@BenLee what’s the Coda perspective on this?

Hi @Thomas_Hils, all,

I posted a topic about data segregation: [Data Segregation]: building a game in Coda.

It’s nothing more than having the User column throughout tables, let me know maybe you could find it useful, though.


@Nick_HE, this is a question we see pretty often and we see use-cases that would benefit from this regularly as well. It’s one of those features that hasn’t quite made it to the top of the list, but it’s definitely talked about and paid attention to.

Something that’s somewhat surprised me is just how many questions pop up when seemingly small features are being put into play. There is quite a bit of planning that goes along with it and the order in which things are added can affect other things too.

I can say that Coda sees this as a feature that would add value for sure and it is important. I can also say that the order in which features are added isn’t necessarily an order of importance or demand. Some items need to be in play before others can be added and some things need to be tested before other things can be built on top of those. There is a big list of questions and interactions that need to be considered, like how will locking and permissions work with a per-user search field?

For now, using the suggest work-arounds is the way to go, but this is something that is on our list and is seen as an important feature.


Thanks Ben! Appreciate the transparency, as always.

1 Like