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?

FusionAuth uses standard SMTP for all email connections. As long as Proofpoint Cloud supports a standard SMTP connection where FusionAuth sends transactional emails, initiates a handshake, and completes delivery, the integration will work. You can reference our documentation for details on configuring SMTP with common providers:

Configure Email

Is Proofpoint Cloud supported for SMTP configuration in FusionAuth, or is there anything special needed to make it work?

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?