I'm trying to create multi user logins in Access

[Jonk7273]

God bless you if you do I would really appreciate it!!! Owe mass quantities of pints if you do!!

[Jonk7273]

Would very much like it if you helped me put something together...is there any way you can help me with alerts and email alerts as well?

[Micron]

OK, but let's get the login part done first. What follows is not the most elegant but should suffice for your needs and the price is right.
Would surprise me if there are no critics. Keep in mind that my version is 2007, so maybe some things I could do different if I were using 2013.

1) Create a backup copy of what you have for safe-keeping. I'm assuming your db has been split into front end/back end (FE/BE) parts. If not, don't do anything else until you've done that.
2) Then create the following:

(2) standard modules: (if you don't see Option Explicit at the top of your new modules - stop, Google how to turn it on, then start over).
mdlStartup; your startup routine could get robust going forward (some of mine have 15 or so steps to automatically run queries, output data, etc. during startup, so let's put this stuff on it's own). See attachment.
mdlCommonFunctions; things that could be re-used often should go in here. I have modified the declaration line for fosUserName (has to be at the top under Option Explicit) per instructions I found for 64 bit Office. See attachment.

tblUser [with these fields - data type - parameters ] (* = mandatory, others optional but advised. Hopefully, you will need them later as you develop expertise). You must advise me if there are any conflicts, such as I spec number when your data is not/can't be.

* LoginID - text - PK, no dupes (text character limit defaults to 255 - you can shorten)
* EmplNo (per the requirements of your original post) - long integer - no dupes.
Fname - text, Lname - text
Level - text (this one I would make a lookup field on tblLevels (see below). Usually I avoid lookup fields but have had no problems with this one. The intent is to limit functionality to users based on grouping (Admin, User, Supervisor, etc.). You will need this BEFORE you try to create a lookup on it in tblUser. Or you can go down the path of using a workgroup file.
Active - yes/no
LoggedIn - yes/no

SndReqEmail SndRgaEmail ContCntr Email
These you probably don't need. In my app, they identified who got a certain type of email if there were issues (Requisition, ReturnGoodsAuthorization, ContractorCount)
All were yes/no fields. For email functionality going forward, add a field for addresses: EmailAddress and use your own field names for flagging recipients.

tblLevels:
Level - text (values: Admin, User, or whatever)

Macro: AutoExec. Action - run code. Code - startup()

I presume you'll use a form to contain the values as was suggested (I think this is not the time to create a custom user object).
Since I use the other method, I might falter on this a bit.
Create a query qryGetUserInfo that gets all the fields from tblUser and in the criteria row for LoginId put fosUserName()
Create form frmLoggedIn based on that query. If you use a form wizard for ease and speed, it will use the field names as control names (not best) so rename them all. For name "LoginIDl" (assuming that is your tblUser field name) preface it with txt (txtLoginID) for text boxes. Level should come out as a combo (cmbLevel) if it is a lookup field.
Grab the text from the attachments and dump into the module of the same name. I did this instead of creating bas files since I want to avoid any conflicts with security at your end. There are some extra procedures that I thought might prove useful later, and you will find a shutdown procedure in mdlStartup (weird maybe, but why create a module just for shutting down?).
mdlCommonFunctions.txt

mdlStartup.txt
That should get you started.