there can be an additional relationship on the layout. create a global field (in parent) & place it on the layout to hold a "key" (to be placed there by clicking on the portal row - a button there). this can then be related directly to the portal record (a new relationship). when set, the fields from this new relationship can then be entered/edited.

there can be an additional relationship on the layout. create a global field (in parent) & place it on the layout to hold a "key" (to be placed there by clicking on the portal row - a button there). this can then be related directly to the portal record (a new relationship). when set, the fields from this new relationship can then be entered/edited.

Why not open the related record in a new window that doesn't allow resizing/closing/etc (see options for 'New Window Script Step') - with a button that closes the window when finish editing - and You be there where You started? Just go to the native layout/TO of the portal record in that new window

You could also use the 'go to related record' script step with the 'open in a new window' option or get the ID of the portal record in a $variable and isolate that record in the new window in its native layout/TO

A popover may be set up with global fields for editing/creating the portal records. A button outside the portal can open the popover with empty global fields and a global variable set to indicate that the "mode" is to add a new record. A button inside the portal row can set a global field used to match directly to the portal record and load the global fields with values from the portal record for editing plus setting that same "mode" Variable to indicate that this action is to "edit" an existing record.

Clicking a "save" button in the popover either creates a new portal record (if mode is "add new") or uses the global field based link to the existing record to edit it. (If the "mode" is "Edit".) This can easily be a modified version of MagicKey if you want, as the same global field based relationship can add a new record if it is empty and edit an existing record if loaded with the ID of an existing portal record.

so only only the child key fields are shown in the portal.

That's something that I would not do. Key fields are the fields that shouldn't really ever be exposed to the average user. A name or description field that is, as a result an easy thing for the user to recognize and work with, yes, but not an actual key field.--but I may be misinterpreting what is meant by "key field" in this thread.

Thanks for your input. Sorry for not being more clear and causing you to misinterpret.

By key fields I meant that by looking at the line in the portal I could immediately see what the child record was about. I agree that fields like primary- secondary and foreign keys should never be accessible to users.