Suggestion for Enhanced Button Functionality in Baserow

Hello Baserow Team!

I wanted to share a key use case scenario for Baserow in my operations and propose some enhancements that could be implemented by your team.

Currently, I actively use Airtable in conjunction with n8n to generate contracts in Google Docs based on data from Airtable, as well as to create payment ledgers in Google Sheets. There are several other scenarios too. This setup has transformed our database into a full-fledged corporate application, based on a simple yet powerful idea: sending a webhook containing the row identifier to a system like n8n or Make and configuring the necessary automations.

I attempted to transition our existing Airtable + n8n logic to Baserow but encountered several inconveniences. I’d like to discuss these below and offer suggestions for potential improvements.

1 - Enhanced Button Functionality Using Formulas:

Transform Baserow buttons into real buttons rather than mere hyperlinks, akin to the user-friendly design found in Airtable. This enhancement would improve the visual and interactive experience.



2 - Refined Button Activation Conditions:

In Airtable, there’s an ingenious feature where buttons can be made inactive unless certain conditions are met, like the activation of an adjacent checkbox.

This prevents accidental clicks and enhances user interaction. However, when attempting to implement a similar conditional activation in Baserow, the button, unfortunately, becomes non-clickable, losing its intended functionality.

Here is an example formula, which make button non-clickable in both conditions:

IF(field(‘Activate buttons’),
button(CONCAT(‘https://myserver/webhook/24cd0401-18802f1082df?database_id=77&table_id=232&record_id=’, field(‘Row(ID)’)), ‘:radio_button: Create Offer :radio_button:’), ‘Create Offer’)

3 - Streamlined Automation Using Webhooks:

To work with a row in Baserow using automation tools like n8n or Make, three parameters need to be passed in the webhook: ‘database_id’, ‘table_id’, and ‘row_id’. While the variable for ‘row_id’ is readily available, there is a notable absence of variables for ‘database_id’ and ‘table_id’. This omission requires users to manually enter these details, which is not only less convenient but also prone to errors due to manual data entry. Introducing variables for ‘database_id’ and ‘table_id’ would simplify the setup of automated webhooks buttons in Baserow.

4 - Rapid Automation Expansion with Embedded HTTP Requests in Buttons:

Introduce a transformative feature where Baserow buttons can execute an HTTP request (typically a POST request) directly to a specified webhook URL upon being clicked. By embedding the request within the button, the URL remains hidden, boosting security and user experience. This functionality would drastically expand Baserow’s automation capabilities, enabling users to set up diverse, complex automations quickly and seamlessly.

Hey @Alexander, thank you for sharing your idea. We are actually starting to work on making the button formula function appear as an actual button very soon. You can track the progress here: Resolve "Button formula function should show as an actual button" (!1918) · Merge requests · Baserow / baserow · GitLab.

I will share your ideas with the developer in charge of building it. Thank you for the detailed explanations. :raised_hands:

Thank you for your answer.
Btw, does that make sense to participate in a discussion on gitlab?

Hey @Alexander, sure! Feel free to leave your ideas as comments there. :slightly_smiling_face:

Small update to an idea for point 3: the requirement of three variables - ‘database_id’, ‘table_id’, and ‘row_id’. This will also provide a method to create a unique ID for a row, consistent throughout the entire database. Simply concatenate one after the other.

Hello @Alexander,

thanks for your feedback. I wanted to share that “Add the workspace_id and the database_id to the webhook payload” has been merged, and it will be part of the next release.

With these changes, the webhook payload will be something like:

    "table_id": 3,
    "database_id": 2,
    "workspace_id": 1,
    "event_id": "00000000-0000-0000-0000-000000000000",
    "event_type": "rows.created",
    "items": [
            "id": 0,
            "order": "1.00000000000000000000",
            "Name": "",
            "Last name": "",
            "Notes": "",
            "Active": false,
            "Duration": null,
            "Date": null

Could you try this formula instead?

IF(field(‘Activate buttons’),
button(CONCAT(‘https://myserver/webhook/24cd0401-18802f1082df?database_id=77&table_id=232&record_id=’, field(‘Row(ID)’)), ‘:radio_button: Create Offer :radio_button:’), button(‘’, ‘Create Offer’))

I advise creating a button with a blank link for the false branch of the if statement, instead of plain text.

This way works, thank you for the solution!

Hey @Alexander, just a quick update. The button formula function is now displayed as an actual button in Baserow. :slightly_smiling_face:

Hello! Awsome, thank you, will test it)

A post was split to a new topic: How to use button function linked with a webhook for generating contracts or invoices

@olgatrykush btw, are there any chance to have an http request on a button click?)

Hey @Alexander, first of all, thank you for sharing how you use the button function. It’s a great use case. I hope you don’t mind that I posted it as a separate topic in the Tips & Tricks section for better visibility. :raised_hands:

Let me check this with the dev team. Is it crucial for you to have it?

Hey, absolutely, I’d be more than happy if you publish it! Thank you for giving it more visibility. :+1:

Yes, for me very important)
I’m inclined to move the financial database from Airtable to Baserow once certain functionalities are released in Baserow. Currently, in this database users generate lots of agreements and invoices based on the data in the table by button click. I find current approach with button with a link not very secure, as I aim to hide the webhook from users. Additionally, opening a new tab instead of executing an action directly feels like a makeshift solution rather than the awaited behavior.