If you’ve ever used JavaScript to modify UI or enable a non-native workflow in a Quickbase app, this post is for you. We know that adding custom code to an application can be a valuable way to extend...
Updated 10 months ago
Version 2.0
Blog Post
@Nick Wade I am glad to hear that you were able to make that switch and that helped to resolve your issue with permissions. Using a method like that to let the permissions in QB help you decide what data is to be shared is exactly what we recommend. That way you aren't running a call that could serve up data to the wrong people. In regards to your API question the tool we would recommend to address that issue right now would be making use of Pipelines, after the record saves the Pipeline could call the API that you want and then enrich your data and then long term other options should open up.
@Jeff Jeff For your question the recommendation there would be to make use of our custom data rules. By this operating server side, instead of in the browser via JavaScript, we are able to validate data across all methods of data entry. So now your single rule applies to forms, grid edit, APIs, etc. It does have the ability to show that error right in line before the save but it will flag them on the save. Our PD team is definitely looking at the way to deliver that error in line for a more delightful and modern experience so feedback like this is helpful as that work goes on.
@Jeff Jeff For your question the recommendation there would be to make use of our custom data rules. By this operating server side, instead of in the browser via JavaScript, we are able to validate data across all methods of data entry. So now your single rule applies to forms, grid edit, APIs, etc. It does have the ability to show that error right in line before the save but it will flag them on the save. Our PD team is definitely looking at the way to deliver that error in line for a more delightful and modern experience so feedback like this is helpful as that work goes on.