01
Row-level security on every farm table
Database-level policies ensure a query can only return data for farms the requesting user actually belongs to, regardless of how the request is made.
Security
Your farm’s data is isolated by design, not by policy.
Boma enforces farm data isolation and role permissions at the database layer using row-level security, so access control is a real technical boundary, backed by an audit trail of who did what and when.
Row-level security
Farm data isolation enforced directly at the database layer.
Audited
Sensitive actions are recorded with actor, entity, and timestamp.
No PII in analytics
Platform usage analytics are built to exclude personal data by design.
Security
Access Boundary
Enforced at the database, not just the UI
Row-level security means a farm’s data cannot be reached by another tenant even if a request bypasses the visible interface.
Product screenshot placeholder
What This Feature Does
In plain terms
Security and Farm Data Control describes how Boma protects farm data as a foundational property of the platform, not a feature bolted on afterward. Every table that holds farm-specific data — animal records, health events, milk entries, team membership, reminders — is protected by row-level security, meaning the database itself refuses to return rows belonging to a farm the requesting user does not have access to.
On top of data isolation, role-based permissions determine what an authorized user can do within their own farm, also enforced at the database layer. A worker calling the same underlying data a manager can call still cannot perform manager-only actions, because the permission check does not live only in the app’s interface — it lives in the data access rules themselves.
Sensitive administrative actions — suspending a farm, changing a subscription, granting platform admin access — are recorded in an audit trail with who performed the action, what it affected, and when, so accountability does not depend on someone remembering what happened.
Key Capabilities
What you actually get
Each capability below is available today inside Boma, not a roadmap promise. Together they form the working core of this feature.
02
Role permissions enforced at the data layer
Farm role restrictions are checked at the database, not only hidden in the interface, so access boundaries hold even for direct data requests.
03
Audit logging for sensitive actions
Administrative actions like suspensions, subscription changes, and role changes are recorded with actor, entity, and timestamp.
04
Idempotent writes for safe retries
Offline mobile submissions use idempotency keys, so a retried sync after a dropped connection cannot silently duplicate a record.
05
Immediate access revocation
Suspending or removing a user or farm membership takes effect immediately, closing off access without a delay window.
06
Privacy-conscious usage analytics
Platform-level usage analytics are built to exclude personal data such as names, emails, and passwords from tracked event payloads by design.
07
Distinct platform admin boundary
Platform administration is a separate role from any farm’s own membership, so elevated platform access does not implicitly grant access to a specific farm’s operational data beyond what administration requires.
Why It Matters
The operational cost this feature actually removes
Farm operations data is sensitive in ways that are easy to underestimate: financial signals like sales and production trends, personnel information tied to team accounts, and operational detail that a competitor or bad actor could misuse. Software that treats access control as a UI convenience rather than a real boundary is one configuration mistake away from exposing that data.
Boma’s approach is to make the database itself the enforcement point. A bug in the interface, a misconfigured screen, or a direct API call cannot bypass row-level security, because the restriction is not implemented in the interface at all — it is implemented where the data lives.
Isolation that holds even if the UI has a bug
Because enforcement is at the database, an interface mistake cannot expose another farm’s data.
Real accountability for sensitive actions
Audit logging means administrative actions are traceable, not just trusted on faith.
No duplicate records from unreliable connections
Idempotent writes mean field conditions cannot corrupt the accuracy of the farm’s record.
Analytics that respect farm privacy
Platform-level usage tracking is scoped to product analytics, not farm operational or personal data.
Use Cases By Role
How each person on the farm actually uses this
Boma is built around real farm roles. Here is how this feature shows up differently depending on who is signed in.
Owner
Trusts that competitors cannot see their data
An owner evaluating Boma against a spreadsheet or a shared drive gets a real technical guarantee that their farm’s data is isolated from every other tenant, not just a policy statement.
Manager
Removes a departing worker’s access with confidence
A manager suspending a former employee’s membership knows the access is closed immediately, not eventually, and that the action is logged.
Worker
Operates within a clearly bounded scope
A worker’s access is limited to what their role allows, enforced at the data layer, so there is no risk of accidentally reaching data or actions outside their responsibility.
Vet
Accesses only the farm they are actively engaged with
A vet working across multiple farms only sees data for the farm they are currently a member of, with no bleed-through from other engagements.
Admin
Reviews the audit trail during a security review
A platform admin investigating an access question can review the audit log to see exactly which administrative actions occurred, by whom, and when.
How It Works
Step by step, in practice
Security is not a separate step in the workflow — it is enforced continuously as part of every request.
- 1
A user signs in
Authentication establishes who the user is before any data request is evaluated.
- 2
Every data request is checked against farm membership
Row-level security policies confirm the requesting user belongs to the farm the data is scoped to.
- 3
Role permissions govern the specific action
Beyond farm membership, the user’s role determines whether the specific create, update, or view action is allowed.
- 4
Sensitive actions are logged
Administrative actions that affect access, billing, or farm status are recorded in the audit trail as they happen.
- 5
Access changes take effect immediately
A suspension, removal, or role change is applied right away, with no delay before it becomes effective.
Data & Control
Who can see it, who can change it, and who is accountable for it
Boma is built on Supabase, using Postgres row-level security as the enforcement mechanism for farm data isolation and role permissions. This means the same rules apply whether a request comes from the web dashboard, the mobile app, or a direct API call — there is no separate, weaker access path.
Two classes of backend access exist deliberately: a row-level-security-scoped client used for normal user actions, and a service-role client reserved for trusted server-side operations like cross-farm admin queries or system bookkeeping. The service-role client is never exposed to end users, keeping the privileged path narrow and auditable.
Postgres row-level security
Farm isolation and role permissions are enforced by the database itself, not application code alone.
No weaker access path
Web, mobile, and API access all go through the same enforcement rules.
Narrow, audited privileged access
Service-role access is reserved for trusted server operations and never exposed to end users.
Consistent behavior across the platform
Every module relies on the same underlying security model rather than reimplementing its own rules.
Business Outcomes
What changes operationally once this is in place
These are the practical shifts farms describe once the feature is part of daily use, not a marketing estimate.
Real data isolation between farms
Enforced at the database, not just assumed based on interface behavior.
Traceable administrative actions
Sensitive changes are logged, supporting accountability and review after the fact.
Reliable data even on unreliable connections
Idempotent writes prevent duplicate records from retried offline submissions.
Privacy-respecting platform analytics
Usage tracking is designed to exclude personal and sensitive farm data from analytics payloads.
Questions
Common questions about this feature
Specific answers for teams evaluating whether this part of Boma fits how the farm actually runs.
How is our farm’s data kept separate from other farms on Boma?
Every farm-scoped table uses Postgres row-level security, meaning the database itself will not return data for a farm the requesting user does not belong to, regardless of how the request is made.
Can a worker accidentally access manager-only data through a bug?
Role permissions are enforced at the same database layer as farm isolation, not only in the interface, so a request that bypasses the visible UI is still subject to the same restrictions.
Is there a record of administrative actions taken on our account?
Yes. Sensitive actions like suspensions, subscription changes, and role changes are recorded in an audit trail with the acting user, the affected entity, and a timestamp.
What happens if a mobile sync is retried after a dropped connection?
Offline submissions use an idempotency key, so a retried sync is recognized as the same entry and will not create a duplicate record.
Does Boma include personal data in its own product analytics?
No. Platform usage analytics are designed to track product-level events like page views and feature usage while excluding personal data such as names, emails, and passwords from event payloads.
Related Features
Works alongside the rest of the platform
Ready To Try It
Put your farm’s data behind real technical boundaries.
Talk to us about how Boma secures farm data, or start free and see the access model in practice.