Allow editing Data Tables in Protected Environments (for environment-specific configurations)

Feature Requests
1

Problem

In Protected Environments (Settings → Environments → “Protected Environment” enabled), workflow editing is correctly disabled to enforce Git-based deployments. However, Data Tables remain locked for manual edits, even though their content (rows) is not version-controlled via Git—only metadata and column definitions are.

This creates an inconsistency with Credentials and Variables, which can be edited in Protected Environments (as their Git stubs require environment-specific adjustments). Data Tables often serve similar purposes (e.g., storing environment-specific configurations like API endpoints, feature flags, or lookup values), and blocking manual edits forces workarounds like:

  • Temporarily disabling environment protection (risky)
  • Using external storage (e.g., databases) for what should be simple table data
  • Hardcoding values in workflows (less maintainable)

Proposed Solution

Allow manual editing of Data Table rows in Protected Environments, while keeping the table schema (columns, types) tied to Git deployments. This aligns with the existing behavior for Credentials/Variables and acknowledges that:

  1. Data Table content is not part of Git deployments (only structure is).
  2. Environment-specific data (e.g., prod-only configurations) must sometimes be added post-deployment.

Potential Concerns Addressed

  • Safety: Row edits wouldn’t affect workflow logic (unlike workflow changes), and schema changes would still require Git.
  • Consistency: Matches the current treatment of Credentials/Variables.
  • Use Case: Critical for teams using Data Tables as lightweight configuration stores (e.g., for environment variables, feature toggles, or dynamic routing rules).

Impact

  • Reduces friction for teams using Data Tables for runtime configurations.
  • Maintains security by keeping schema changes Git-controlled.
2

This is a real gap, and I think the asymmetry is the whole story: a Data Table’s schema is Git-managed while its rows are instance state, so a protected environment blocks UI writes to anything that mutates the instance and both locks arrive bundled together even though their provenance is different.

Workarounds that work today: keep environment-specific values (API endpoints, feature flags, lookup values) in Variables, which n8n already leaves editable in a protected environment; and if rows genuinely must change per environment, drive them from your deployment pipeline or keep them in an external store (Postgres/Redis via a credential node) so the change is reproducible rather than a one-off UI edit.

Worth adding to the request that row data isn’t exported with the Git stub, so any prod edit is shown as silent drift – that is the strongest argument for a separate “edit rows” permission instead of unlocking schema changes along with it.

3

Problem is fixed with release 2.45.0: fix: Align data table and variable editing on protected instances by ireneea · Pull Request #41258 · n8n-io/n8n · GitHub