How We Built a Custom Permissions DSL at Figma | Figma Blog (opens in new tab)

Figma’s original permissions system—a large Ruby has_access? method in its monolith—became too complex, risky, and expensive to maintain. As collaboration features expanded, permission rules involving roles, links, hierarchies, organizations, billing, and deleted files caused bugs, delayed projects, and heavy database load. Figma responded by building a custom permissions DSL and cross-platform logic engine to make rules more modular, flexible, performant, and easier to debug.

Why Permissions Became Difficult

• Figma’s collaboration model requires detailed access rules for files and other resources.
• Access can come through:
  • Roles inherited from parent folders, teams, or organizations
  • Link-sharing settings
  • User roles and authorship levels
  • Passwords, expiration periods, and organization restrictions
• Originally, permissions lived in a Ruby monolith using ActiveRecord.
• A model-level has_access? method accepted a user and resource, performed database queries, and returned a Boolean.
• Product engineers had to call this method correctly from controllers.

Problems with the Original System

Complex Logic and Difficult Debugging

• has_access? methods grew into long functions with many optional parameters.
• Engineers were reluctant to modify them because mistakes could expose access to large numbers of files.
• All permission logic for a resource was intertwined, making it difficult to isolate or test individual rules.
• Debugging often required adding many print statements and understanding the entire permissions implementation.

Inflexible Hierarchical Permissions

• Permissions were nominally represented by hierarchical integer levels, such as edit access being higher than view access.
• Boolean flags introduced exceptions that undermined the hierarchy, including options such as:
  • ignore_link_access
  • org_candidate
  • ignore_archived_branch
• A user could have a higher access level but fail a lower-level check when a flag changed the behavior.
• These flags differed between resources, forcing engineers to remember numerous special cases.
• Figma needed granular, non-hierarchical permissions that could operate independently or define new permission hierarchies.

Excessive Database Load

• As Figma scaled, permission checks accounted for roughly 20% of database load.
• This created a serious scalability concern because database capacity had physical limits.
• Although the database team was pursuing vertical and horizontal sharding, Figma also needed to reduce and better control permission-related queries.

Building a Custom Permissions DSL

• Figma generally prefers adopting open-source or commercial solutions, but existing options did not adequately address its requirements.
• The company chose to build:
  • A domain-specific language for expressing permissions
  • A custom cross-platform logic engine
  • A migration plan for moving critical permission rules into the new system
• The intended result was a permissions system that improved developer ergonomics while increasing correctness and performance.

Figma’s experience shows that permissions can become a foundational scalability and reliability problem when implemented as one growing authorization function. A dedicated, composable DSL can provide clearer rules, more flexible access models, and better control over database usage.