github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 07:18:56 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #685] [Feature Request] Set Default Active Organization in Backend #25702

New Issue
Closed
opened 2026-04-17 15:57:50 -05:00 by GiteaMirror · 9 comments
GiteaMirror commented 2026-04-17 15:57:50 -05:00
Owner
Copy Link

Originally created by @ayushsharma82 on GitHub (Nov 28, 2024).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/685

Originally assigned to: @Bekacru on GitHub.

Describe the solution you'd like

Currently, user can only set an active organization per session but we should be able to set a default active organization in backend/database. This way user will not have to select an active organization upon every new session. This reduces friction a bit and makes frontend a bit easier to handle as well.

Originally created by @ayushsharma82 on GitHub (Nov 28, 2024). Original GitHub issue: https://github.com/better-auth/better-auth/issues/685 Originally assigned to: @Bekacru on GitHub. **Describe the solution you'd like** Currently, user can only set an active organization per session but we should be able to set a default active organization in backend/database. This way user will not have to select an active organization upon every new session. This reduces friction a bit and makes frontend a bit easier to handle as well.
GiteaMirror added the lockedenhancement labels 2026-04-17 15:57:50 -05:00
GiteaMirror commented 2026-04-17 15:57:54 -05:00
Author
Owner
Copy Link

@ayushsharma82 commented on GitHub (Dec 2, 2024):

@Bekacru Appreciate the work around but this still requires some effort from the developer to store/persist active organization in some store or different table.

Is it possible to add it in the database schema of user or organization itself to auto inject active organization? I was hoping for methods by which we can store it in backend itself.

<!-- gh-comment-id:2511033962 --> @ayushsharma82 commented on GitHub (Dec 2, 2024): @Bekacru Appreciate the work around but this still requires some effort from the developer to store/persist active organization in some store or different table. Is it possible to add it in the database schema of user or organization itself to auto inject active organization? I was hoping for methods by which we can store it in backend itself.
GiteaMirror commented 2026-04-17 15:57:56 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Dec 2, 2024):

The concept of activeOrg in the session table is primarily a utility to track the active organization globally, especially if you enforce that only one organization can be active at a time. But, this is not the case for most applications, as users should typically be able to have multiple organizations or workspaces open simultaneously in different tabs.

When enforcing a single active organization, activeOrg can be used, and it is also useful for Better Auth's internal use cases. However, if you want to persist the active organization between sessions, this decision should be left to the application owner. It could default to the last active organization, a personal organization created by default, or any other logic determined by the application. This cannot be decided at the library layer.

<!-- gh-comment-id:2511108045 --> @Bekacru commented on GitHub (Dec 2, 2024): The concept of `activeOrg` in the session table is primarily a utility to track the active organization globally, especially if you enforce that only one organization can be active at a time. But, this is not the case for most applications, as users should typically be able to have multiple organizations or workspaces open simultaneously in different tabs. When enforcing a single active organization, `activeOrg` can be used, and it is also useful for Better Auth's internal use cases. However, if you want to persist the active organization between sessions, this decision should be left to the application owner. It could default to the last active organization, a personal organization created by default, or any other logic determined by the application. This cannot be decided at the library layer.
GiteaMirror commented 2026-04-17 15:57:56 -05:00
Author
Owner
Copy Link

@ayushsharma82 commented on GitHub (Dec 2, 2024):

However, if you want to persist the active organization between sessions, this decision should be left to the application owner. It could default to the last active organization, a personal organization created by default, or any other logic determined by the application. This cannot be decided at the library layer.

I have to respectfully disagree, I believe you are can hit both targets with one stone but it's up for you to evaluate. From my perspective, all it needs is a client.organization.setDefault function that takes organization Id or a null value.

For Example:
If we invoke setDefault with a organization Id, then the default organization gets saved in database and gets injected automatically upon new sessions. If we invoke it with null then it should clear the entry in DB and revert back to your existing logic of not setting any active organization on new sessions. This is pretty self explanatory to devs and works both ways.

<!-- gh-comment-id:2511152588 --> @ayushsharma82 commented on GitHub (Dec 2, 2024): > However, if you want to persist the active organization between sessions, this decision should be left to the application owner. It could default to the last active organization, a personal organization created by default, or any other logic determined by the application. This cannot be decided at the library layer. I have to respectfully disagree, I believe you are can hit both targets with one stone but it's up for you to evaluate. From my perspective, all it needs is a `client.organization.setDefault` function that takes organization Id or a `null` value. For Example: If we invoke setDefault with a organization Id, then the default organization gets saved in database and gets injected automatically upon new sessions. If we invoke it with `null` then it should clear the entry in DB and revert back to your existing logic of not setting any active organization on new sessions. This is pretty self explanatory to devs and works both ways.
GiteaMirror commented 2026-04-17 15:57:57 -05:00
Author
Owner
Copy Link

