[ Data Providers ] - Expose Budibase `_id` in Custom Queries for External Tables

[NDCallahan]

🧩 Feature: Expose Budibase _id in Custom Queries for External Tables

📝 Description

When using an external table with standard bindings, Budibase automatically provides a synthetic {{ _id }} field. This internal identifier allows components to track the selected row, navigate between screens, and maintain consistent “current row” behavior.

However, when a component uses a custom query (even if it queries the same external table), Budibase no longer injects the {{ _id }} field. The result is that components lose access to the Budibase-generated identifier, causing issues such as:

• “Current row” no longer matching the selected item
• Navigation parameters breaking
• Components behaving as if a different row is selected
• Inconsistent behavior between standard bindings and custom queries

This behavior is expected today, but it creates real limitations when using custom queries to filter, sort, or shape data.

---

💡 Use Case

As a Budibase user, I want to:

• Access the Budibase-generated _id field even when using a custom query.
• Maintain consistent component behavior regardless of whether data comes from:
  • A standard external table binding
  • A custom SQL query
• Ensure that “current row,” navigation, and component logic continue to work as expected.
• Avoid duplicating _id manually into another column just to preserve Budibase behavior.

---

🔍 Current Pain Points

• Custom queries remove the _id field entirely.
• Components lose the ability to reference the selected row reliably.
• Navigation and detail screens break because _id is missing.
• Workarounds require:
  • Creating a duplicate column to store a Budibase ID, or
  • Rewriting logic to use raw primary keys
• This creates inconsistency between standard bindings and custom queries.

---

🎯 Expected Behavior

• Budibase should expose _id (or an equivalent synthetic identifier) to custom queries for external tables.
• This could be implemented by:
  • Automatically injecting _id into custom query results, or
  • Providing a function to generate _id from the table’s primary key, or
  • Allowing users to map a primary key to _id in the query result.
• Components should behave consistently whether data comes from a standard binding or a custom query.

---

🚀 Why It Matters

• Enables consistent component logic across all data sources.
• Prevents navigation and “current row” issues when using custom queries.
• Reduces the need for workarounds like duplicating _id into another column.
• Makes filtered or transformed views of external tables behave the same as the base table.