@elliotdickison Thanks for the feedback.

I'd love to chat a bit more to understand the problem.

Will send you an email.

Because advanced themes are so customizable, they can be hard to upgrade. Here's some ways to make it easier.

• When you create a new theme, start from the default version. Commit it to git before you change anything.
• Use the FusionAuth CLI to download/upload your theme during development and CI/CD.
• When a new theme comes out, clone or pull the latest from the theme history repo.
• Run this command to see what has changed: git format-patch 1.61.0..1.64.1 --stdout > update-themes.patch (this shows the changes between 1.61.0 and 1.64.1; adjust as needed for your installed version and the target version).
• Go to your theme git repo and apply the changes: git am --3way update-themes.patch which will attempt to automatically merge the changes. If there are conflicts, you can resolve them manually and then run git am --continue.

You can also use a 3 way diffing tool like diff3 or kdiff3 to visualize the changes.

These upgrade notes also provide detailed human friendly instructions on the changes.

I am using advanced themes and wanted to know how to find out what had changed in the themed pages when a new release happens.

I've read the instructions here.

There are a couple different scenarios where a login record could have a blank application Id. Usually it is #1 or #2. It occurs in scenarios where the user can have a JWT/access token that does not have the application Id in it.

1. If a user is not registered for the Application they are logging into
2. FusionAuth makes a login record when a user is created since FA makes a JWT upon user creation
3. If you use the Login API, you can log in without an App ID because you don't have to provide an application on the API call.

We have a user who has logged in repeatedly, but the application is blank.

https://fusionauth.io/docs/apis/login#search-login-records doesn't mention anything about this.

What gives?

It's one thing to read about new features in the release notes and another to see them demo'd. If you're interested in what FusionAuth has been up to, come check it out tomorrow in our Q1 2026 edition of Shipped!

@batmysta Going to link to this issue.

@batmysta I know this is a bit of a "trick" answer, but the reality is the right answer depends on what exactly you want the user to have access for. I understand that the roles in FusionAuth may give more access than you may like (I.E. MFA is a tenant level settings, but there is no role just for MFA edit.), but there are some other options.

Again, depending on what you want to do and what version you are running, there is the idea of the Tenant Manager applicaiton. This will still not help you with MFA settings thought.

The other option is using the APIs. Since everything in The FusionAuth admin UI is API first, you could create your own application that would allow users you choose to edit them.

Hope this is useful.

@hvfa Apologies for being a bit AWOL. I hope for things to slow down and be able to take a look at this a little more closely next week.

I think the way I'd approach this is:

• import all users into FusionAuth

At cutover time:

• look at local database to see which password hashes had changed
• pull the user data from FusionAuth for each of these users
• delete the user
• re-import the user with the new password hash and the FusionAuth data, maintaining the same userId (if you provide the UUID, we'll use that)

I get that is an additional complexity, but hopefully that helps.