Clerk is an authentication provider for the most part, it concerns itself with telling you who the user is. Based on that your business logic should be able to determine what they are entitled to do.
They offer a Org/Role based RBAC but since you're doing something different I'd just scrap it entirely and roll your own authorization flow, they have a guide that'll help you get your own started here: https://clerk.com/docs/guides/secure/basic-rbac
Their recommended guide is to pretty much have your own RBAC using key value pairs they offer, which is IMO relatively lazy and most teams come up with this on their own anyway. I wish they offered something that is not prone to someone editing a JSON input manually on their website. You can do basic stuff with it, build tooling around it, but again the fundamental model of only user having a role on the org level has its limitations.
Can you share your evaluation process? I'm always curious how folks evaluate auth providers.
Did you do a spike? Full POC across a couple of solutions? Rely on a recommendation from a friend? Run through a quickstart and decide it worked and you had bigger problems to solve? Something else?
Also design wise, the main logo item (vortex looking thingy) is a tad bit complex, maybe think about a redesign focused on making it more simple/recognizable. The rotating dashes on the landing page hero are a good motif though, so I'd lean into that.
Also noticed that on this page: https://fusionauth.io/tech-papers/winter-2026-g2-fusionauth-... the form under "To get this tech paper complete the form below." doesn't load on Firefox with Enhanced Tracking Protection enabled. Disabling it causes the form to load though.
thankfully i'm familiar with better auth from a side project, but migrating SSO/SCIM sounds like it might be a bit of a pain