How can I create and relate a Parent Company and a Subsidiary Company

So I would use my current "Companies" table for my Parent Companies.  I would create a "Subsidiary Companies" table and move the Subsidiary Companies to that table.  Then I would need to create a relationship between those two tables with "Companies" can have many "Subsidiary Companies."  I would also need to create a relationship where "Subsidiary Companies." can have many "Contacts" like I have for "Companies" can have many "Contacts" already.  Is that correct?  Is there anything else I left out?  On the "Companies" Table I can have a field to pull related "Subsidiary Companies" (Subsidiary) and on the "Subsidiary Companies" table I can have a field to pull related "Companies" (Parent) ?  For the existing contacts how can I have them be connected to a Parent Company and a Subsidiary?  Do I need a new field?

Yes that is right, it requires you to go through and relate your Parent Companies and Subsidiary Companies but ideally long term it will be neater and help keep your data clear. Then once you relate Subsidiary Company and Contacts you have 2 choices. You can either create and relate Contacts to the specific Subsidiary Company via the Related Subsidiary Company. Also for any contacts that are related to the Parent you might also want to view you can create a field that is the Report link field in Subsidiary Company.

A Report link displays records on a Form based on matching a field in one table to another, and once your data is filled in your Subsidiary Company and your Contacts table will have one very solid field in common, they will both have a Related Parent Company field with the same value. So you can set the report link to match Related Parent Company in Subsidiary Company to the Related Parent Company field from Contacts. This way you will have the report of the contacts specifically related to this Subsidiary Company and a list of the contacts that were related to the the Parent Company. It will allow you to more easily differentiate the two. It just takes a bit more work in the beginning to get all lined up. Then in the future you can either chose to add a contact who is just for one of your Parent Company's or a contact who is related to the Subsidiary Company. I have linked below a little video that shows what a set up like that might look like in an App

https://www.screencast.com/t/pcc3oUACPit

When I view the "Parent Company" on the Subsidiary table it is showing an ID# instead of the Name.  When I edit it shows the name, how do I make it show the name when viewing?  Sorry for asking things that should be simple._

One thing I didn't think about is "Opportunities" Table.  Sometimes an opportunity will be related the the Parent Company and sometimes the Subsidiary Company.  I guess if I copy the "Companies" Table and rename the copy to "Subsidiaries" table it would retain all the relationships created?  Then I can just edit the data based on which Table it is in?

I would probably relate Opportunities to both Parent Company and Subsidiary company tables - meaning Opportunities would become a child table to both Parent and Subsidiary tables. Then, if I want to have a master record of all Parent company AND Subsidiary company opportunities, I'd pull through theOpportunities from the Subsidiary to the Parent company table with summary fields or embedded reports.

I'm better at drawing out the relationship than typing it out but I'd describe it exactly as Evan depicted in his initial response to you, except replace Contacts with Opportunities. Hope that makes sense. 

Hi Mark,

I would agree with Anna that you could replicate this build to share Opportunities as well. This way a Parent company can have Opportunities and a Subsidiary could have their own opportunities. 

That is another way of doing it. From a technical standpoint creating a self referencing table causes some options to no longer be available such as copy master detail buttons. Self referencing tables disable this function and require an entire re-architecture in the future if that is something that becomes needed or requires a custom scripted button.

From an experience standpoint, being in a Care role before this I've just seen a number of customers who caused themselves a great deal of heart ache trying to navigate a self referencing table when it comes to reporting and keeping the flow of their information clean and organized. Self-referencing tables are functional but I usually prefer to break things up into distinct tables to leverage that separation as a tool. Also long term it helps to keep the tables from individually growing too large as the data is naturally broken up. 

Thanks for the reply!