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.

We’re integrating FusionAuth with our system and want to verify users’ phone numbers during registration, but we’re not ready to enable two-factor authentication (2FA). Is there a recommended way to implement phone number verification via SMS during registration without enabling 2FA? Ideally, we’d like users to enter their phone number and verify it before completing the registration process.

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 cannot integrate Datadog directly into the cloud-hosted version of FusionAuth. The only relevant section in the documentation is "Use Datadog Agent on a Remote Host." This requires setting up Datadog to monitor FusionAuth using the Prometheus Metrics API endpoint. For monitoring failed 2FA rates, FusionAuth does not currently have built-in support. There is no webhook for failed MFA, but you can use the failed login webhook to monitor incorrect password attempts.

Retrieve system metrics using Prometheus
Use the Datadog Agent on a remote host
User login failed webhook

We are investigating what additional telemetry and data we can monitor and log to our monitoring systems. I found the self-hosted version supports integration with Datadog here: https://fusionauth.io/docs/operate/monitor/datadog

However, I am unclear what we can monitor on the cloud version since we are not managing the container or deployment side.

1. Can we integrate the cloud-hosted version into Datadog to monitor for performance issues or other issues that might impact end users? If so, are there any guides?

2. Can we monitor failed 2FA rates using a tool like this? Or are there recommended approaches for monitoring drop-off during 2FA enrollment and other login issues?

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?