If you have any other suggestions I am welcoming them with open eyes and ears.
From a cursory glance this seems well designed. I can find my way around and figure out what is going on
1. Table and field names are clear and proper
2. Table design and data relationships looks well designed
3. Code is clear, variables understandable
4. Code is well organized and concise
5. Looks well designed so you can continue to add features
To make things easier for you, you may want to add to the forms so you can test them without having to go through the flow. In other words open from the navigation pane.
For example if the form uses open args and openargs are not passed I check for this case and do not throw an error. Might put a message "No Args passed.". This way it runs through remaining code and as an admin I can check the form without having to open some other forms to get to it..
Also check if Tempvars("SCM") exists before setting menu
Once I split a database I always have relink code.
The user opens the db and it checks that all tables are linked. If not prompts the user to use a file browser to locate the backend. This is very useful in development for working between a production BE and a development BE and being able to move them around. If not when you give the user an FE you may have to manually link locations. If you need that I can provide. If not how are you distributing and linking to the proper BE? Normally the path from your computer may not be the same as the User. Even if on the network.
Also how do you plan to distribute updates. You can search on here for a lot of updater code. Often the actual Front end is on the network and the user has a link to a batch file. Then it checks version to the version on the backend and if not the most current the new version is downloaded.