Auto-assign customers to usergroups based on the state or region on their address. Drives state-bounded price tiers, shipping cohorts, and content visibility.
State Usergroup Rules map a state or region code on the customer's address (CA, NY, TX, ...) to a usergroup. When a customer's address is...
Open /admin/usergroups. Create the groups you want the rules to assign — e.g. customers-ca, customers-northeast, customers-tx. The rule n...
State Usergroup Rules is a small primitive — one row maps a state to a usergroup. The interesting question is what you wire on the receiv...
Step-by-step click path from a fresh tenant to a working rule. Assumes you already enabled the module under /admin/modules → State Usergr...
Before relying on a rule on a live tenant, dry-run it against a test customer. The platform doesn't ship a "preview which usergroups woul...
The rule fires silently. The customer never sees a "you have been added to usergroup X" message. The visible effects are second-order — w...
The trigger is users.Service.ApplyStateUsergroups(ctx, userID, stateCode). It is called with the address's state value after CreateAddres...
State Usergroup Rules has no module-specific privilege. Its admin API routes sit in the same privilege group as vendor management, so acc...
The module is small, so most surprises come from misunderstandings about WHEN the rule fires and WHAT it does (and does not) clean up.
No. The rule fires forward only — on address create/update. Existing addresses are not retroactively scanned. To back-fill, either re-sav...
The module has no configschema fields. All operational state lives in the stateusergrouprules table.
Walk through the gates: