Relationships should be generally based on serial numbers, though there trick situations where you'll have a different arrangement, like a 'saved' querry
The key thing to remember is it is your responsibility to make sure native IDs are being echoed into fields in foreign tables. By native I mean unique, and in a Super table or parent table. By foreign I mean a table acting as a subtable or child to the first table (relative to our first table). By echo I mean a copy is made of an ID and stored in the foreign table.
When using Filemaker portals, this is done for you, behind the scenes, but only if you select 'create relationships' in the 'Edit Relationship' dialog window (found when in the relationship graph, and you double click the relationship operator). Note that if you have other foreign ID fields in your child table (because a child can have an infinite number of parents or super tables, meaning super entities) you'll have to populate those fields via other means.
Other means would be, manually write in each foreign ID, which is not reasonable, or make use of a script with a Set Field step et. Or:
If you were to work from a child layout, and wish to assign a parent, then you can use a drop down list for that field. In this case, you're working in the opposite direction of a portal, and so wouldn't need to select 'create relationship' in the Edit Relationship dialogue box (unless you're using the portal elsewhere). To assign a parent record you need to store a copy of the parent ID into the field meant to hold this copy in the child table (where its considered to be a foreign field, which means it isn't required to be unique). To do this you'll need to create a value list. The value list will have the ID as the first shown, whereas the surname will be the second shown. Even though the surname is shown, it isn't stored, only the ID is stored, and a copy of it at that. AFTER, this has been done, THEN you can have a display of the surname in yet another field in the layout that is now showing the related field SURNAME (which is like peeking into the parent table from the child table, but only when they're already related or joined together). The surname can be adjacent to the ID (in and on the child layout) or it can even be placed directly on top of the ID field (but you'll want to set it to be 'not-enterable' or 'not-editable' in browse mode, AND you'll want the ID to be set to the same color as the background of your layout -- you, the user, want to see human names, but filemaker the database, wants to see nonsensical numbers)
One mistake to watch out for, is when assigning parents in a child layout, you might have the correct value list, but are (mistakenly) trying to store the parents ID copy into a field based on the wrong table -- it must be the field set aside for the copy of the parents ID that is resident to the child table.