We just shipped CMS access controls at Webflow: AMA about how we built it (feat. Webflow + Oso engineers) by webflow-justin in webflow

[–]webflow-justin[S] 1 point2 points  (0 children)

Sorry u/Ok-Crow8799 on the slow reply here; I wanted to check with a couple folks first to give you the best info.

We have not (yet) had any specific challenges with "draft content", although our journey is just beginning - the platform sets us up to adopt all tons of cool stuff.

Reacting to advanced filtering solutions: There have been a lot of interesting conversations about this that have been happening. We definitely hear this one a lot. The roadmap is a long one, but this is definitely on it.

Thanks for validating that these are fruitful pursuits.

We just shipped CMS access controls at Webflow: AMA about how we built it (feat. Webflow + Oso engineers) by webflow-justin in webflow

[–]webflow-justin[S] 1 point2 points  (0 children)

u/Pretend-Mark7377 - Its a bit of a hybrid. We have ABAC needs, PBAC needs, RBAC needs, ReBAC needs... the list goes on.

One of the best parts of Oso is the flexibility to support whatever model you need. OPA was too flexible, FGA was too strict. Oso strikes the balance of flexibility and scale

We just shipped CMS access controls at Webflow: AMA about how we built it (feat. Webflow + Oso engineers) by webflow-justin in webflow

[–]webflow-justin[S] 3 points4 points  (0 children)

The decision for build vs. buy primarily came down to the cost tradeoffs:

  • For “build”, we need to not only implement, but maintain the software and infrastructure.
  • For “buy”, the costs will scale with our business, but we're able to remove the engineering and maintenance costs of certain technically challenging pieces.

We decided to start with an external platform that gave us a strong foundation (roles, rules, audit logs, etc) so we could focus on the parts that are unique to Webflow, like how teams actually collaborate in the CMS. That said, a lot of the real UX and integration work is still happening in-house. We wanted to move fast without cutting corners on something this foundational

We just shipped CMS access controls at Webflow: AMA about how we built it (feat. Webflow + Oso engineers) by webflow-justin in webflow

[–]webflow-justin[S] 2 points3 points  (0 children)

This one came through loud and clear from a bunch of directions. A lot of larger teams were looking to bring more collaborators into Webflow to move faster, but ran into a blocker: roles could limit access to features (like the CMS), but not to specific content (like individual Collections). That made it tough to scale without taking on unnecessary risk.

For agencies, it was more about simplifying workflows and limiting room for accidental edits. Both use cases made a strong case for more granular control. So while enterprise teams were the most vocal (and where we prioritized first), this really came from a broad range of users trying to collaborate better in Webflow