Search Privacy & Constraints: FAQs

We added a separate permission controlling whether a field can be used in search constraints ("constrainable"), independent of whether the field can be viewed. This gives developers more precise control over when values can be accessed through searches. We also added a new Search Privacy setting and updated the Security Dashboard to proactively identify constrainable fields and guide remediation.

To strengthen application security and give developers more precise control over how sensitive data can be accessed through searches. The updated Privacy Rules system and Security Dashboard help identify configurations where hidden fields may still be usable in search constraints, allowing users to review and tighten access patterns more proactively.

A field is constrainable if it can be used as a constraint in a search — e.g., Users where email = … or Orders where status = paid. This is separate from whether the field is visible. A field can be hidden from view but still usable in searches, depending on the Privacy Rules configuration.

It lets developers control whether a field can be used in search constraints and filters, separately from whether it can be viewed. This provides more granular control over how data can be accessed within an app.

Previously, users only had control over whether a field was viewable. Now, users can control if the field can also be used in search constraints and filters.

You can make a field non-constrainable by updating its Privacy Rules settings and disabling its ability to be used in search constraints or filters.

Not necessarily. Evaluate whether a field truly needs to be searchable for app functionality. Highly sensitive fields should generally have more restrictive settings unless constraining is required for a legitimate use case.

Yes – a field can be visible to users while being unavailable for search constraints or filters.

Yes – Bubble continues to support using a field as a search constraint without exposing its value directly. (This is also the configuration most likely to be flagged for review.)

Fields commonly used for app functionality and user experience should typically remain constrainable, such as statuses, categories, dates, ownership references, or other operational fields needed for search constraints and filters.

When deciding, weigh whether the field is necessary for functionality and whether allowing it in searches aligns with the data's sensitivity and intended access patterns.

Switching modes changes how constraints are enforced; in Strict mode, constraint permissions are enforced exactly as they are set in privacy rules. In Off mode, constraint access is automatically granted for all fields, regardless of Constraint permissions set on privacy rules, and you'll see a warning message in your privacy rules.

A new section that flags fields that may be searchable/constrainable in ways that warrant review. It's meant to help developers understand how their Privacy Rules are configured and where more restrictive settings may be appropriate.

The Security Dashboard determines risk based on Privacy Rules configurations, including whether fields are constrainable, whether they are viewable, and the relative sensitivity of the data involved. Findings are categorized by priority level to help developers identify fields that may require additional review.

See How to resolve a "Constrainable Fields" flag, above.

If a field previously used in search constraints is now marked non-constrainable, searches relying on it may stop returning results or behave differently. Update the affected workflows or Privacy configuration accordingly.