The New Customer/User Account Schema
How customer/user management worked previously
Prior to GTMA IV, each portal customer account was bound to a single primary user account. That is, there was one user login account and it was associated to a single customer. Secondary users could be created for a customer, but these had to be unique and could not be duplicated across customer accounts.
This created some major issues for larger portals where the same user owned or managed several customer accounts. Given that the login email address had to be unique, portal admins were forced to create pseudo addresses in order to provide access to the user's other accounts. We used customer grouping to then link the primary user to the secondary accounts. A real pain to manage.
The new customer/user account schema
The new schema builds off of the customer grouping idea, but greatly improves and perfects it.
Customer and User accounts are completely separate entities
Customer and User accounts are completely separate entities and can exist completely independent of each other. For any customer, there can be multiple users with access to that customer. Any user can also have access to any customer (as long as an admin has assigned them access).
When enabling a new customer account, GTMA will suggest a user account - either one that exists, or it will propose creating one based on an existing email address known for the customer. Where no email exists, the staff user can create a new user and assign them during the customer enable process. Optionally, an invite email can be triggered to the user.
One exception - staff users. The one exception is that staff users can never be assigned to a customer account and an existing customer user can never become a staff user.