There is a possibility that I may run an independent back-end app for clients to log into to enter podcast show and episode information. Sometimes I may log into this independent admin app on their behalf to update their podcast info.

Although not strictly needed, and not looking to build an outright "team" function, I do want a hook into possible future needs. I need a database table that can have a many-to-many relationship with personbydomains (aka "users").

So, I am seting up a database table to "pair" with my podcast admin users. I am calling this table "clients".

It seems that I should keep this table within my podcast packages, confined solely to podcast admin functions. Ah, indeed! But my instincts are to place this table in the main librarybackend package so that once used in an app its usage is universal within that app. Very much do not want to build "stovepipe" database tables, which was a Big Reason why I wanted to build a "starter" profiles database into my Software in the first place.

Although it seems that I should classify this "clients" database table as Authentication, I am deeming it a Profile table. This table serves no actual authentication function. Worse, it's purpose is rather amorphous. Hence its Profile categorization.