Whenever you use a script to place the cursor into a portal field, you must always be aware of your position. Whenever you manipulate anything outside of the portal fields, your position moves out of the portal.

One of the first things that a new FileMaker developer will notice is that you can’t modify a portal row, commit records, and then try to access the next row. Once you commit, your position in the portal disappears and you’re back in the focus of the main record. If you go to the next portal row from there, you’ll simply go to the first portal row every time. The common workaround is to simply store the current position and use that with Go to Portal Row to reach the next row.

Another issue is that Go to Portal Row always goes to the bottommost portal (based on layout depth arrangement, not position), which is normally the first portal that you’ve created. If you wish to move to a higher portal’s record, you must first go into an object or field within the higher portal first. Then, Go to Portal Row will be in the context of the higher portal.

A final situation to watch out for regarding portal position involves when you have field validations within calculated fields. Let’s say related field A is a certain value. Related field B auto-calculates from field A and then validates its own data. If field B can be found both inside and outside the portal, then that validation will always point to the field outside the portal.

So in this situation, if you’re entering data into a portal row’s field A and don’t meet field B’s validation, you’ll be brought to wherever field B is on that layout outside the portal, losing your portal position along the way. Field B could even be on another tab, which will make the validation experience truly disjarring.

And even if you don’t have field B outside a portal but have it inside 2 separate portals, you’ll always be brought to the field B that occupies the lower position (based on layout depth of the field itself, not the portal it’s in). You could be moved from one portal to another, likely unrelated one, and possibly on another tab.

The best option for these validation cases is to make additional reference fields instead of reusing the same fields. But hopefully, these won’t be situations you’ll be encountering often.