For a new user, you've definitely tackled an ambitious first project. You may want to invest in a good book on filemaker and/or some training tutorials to help you get up to speed.
Create a Database that will enable myself and others to data enter important information on a file (an online file system)
Shouldn't be a problem, you can even set up links that open the file when the user clicks the link.
Publish to the web to allow other individuals who have permission to view certain aspects of the files to do so
Web publishing adds a whole other layer of complexity to your task. Filemaker can be published to the web via Instant Web Publishing (IWP) and Custom Web Publishing (CWP). Both options require you to learn even more new skills and each option has its trade-offs. You might want to search this forum under IWP and CWP to learn more. There are also PDF documents on Filemaker's Download page that give you more info on each.
Allow specific user groups upload necessary documentation
Hmm, as in "upload a file"? I think that would require a plug in for this to work on a web published database. I could be wrong though as I'm still learing all the ins and outs of web publishing myself. It's simpler for LAN users that each have their own copy of filemaker to use to connect to your database.
Email the conversation Log/Status Update of the files to the people within that specific section
Filemaker certainly does emails, but this again raises the bar you have to clear. Sending email requires Filemaker to interact with a mail server and this has to be set up just right in order to work. You can search this forum under "email" and see threads where other users have worked with this feature.
Specific to the questions on your layout:
That <Missing Table> tag you show indicates that the table occurrence that the field originally used to reference a field can no longer be found. Perhaps you deleted it or it could be a reference to a table in another file that is not open or which filemaker cannot find to open.
You can certainly place fields from different tables on different tabs in your layout. Whether you should and exactly how to do this has a lot of possible answers depending on how you choose to design your tables and what you need to see happen here.
Keep this central thought in mind:
Each layout you create can refer directly to one and only one "box" in your relationship graph. (These boxes are called table occurrences). You can place fields from other such Table occurrences on your layout, but the relationships you define in the relationship graph will control which record in the other table will supply the data you see in the layout.
Another useful layout feature to learn about are "portals" this is a window that allows you to display a list of records from a related table on your layout. It's a major feature in filemaker that will solve a lot of problems for you when it is used correctly. Look it up in Filemaker's help system to learn more.
Thank you for the info!
I guess one of my main questions is this:
The databases do not share common information on everything. If I try to link the common information, it seems I have to do so for the whole database. So, for instance, Names, email addresses and account number are the only things that are commonly shared throughout all databases. Everything else is exclusive to its respective database.
So, do I need to have completely different databases, with no "relationships"? Or is there a way to just link the info I need to and still be able to use the other things?
Of course the tables (better term than "databases" for this discussion) don't "share common information on everything". All they need in common is the value in a single field such as a user's Account name or (better) ID number. If you do need to list information from another table and you simply want to list all the information in that other table, you can use the "X" operator instead of the default "=" operator. This relationship then matches all records in table 1 to all records in table 2 and this gives the layout enough information to display a list of all records in a related table, via a portal for example. And this portal can be placed on a tab in your tab control if that's what you want.
Suppose you have a very large pile of 3x5 cards and manila folders and one cardboard box spread out on your floor.
Trying to organize things, so you can find and display what you want, you take some multicolor strings and some multicolor labels.
You name a label "Pets", tape that label to the cardboard box, with a green string, and the other end of the string is taped to each folder and each 3x5 card with a small label with "Pets" on it.
When you lift the box (labeled "Pets") every folder and every 3x5 card will be lifted with it.
[all contents, every folder and every 3x5 card is connected to the cardboard box]
[[this means the database is called "Pets", AND each folder AND each 3x5 card has an ID field with "Pets" in the field]]
NOW, (this going to become combersome and confusing) you take a folder attach a yellow label (with "Dogs" on it) and yellow strings and attach each string to each 3x5 card with dog information with a yellow label with "Dogs" on it.
[the yellow string is a relationship, connecting the folder with the "Dogs" label to each 3x5 card with a "Dogs" label]
When you lift (examine) the manila folder with the Dogs label, the yellow strings will pull up all the 3x5 cards with a "Dogs" label.
There will still be a green string (relationship) to the cardboard box with "Pets" for a label. But we are only lifting the Dogs folder, so the Pets box is still on the floor.
There could be another folder, connected to the Dogs folder by a string that could be labeled "Small Dogs"
This seemed like such a good analogy, but the complexities quickly bog down the text explanation...
Any help with simplifying the text explanation would be welcome.