This is also the time to talk about version control.
If after looking at the problem in depth, you decide that it needs to be a unified database (i.e. single BE, copies of a single FE), then you are looking at some versioning and other architectural methods to keep things going.
If all you were to do is to change features of the FE file, you could look up the articles here on the topic of "auto-update front-end" and other variants of that concept. But if you have the auto-update feature set up, you would just update the "master" copy of the FE file and let users download the new copy when they launched the script that has been published in this forum for that purpose.
When you are talking about a BE update, however, you want to do something a bit more thorough. In this case, if you DON'T have an auto-updater, you have a serious problem in that invariably, someone will try to run the wrong version of the FE against the new BE. The way I usually stopped this is I had a table that was NEVER actually written by any queries. It was my "this is the current version of everything" table, and I could look up the version info for the BE file.
In the FE file, I had a second version number that could be compared to the BE's version number. I had an opening form that checked versions and popped up a message with a nasty-gram in it if the version mismatch was about to occur.
The second part of your problem is split audience functionality. I don't know what you want to do (and to a minor extent, don't care), but this is how I approached it. I had a table of users in the BE and a complex opening form that was my dispatcher, control panel, whatever you wish to call it. The form's .OnOpen event would get information about the user and look up the username in the table. No such user? Go away (and you can Cancel an Open event, so it is a neat-and-tidy closure.) As an aside, this is also where I checked for version incompatibility, so I could again take advantage of the .OnOpen's ability to accept a Cancel.
If the Open event let you through, the .OnLoad routine of that form knew who you were and what role you play in the scheme of things because the .OnOpen routine looked that up and left behind the info where all other forms could see it - in a General Module dedicated to security issues. Everything I needed to keep, I left in Public Variables in the General Module which meant they were persistent. (There are other ways to skin that cat - that was the one I chose.)
The control panel's buttons were enabled or disabled in the .OnLoad routine according to who was using the database. So if you had accountants and auditors, some would see one set of buttons; some would see another set. Maintainers would see everything.
Obviously, if Pat's comments about separation of data make sense to you, then my methods would not be important.
Now, there IS a third viewpoint... If you really wanted two disparate and unrelated BE files to work from the same FE file, you can. I believe the limit is 16 database files can be open at once. The FE is #1, the BE is #2. You have room to open 14 more databases. The idea of determining roles at run-time doesn't prevent you from having a third (BE) file linked in to the common FE. You just can't have persistent relationships between data split between the two files. HOWEVER, there IS such a thing as having a "temporary" relationship between two tables as long as they are both visible. You implement this in the query design window in the area above the grid at the bottom. You would do this, not for a permanent relationship, but only for a temporary one that only applies to a given query.
