Is it possible to set all users to have the passwordChangeRequired status set to true by default, so they are forced to reset their password upon their first login? Additionally, can we set a default password format as company{username}? For example, a user with the username 1234 would have the default password company1234.

Our FusionAuth instance only lists 11 Lambdas by default, and JWT Populate is not one of them. How can we create a JWT Populate Lambda?

Does FusionAuth provide an API to import roles for an application?

We are using the /api/user/forgot-password API for password resets, with sendForgotPasswordEmail set to false since we send our own email. However, users are now receiving two emails: our custom email and a password reset email from FusionAuth using our template. This issue occurs only in our pre-live and production environments, not in the local Dockerized version. What could be causing this?

You can manage both flows within a single tenant. Typically, you’d configure separate applications, one for the Admin portal tied to your AD/Entra ID provider, and another for your client-facing site using FusionAuth. You can then use login hints or managed domains to direct users to the correct Identity Provider (IdP).

Identity Provider Hints
Managed Domains

We’d like to configure FusionAuth so that our Admin portal authenticates against Active Directory/Microsoft Entra ID, while our client-facing site uses FusionAuth for authentication. Does this setup make sense, and should we use separate tenants for this, or can both flows be managed within a single tenant?

Yes, you can create a user without SMTP configured. In the Admin UI, disable the Send Setup Password option and set the password manually during user creation. If you’re using the API, set "sendSetPasswordEmail": false and include a "password" field in the user object.

Users API

Can I create a user in a tenant if SMTP hasn’t been configured? I want to set up an account, but the user isn’t receiving emails (likely because SMTP isn’t set up). Is there a way to manually assign a password so they can log in?

During an upgrade, FusionAuth monitors your deployment, and if it becomes unresponsive for more than five minutes, the on-call engineer is alerted. A snapshot of the database is taken before the upgrade, so a rollback is possible, though it is manual and would result in data loss from the time of the upgrade to the rollback. Rollbacks are very rare and have only happened once in the past four years.

You can safely upgrade directly to 1.59, and many customers do skip versions. The upgrade process is straightforward: once started, the deployment status changes to Upgrading and returns to Active when complete. For production instances, downtime is minimal (typically seconds, if at all) because multi-node deployments use rolling upgrades. Most upgrades take under 20 minutes, though in rare cases they can take up to an hour.

FusionAuth never forces you to upgrade, but if you are running a very old version (1–2 years behind) and encounter issues, support may request that you upgrade before troubleshooting.

Upgrading a Deployment

We’re considering upgrading from FusionAuth 1.54 to 1.59 and want to ensure the process is smooth and safe for our clients. Could you clarify:

• What monitoring protocols are in place during the upgrade?
• Is there an automatic rollback if something goes wrong?
• Should we upgrade directly to 1.59 or go version by version?
• Will there be downtime during the upgrade?
• What does the upgrade process look like for us?
• Will older versions eventually become unsupported, requiring an upgrade?

Good question. I believe this is due to how we implemented our PATCH calls. If you are making a straight API call, you can change the Content-Type header to application/merge-patch+json which will instead overwrite the existing array with whatever you have provided. That's the most straightforward way to replace array values. There are other methods detailed in the doc below but those involve removing values one by one instead of just overwriting them. The downside here is that I don't believe Client Libraries usually support the merge-patch header.

• https://fusionauth.io/docs/apis/#the-patch-http-method

The UserData of our users contains an array which is creating a problem for us using PATCH. When PATCH is used to refresh the user it always results in an array append. It appears that one option is to perform a GET request, modify the array, and then execute a PUT request. That's multiple steps, and thus more opportunities for something to go wrong. Can the array values be replaced with a PATCH rather than adding to the array?

If you believe that you have discovered a bug or issue with FusionAuth, please log an issue below.

• https://github.com/FusionAuth/fusionauth-issues/issues/new/choose

To note, you will likely want to be listening to the registration.update webhook for changes to the registration object prompted by additional fields the user needs to have completed based on what is a required field for self service registration.

In the case of a user entering all these fields "manually" (as part of a registration form) we will create the user and the registration at the same time (thus transmitting all information, including all required registration fields, as part of the user.create and registration.create events).

However, in the case of a social login, the user and registration will be created after the IdP provider returns information via the user.create and registration.create events. Additional registration will be asked of the user as part of the complete registration process (if there are additional required fields) and that additional information will be transmitted as part of the registration.update event.

• https://fusionauth.io/docs/extend/events-and-webhooks/events/user-registration-update

My registration form includes custom fields. The values are correctly sent to our backend with the user-create-complete event. Unfortunately, this does not apply to users who register with social login. At this point, the event is dispatched without the supplementary custom content, as it occurs immediately after the social login and before the user is prompted to provide additional registration details. Consequently, I anticipated a user.update.complete event to occur shortly after the 'empty' user.create.complete event, but it did not happen. Please provide guidance on how to troubleshoot this issue.