Unfortunately, lambdas won't help here. FusionAuth never exposes the password anywhere lambda code can access it, so you can't write a lambda that validates complexity.

You do have several other options, each with tradeoffs:

Low complexity for everyone, with MFA for franchise managers. Configure the tenant with low complexity rules and require MFA for the franchise manager group using the MFA lambda. The MFA lambda can be combined with most of the other options below.

Low complexity for everyone, with an IdP for franchise managers. Add an identity provider pointing to a different FusionAuth instance/tenant or a corporate directory, and have franchise managers authenticate there.

The FusionAuth instance can have more complex password requirements. Add a Login Validation lambda that denies login for users in the franchise manager group unless they authenticated through that IdP. Modify the theme to hide the IdP button on the normal login page. Pass an idp_hint on the authorization URL for everyone in the franchise manager group.

Passwordless for restaurant staff. Let restaurant staff log in without a password and set higher complexity rules at the tenant level for everyone else.

Two tenants with separate applications. Create tenant A (low complexity) and tenant B (high complexity). Have the restaurant staff application use tenant A's ID and the franchise manager application use tenant B's ID. You could also use a universal application to represent the application.

Two tenants with a connector. Again, tenant A is low complexity and tenant B is high complexity.

Set up a connector from tenant B to tenant A, with MFA lambda rules in tenant B for franchise managers. Configure the connector to not migrate users. Have all users log in to the application in tenant B, which checks tenant A for restaurant staff.

All of these will work, but they have tradeoffs. Some may increase your MAU count, and some may add latency.

Why not per-application password rules?

As an aside, I don't expect FusionAuth to ever support different password rules per application, because it would lead to confusing user experiences:

If the staff app requires 10 characters and the manager app requires 15, and a user registers in the staff app, what happens if/when they log in to the manager app? Do we deny the login? Force a password change? If the staff app requires 10 to 20 characters and the manager app requires 25 to 35, no single password can satisfy both. Would a user have to change their password every time they switch between the two apps? Can you migrate users between applications?

A couple of things:

https://fusionauth.io/docs/v1/tech/troubleshooting/#troubleshooting-email has troubleshooting tips worth checking out.

The UI copy doesn't copy the SMTP password, so double check that as well.

Yes.

The only thing you can't create via the API is another API key. You can track that functionality on this issue.

See the tenant documentation for more.

Tenants are separated logically, with users, identity providers, and applications all separate.

If you need physical or geographic separation (for instance, to host users in tenant A in the USA and users in tenant B in Germany, you can do this by running two instances of FusionAuth. You can keep system wide configuration in sync using scripts with the client library.

Yes. You can use the tenant API or any of the client libraries to created, read, update and delete tenants and all their configuration.

Sorry, that functionality isn't available in the UI.

No hard limits, we have some clients running somewhere between 5-10k.

If you encounter any performance degradation, you can open a GitHub issue and we will take a look. We do have some work in plan to improve the UI for this type of scale.

User ids need to be globally unique. You can either provide your own unique uuid or you can let FusionAuth provide them for you. But these values are not tenant scoped.