You obviously already have a path between Dashboard and Contacts (why?). If you want to create another one, the TO of Contacts needs a unique name so each reference is unambiguous.
Create that new TO and relate it to Dashboard with the cartesian [x] operator, connecting any two fields. This will make all records in Contacts related, and a portal will display them all.
All "tables" on the relationship graph (RG) are table occurrences (or alias', if that helps you understand them better). You can have as many TO's of the same BASETABLE as you wish (but it can look like "spaghetti"!). The NAMES of these T.O.'s must be unique. You can even rename the TO once a table is created and automatically added to the RG.
You may see some examples others have done. Name them so they make sense, be wary of the use of odd characters or reserved words, limit length.
See this in help topic for naming hints:
(while referring to 'fields', the same should apply to table occurrences)
Me? I often connect FM with other apps/systems, so I stick with the 'safe approach' of only alphanumeric characters or "_" (underscores) in all object names (avoiding spaces).
Thank you. I think I might be trying to do something outside the scope of FM. I really want a List view layout but with a side panel. A portal seemed like a solution but its connection to the form layout's table seems to be a problem. Correct me if I am wrong but given my limited FM knowledge I can't see how its possible. It seems with the current trend of many popular apps having the ability to have a side panel for a menu on a list view would be a good option within FM.
Yes! a form/list layout would be handy. A section for 'form' and a section for 'list'. However, if you have a layout which is NOT based on your "list" and has globals to change & related to the portal, this is our work-around. The key here may be to have a 'no records' table with globals only and use a layout from that table to display what you want.