How to force the user to create an organization?
In my system, every user must have an organization. There will always be only one. I want the user to be required to create the organization right after being created. And whenever they log in, that organization should already be set as the user's organization.
11 Replies
Hey @DanielGoncalves ,
I think what you’re looking for is to use databaseHooks in your Better Auth setup. Right after a user is created, you can automatically create a default organization for them.
https://www.better-auth.com/docs/concepts/database#database-hooks
Also, even if each user can only own one organization, they can still be members of other people’s organizations. (I’m assuming that’s why you still want to use the organization plugin — otherwise, you probably wouldn’t need it at all.)
So in your session logic, it makes sense to default the activeOrganizationId to the one they own.
Here’s a full example of how your Better Auth config could look:
Hi @Ricardo. First of all, thank you very much. I may have misunderstood how this plugin works. Let me explain my idea. My system will manage churches, so when a user creates an account, they will set up their church, and everything they do will be related to that church. That's why I thought about setting up churches as Organizations, and each admin will always access the same church they created when they signed up. Wouldn't this be a valid case for using organizations?
I'd say organizations would be overkill if you dont plan on having multiple members as part of church. organizations are good for multi tenancy apps. Having multiple members, sending invitations, having teams, permissions etc. although it would suit of you just want a church to have multiple members without permissions etc. If you want a user to belong to one church only your probably better off to just have a churches table with a church id on the user.
I think @Kevin did a great job explaining what organizations are and the benefits of using them. I agree that using the organization plugin might seem like overkill in this case. However, when I build a system, I like to think ahead.
What I’m about to say really depends on your product and how you envision it scaling. It’s hard to give specific advice without context, but imagine a user who currently runs a church and makes posts about it. In the future, that same user might want to have an editor as a team member posting on their behalf.
Preparing your system for that possibility is one of the smartest things you can do. Otherwise, retrofitting your app later to support multiple users in a church, each with different roles, will be a painful and complex task.
Thank you for your suggestion, @Ricardo . One issue I'm running into is that if I want to use a user.create.after hook, how can I access the desired organization name or slug for the user? I see you're using a default org name now, but I'd like to be able to pass a value. Can't ascertain how to do this besides adding a orgName as additionalField on the user. Downside of that is that this is its sole purpose and it would clutter the db schema unnecessarily.
That's an amazing question. I would like to know how to do it, too @Budi. Think would be great if better auth had to support to pass extra data that we could grab in the hooks...
I think the correct way to do this would be to add middleware that injects organization slug and your others things into the sign up path context, then accessing it from the ctx object. That way you avoid adding a collumn to your user table
So add a before hook middlewware to inject it into context for sign-up route, and then access ctx in your after hook?
You would also want to validate in the before hook that the organization slug isnt taken also so it returns a Bad request if the slug is already taken that way you dont end up with cases where user was created but the after hook failed to create the organization
That's a good call @Slip . For now @Budi if u really need this done, I would use the metadata field in the user schema, to pass some extra things. In my case metadata field is just a Json field, not really typed, so I could easily use that for those particular things, and when accounts has been created, i would remove it from there. In this case the noise is in a more controlled environment, without having to add trash to the user schema
Thank you for your suggestion.
How would the before hook get access to the organizationName? How can I make that accessible if I don't put that on the user schema?
And thanks for your suggestion too @Ricardo wrt. metadata. If it needs to be on the user schema, then indeed, metadata.jsonb would be a good option.
I am assuming you have some sort of frontend form that the user selects their org name when they are creating their account? then you pass it in the req body to the sign up route, and the before hook on that route can catch that and add it to context which should* be accessible in your after hook, I haven't done exactly that for anything but done similar
The image is from the hooks docs but it shows how you can add to the request context

That makes sense. So I limit the hook to only apply to a particular route, then enhance the returned context.
Thanks, will give this a swing!
I've tried this but unfortunately this breaks the entire signup flow. I cannot seem to be able to modify the returned context in the middleware hook.