There are a lot of moving parts to controlling the interface for a project. How far you need to go is dependent on your user base. Are you trying to protect the app from accidents? That's pretty easy. Are you trying to protect the app from malicious damage? That is harder. Are you selling the app and want to protect your intellectual property? That is pretty nere impossible. If you are worried about data security, you should consider using SQL Server or some other RDBMS which provides strong support for this.
So, let's start with - how far do you need to go? You really don't want to spend a lot of time trying to apply security to things that don't need to be secured.
Since malicious damage is a fireable offence and probably criminal also, that is probably the least of your problems for internal applications. The most important thing to secure is the data. A large part of that is validating data to ensure that the user is prevented wherever possible from entering data that is invalid. For example, if you are entering the date of birth for an employee, it makes no sense for the date to be > today. It also makes no sense for the employee to be < 16 years old for most jobs in the US. Some jobs such as being a bartender require the employee to be >= the legal drinking age in your state. Therefore, it is just plain sloppy on your part to not bother to at least apply sanity checks to dates - all dates. 4/30/202 is a valid date as far as Access is concerned but it is also almost certainly a typo.
Take a look at the article written by
@isladogs regarding locking the FE. I've also included a link to a very simple switchboard and security. The Security can be used to control the options each user sees.
This is a custom switchboard. It expands on the Switchboard Items table to add four additional columns to define view/edit/add/delete security levels for switchboard items and forms/reports referenced by them. It includes tables to manage users and also to assign them security levels. The user...
www.access-programmers.co.uk
Make sure to go to the end so you get the latest version.
The .accdr extension tells Access to "pretend" to be the Runtime engine. The Runtime engine will not allow access to the navigation pane or any backstage area and it also hides most right click menus and all but limited ribbons. So, doing this will show you what the app would look like if your user's actually were to use the Runtime engine to run the app. You will know if you need to create custom menus or form options for printing, etc.
