Limiting Entity access for App Users and Data Collectors

Thanks again to everyone who shared feedback on our earlier exploration of limiting Entity access in Central. In that post, we outlined a phased approach:

  1. Single ownership: Users can see all Entities or only those they’ve created.

  2. Single ownership with changeable owners: Project Managers can reassign Entities.

  3. Group ownership: Users can be assigned to groups to access shared Entities.

Based on your feedback, technical considerations, and the variety of use cases we’ve seen, we’ve decided to evolve Phase 3. Instead of introducing a separate “group” system, we are moving towards Entity segmenting using App User properties.

What’s changing in Phase 3

Rather than creating and managing separate groups, you’ll be able to:

Add properties to App Users,

filter access rules using these properties (ex., entity.region = user.region) to determine which Entities a user can see,

and reuse properties across multiple Entity Lists, making it easier to keep access logic consistent across lists like farmers, plots, and harvests. Note that each Entity List will have its own filter rule. We will start with simple equality-based filters but expect to expand that in the future.

Alternatives we considered

The original idea for Phase 3 was group ownership, where project Managers could create explicit groups (e.g. “Team A,” “Zone North”), assign users to those groups, and then tie Entities to them. We also explored hierarchical groups and role-based access linked to form assignments.

This concept, although easier to explain (ex. “If you’re in Group X, you see Entities in Group X”), had the downsides of introducing another object type to manage, and limited flexibility for projects needing segmentation by more than just one dimension.

Why this approach?

Flexibility
Users can create any segmentation scheme that fits your project: geographic boundaries, project phases, user roles, etc.

Consistency
The same property can be used to control access across multiple Entities without managing separate “group” definitions. App users can be thought of as Entities, which also have properties and can be filtered, similarly to choice filters in forms.

Alignment with Central’s data model
Properties are already a familiar concept in other parts of the platform and can be extended for access control.

What’s next?

Our next step is to ship Phases 1 and 2 so you can start limiting Entities by ownership and reassigning owners. Phase 3 will build on that foundation by introducing Properties for App Users and Data Collectors, along with a rules editor for filtering Entities based on those properties.

We’d love to hear:

  • What kinds of properties you’d want to define for your users.

  • How you’d like the rules editor to work: text expressions, dropdowns, or a mix.

  • Any concerns about migrating from “group ownership” to “property-based access.”

We’re excited about the flexibility this approach will bring!

4 Likes