30% offEnding soon
FSD-013Frontend system design Premium

Design a Nested Checkbox Permissions Tree

Design an accessible permissions tree with honest tri-state derivation, partial loading, safe propagation, large-hierarchy rendering, and secure writes.

Intermediate 54 min read

Store permission facts and inheritance rules, not checkbox paint. Derive each row's checked, unchecked, or mixed presentation from a revisioned permission snapshot, and expose unknown descendant coverage instead of pretending that unloaded children do not exist.

A nested permissions editor looks like a tree of checkboxes. That surface hides two different hierarchies: the resource tree being displayed and the authorization policy that determines effective access. Bugs appear when the UI treats a visual parent checkbox as policy truth, or uses the currently mounted children as if they were the complete subtree.

Separate permission truth from row summaries

Keep resource nodes, child indexes, explicit grants, explicit denials, inheritance rules, and server aggregates in normalized records. Derive visible rows from expansion. Derive each row's checkbox summary from the permission snapshot and its known coverage.

For a complete group, none selected means unchecked, all selected means checked, and a mixture means mixed. Partial loading adds another dimension. A row can have a known checked summary and incomplete coverage. Display both facts. Do not overload one dash glyph to mean mixed values, unknown descendants, a pending save, and a disabled policy.

The public interview prompt

Design a reusable nested checkbox permissions tree for an enterprise administration console. Explain:

  • normalized resources, parent-child indexes, stable IDs, and visible-row flattening;
  • direct grants, inherited access, explicit denials, effective permissions, and policy precedence;
  • checked, unchecked, mixed, unknown, disabled, pending, and error presentations;
  • partial child loading, server aggregates, pagination, cache generations, and stale responses;
  • parent toggles, propagation scope, descendants created later, idempotency, revisions, and conflicts;
  • ARIA tree and checkbox semantics, arrow navigation, Space behavior, labels, and announcements;
  • large-tree virtualization, search, reveal, selection summaries, and performance budgets;
  • administrator authorization, audit logs, least privilege, rollback, testing, and rollout.

Assume one tenant can have a million resources and a subtree can change while an administrator is editing it. Most sessions expose fewer than 250 visible rows. Children and permission aggregates arrive in pages. These are interview assumptions, not product measurements. A general policy-language authoring environment is outside version one.

What the premium solution covers

The full solution defines permission facts and derived states, honest handling of incomplete coverage, inheritance and denial precedence, propagation contracts, revisioned bulk mutations, focus and expansion behavior, virtualized rendering, server authorization, auditability, conflict recovery, observability, tests, and an interview rubric.

Original media follows a partial subtree through a safe update, separates permission facts from row summaries, maps five presentation states, and opens the bulk-operation envelope. Two deterministic labs expose tri-state and propagation edge cases directly.

Premium solution

Continue with the complete system design

Unlock the architecture, state machine, API contracts, original diagrams, positioning model, accessibility decisions, performance budgets, testing plan, rollout strategy, scoring rubric, and interview walkthrough.

  • Detailed, beginner-friendly explanation
  • Production failure modes and trade-offs
  • Mobile-friendly architecture diagrams
  • Senior and staff-level interview signals
Unlock Premium

Frequently asked questions

Should a mixed parent permission be stored in the database?
Usually no. Mixed is a view summary derived from descendant permission outcomes. Store explicit grants, denials, inheritance rules, and operation metadata. Recompute the row summary from the relevant snapshot.
What should a parent show when some children are not loaded?
Show coverage separately from checkedness. A parent can be checked for all known children while still having unknown descendants. Do not present that as a fully checked subtree unless the server supplied a complete aggregate.
What happens when an administrator checks a parent?
The product contract must say whether it changes loaded descendants, the server snapshot of the entire subtree, or a durable inheritance rule that also affects future descendants. Send that scope explicitly instead of inferring it from the current DOM.
Can a native checkbox display the mixed state?
Yes. Set the input element's indeterminate property from JavaScript. It affects appearance only, so keep the actual checked value and submitted permission operation explicit.
Does disabling a permission in the UI secure the resource?
No. The server must authorize every read and write, deny by default, validate the administrator's current authority, and calculate effective access from trusted policy data. Client controls are usability aids.
How do you virtualize a large permissions tree?
Flatten the visible hierarchy, keep permission and aggregate state outside rows, mount a bounded window, and preserve the active item or move focus safely before unmounting it. Supply logical level and sibling metadata when the DOM is partial.