More granular control over organization creation limits
Administrators can now more easily control how many organizations their users are allowed to create, providing extra controls for your B2B applications.
Configure a default setting for all users via API or from the Clerk Dashboard, and then customize the limit on a per-user basis (also via the Backend API or in a specific User detail view in the Clerk Dashboard)
For some applications, this unlocks the ability to restrict org creation initially until a user has taken additional actions - like signing up for a paid plan. You simply set the defaults and Clerk keeps track of the creation and deletion of organizations.
With our latest release, you can now add custom menu items to <UserButton /> component.
UserButton Customization
The <UserButton /> component now supports the following customizations:
Custom Links: Add external links to the menu using the <UserButton.Link /> component.
Custom Actions: Define custom actions that can trigger specific behaviors within your app using the <UserButton.Action /> component. This includes implementing custom logic with onClick handlers or opening the user profile modal to a specific page.
Here is an example of how to use our new React API for <UserButton /> customization:
<UserButton> <UserButton.MenuItems> <UserButton.Linklabel="Terms"labelIcon={<Icon />} href="/terms" /> <UserButton.Actionlabel="Help"labelIcon={<Icon />} open="help" /> {/* Navigate to `/help` page when UserProfile opens as a modal. (Requires a custom page to have been set in `/help`) */} <UserButton.Actionlabel="manageAccount" /> <UserButton.Actionlabel="Chat Modal"labelIcon={<Icon />} onClick={() =>setOpenChat(true)} /> </UserButton.MenuItems></UserButton>
For more information and implementation instructions, please refer to our documentation for <UserButton />.
It is now possible to set an active organization by URL slug, making it easier to use the URL as the source of truth for the active organization.
For applications that include the organization slug in their URL path, when managing the Clerk active organization, it is common to have an organization slug handy from the URL, but not necessarily an organization ID.
Now, it's possible to call setActive with an organization slug. This saves an extra call to fetch the organization ID, improving performance and reducing complexity.
The example below creates a component that uses The Next.js useParams() hook to get the organization slug from the URL, and then the setActive method to set that organization as active.
'use client'import { useEffect } from'react'import { useParams } from'next/navigation'import { useAuth, useOrganizationList } from'@clerk/nextjs'exportfunctionSyncActiveOrganizationFromURLToSession() {const { setActive,isLoaded } =useOrganizationList()// Get the organization slug from the sessionconst { orgSlug } =useAuth()// Get the organization slug from the URL// e.g. https://example.com/orgSlug/<your-org-slug>const { orgSlug: urlOrgSlug } =useParams() as { orgSlug:string }useEffect(() => {if (!isLoaded) return// If the org slug in the URL is not the same as the org slug in the session (the active organization),// set the active organization to be the org from the URL.if (urlOrgSlug !== orgSlug) {voidsetActive({ organization: urlOrgSlug }) } }, [orgSlug, isLoaded, setActive, urlOrgSlug])returnnull}
Seamlessly migrate AWS Cognito user passwords into Clerk
We’re excited to share with you the release of our Cognito password migrator!
Existing AWS Cognito customers can now migrate their users into Clerk, and their users
will be able to sign in to Clerk with their prior cognito passwords — No password reset flow required.
Visit our guide to learn more about how to use the Cognito password migrator.
Clerk's development instances are great for getting started with Clerk, making local development smooth and simple, and testing out features. However, we have seen many users go to production using their development instance by accident - your app looks exactly the same, and works similarly enough that most wouldn't notice the difference. But if this does happen, it turns into a substantial issue.
Development instances have a more relaxed security posture, are not indexed by search engines, use shared OAuth credentials for social providers by default, and lack custom domain support. In addition, development instances are capped at 100 users, 20 SMS messages, and have "development" prefixes on SMS and email messages, which quickly becomes a large problem if accidentally taken to production. Especially so if the user or SMS limits are hit, which can stop your app from being able to sign up or log in users - certainly not something you want to happen in production 😰. And on top of that, you then need to go through a process of migrating users from your development to your production instance to fix it, which can be challenging and time consuming.
In order to combat this common issue, we made some modifications to the design Clerk's UI components in a specific effort to make it more clear that you're using a development instance. Our hope is that, with these changes, nodoby ends up taking a development instance to production by accident anymore. You can see an example of the change on the <SignIn> component here:
If you need to deactivate this UI change temporarily to simulate how components will look in production, you can do so by adding the unsafe_disableDevelopmentModeWarnings layout appearance prop to <ClerkProvider> as such:
It should be noted that this UI change initially will only apply to newly created Clerk applications. If you have an existing application, you won't see this UI change. We will be rolling out a way for existing applications to enable this feature in the coming weeks.
