Very interesting question.  I hope you get many replies.

TLDR: My thought is no, there isn't any hard and fast "rule". Do what works for you, but remember the K.I.S.S.* principal.

Example:  Richard shows how to make a button to open the contacts for a customer then, later on, adds that as a subform to the main record.  Nothing wrong with either method.  Both work perfectly fine but in my opinion the later is preferable simply because it saves you from having to open another form.

You are the traffic cop as the developer.  You get to direct the flow and navigation to display and, more importantly, obtain information for later use in an efficient manner.  I believe in simplicity first.  I've seen some forms with so much crap on them you can't easily take in all of the information being presented.  I've also seen cases where it would be very possible to miss important data because you had to drill down three layers.

Another perfect (personal) example.  I once spent hours and hours developing this big, complex report.  It was broken into sections and subsections.  Tons of detail.  I was so proud of my accomplishment.  Then my bubble burst.  My boss said, "Oh I never use any of that.  I just go directly to the last page.  I only wanted to know what our sales were yesterday."


*Keep It Simple for the Stupid

Thanks, Scotty, this such a cogent and thorough answer. Experience is the best guide. I can see that more confidential data might best be walled off to the casual user by forcing an action on thr calling Form, like a Command Button press (with password, or qualifying credentials) to expose on a separate Form but the alternative type of relational data -- particularly that with a one-to-many relation -- is treated in a way that accommodates the true purpose of the Form: to display Table data were required. I have a couple of noncritical, practice db's which I use to try out things I've learned to both reinforce and explore technique. I think it best for me to see the various at work there over the next few months. It's often a case of doing it one way because the other way stinks. Thanks.

A subform can link to its parent form via master and child fields.  In VBA, a subform can also refer to its parent form with the "Parent" object:

     s = Parent.TextBox1     ' Get parent form's textbox value

These are two of the unique features of subforms that aren't available if the forms are separated.

Kevin while the opening of a form via a button, you can still limit the records using the where condition on opening the form from the current record / form.

It's natural to have the parent and child together, at least that's what the user would expect.  If the underlying tables are also related as parent and child, then the forms should be done the same way.  If the two forms are separate, that is the user's cue to think that they are unrelated.

I disagree.  I can envision situations that I might not want the general user to have certain information such as SSN, Credit Card info, Orders and order details, many things where opening a different form is advantageous.
In other scenarios such as the contact info mentioned AND it makes sense to have it in the form great drop in a SubForm.

What I'm saying is there is no hard fast "RULE" that dictates how it has to be done.  That is the beauty of Access.  As the developer we get to make up the rules as we go and as our needs change.

Thank you, both Scott and Kevin. It was its time, for subForm usage to be explored and more thoroughly understood by me. You don't know if the pond is frozen until you step out onto an area away from the obvious safety of the shoreline. I see the key here as "what can NOT be done readily if you go the separate form route?" I'm working with subForms a lot now in my practice projects. You don't really know a brave until you've walked "two moons in his moccasins" as is said. Thanks again.

Hi Scott, you can always hide the subform for security purposes.  A form needs to be coded properly to be a subform or a stand-alone form.  If it's set up as one and later you want to be the other, you have to rewrite all its VBA code and form references.  So it's better to start off the right way.  If the underlying data are for parent and child, I always make a main form and subform.  Most of the times I never need to break up the two forms.

Kev. . .I believe I am leaning towards this default as well. Only secure data (or a anticipated sparsity) cause me to reconsider.