I'm a fan of collapsible list views for things like this:
It requires a join "shadow" table to make it work but the user experience is good. However this is not really a portal inside of a portal.
Ultimately you will have to go to the related record from the portal to another screen to have access to a sub-portal to add your images.
The best suggestion is to use simple navigation and layout indicators so that your users can easily switch between the two layouts. This could be as simple as an "expand" button in your main portal, and a "close" button on your secondary layout.
So a follow-up if I may... Right now the portal on the main layout is related and writes to a JOIN table as it is a many to many relationship. So the join has an ID Field, an AuditFK field, and an ElementFK field. The pictures should be related to an Element that is related a specific audit, since multiple audits will inevitably include the same element.
So, in the media table, am I correct that I would need to create both an auditFK and elementFK, and then relate them both to their respective FKs in the JOIN table in order to have the multiple pictures related to the element in the one audit?
... And don't know if this is related to this question or if I should start a new thread, but I just realized something weird is happening. In the portal that goes to the JOIN, if I choose two different elements, both elements are added to the JOIN (i.e. AuditFK # and ElementFK #), but once the record is committed the second entry disappears from the portal. The record remains in the JOIN, but isn't visible in the portal. Same happens if I add a third, where only the first stays visible.
The relationship between the main audit table and the join says auditID = AuditFK AND elementFK = ElementFK. Is that not correct?
At this point I am so confused.
Disregard the second post about the disappearing rows. It was a relationship issue.
If that's how your media table works, then indeed, you should have both of those keys established. Originally you had posted that it was just related to an element, meaning that media should be accessible to any Audit that an element is attached to.
Currently your structure is:
Audits >--JOIN--< Elements --< Media
Audits::AuditPK >-- JOIN::AuditFK | JOIN::ElementFK --< Elements::ElementPK --< Media::ElementFK
Essentially what you're asking for is media to only ever be attached to a single audit/element combination, correct?
Since you will be adding both keys to your table, then you can establish one-to-many relationships from either elements or audits to show a portal of related media.
Audits::AuditPK --< Media::AuditFK
Elements::ElementPK --< Media::ElementFK
You could even setup something using the media table as a join itself, say if you wanted to display a portal of audit media, with related element info:
Audits::AuditPK --< Media::AuditFK | Media::ElementFK --< Elements::ElementPK
With the Media table being your portal, you would be able to display data from elements in your portal.