@ayushsharma82 commented on GitHub (Dec 2, 2024):

When enforcing a single active organization, activeOrg can be used

@Bekacru Maybe you understood it wrong? I'm only asking for a persisted organization Id which gets set when user signs in, (i.e. when a fresh session is created) after that he can change the organization freely according to his will for the rest of the session.

<!-- gh-comment-id:2511190197 --> @ayushsharma82 commented on GitHub (Dec 2, 2024): > When enforcing a single active organization, activeOrg can be used @Bekacru Maybe you understood it wrong? I'm only asking for a persisted organization Id which gets set when user signs in, (i.e. when a fresh session is created) after that he can change the organization freely according to his will for the rest of the session.
GiteaMirror commented 2026-04-17 15:57:58 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Dec 2, 2024):

This would require the plugin to add a defaultOrgId field (or similar) to the user table by default. But, this field may not have any use case unless you’re actively using this feature, and I don't think it’s a common use case. You might prefer to use the last active organization ID as the default when the user logs in. Or, you might not want any organization attached by default and simply treat the absence of an organization as the user being in their personal organization.

And as much as possible, we try to avoid bloating the database with unnecessary fields that users may not use. Since Better Auth operates within your app’s db, we try to include only essential fields.

<!-- gh-comment-id:2511202729 --> @Bekacru commented on GitHub (Dec 2, 2024): This would require the plugin to add a `defaultOrgId` field (or similar) to the user table by default. But, this field may not have any use case unless you’re actively using this feature, and I don't think it’s a common use case. You might prefer to use the last active organization ID as the default when the user logs in. Or, you might not want any organization attached by default and simply treat the absence of an organization as the user being in their personal organization. And as much as possible, we try to avoid bloating the database with unnecessary fields that users may not use. Since Better Auth operates within your app’s db, we try to include only essential fields.
GiteaMirror commented 2026-04-17 15:57:58 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Dec 2, 2024):

This could be its own plugin or an implementation layer on the application side. It should be straightforward to set up.

<!-- gh-comment-id:2511204195 --> @Bekacru commented on GitHub (Dec 2, 2024): This could be its own plugin or an implementation layer on the application side. It should be straightforward to set up.
GiteaMirror commented 2026-04-17 15:58:00 -05:00
Author
Owner
Copy Link

@focux commented on GitHub (Dec 4, 2024):

My use case is to select the last active org, is there a hook to listen to active organization changes so we can implement this logic?

Edit.
I just found out about the session after update hook and I think that could work for my use case.

<!-- gh-comment-id:2516134929 --> @focux commented on GitHub (Dec 4, 2024): My use case is to select the last active org, is there a hook to listen to active organization changes so we can implement this logic? Edit. I just found out about the session after update hook and I think that could work for my use case.
GiteaMirror commented 2026-04-17 15:58:02 -05:00
Author
Owner
Copy Link

@nicolaslopezj commented on GitHub (May 21, 2025):

You can do this to maintain the active org id after logout

databaseHooks: {
  session: {
    create: {
      async before(session) {
        const activeOrganizationId = await usersRepo.getUserDefaultOrganizationId(session.userId)
        return {
          data: {
            ...session,
            activeOrganizationId,
          },
        }
      },
    },
    update: {
      async after(session) {
        await usersRepo.setUserDefaultOrganization(
          session.userId,
          (session as any).activeOrganizationId,
        )
      },
    },
  },
},
<!-- gh-comment-id:2898771189 --> @nicolaslopezj commented on GitHub (May 21, 2025): You can do this to maintain the active org id after logout ```ts databaseHooks: { session: { create: { async before(session) { const activeOrganizationId = await usersRepo.getUserDefaultOrganizationId(session.userId) return { data: { ...session, activeOrganizationId, }, } }, }, update: { async after(session) { await usersRepo.setUserDefaultOrganization( session.userId, (session as any).activeOrganizationId, ) }, }, }, }, ```
GiteaMirror commented 2026-04-17 15:58:02 -05:00
Author
Owner
Copy Link

@bismitpanda commented on GitHub (Jul 16, 2025):

I may be very late to this, but you can do this with additionalFields in the auth config. Add a field defaultOrganizationId which is required and initially "". Then using database hooks, after a user signs up and you create the organization, update the user with the created organization's id.

<!-- gh-comment-id:3080757593 --> @bismitpanda commented on GitHub (Jul 16, 2025): I may be **very** late to this, but you can do this with `additionalFields` in the auth config. Add a field `defaultOrganizationId` which is required and initially `""`. Then using database hooks, after a user signs up and you create the organization, update the user with the created organization's id.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label enhancement locked
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#25702
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?