How is your script triggered? What does it do?
Answer is almost certainly, "yes," but can you give a bit more information?
It's better to work on the related records rather than a portal. Walking portal rows is not reliable.
The script would at some point use the Go to Related Records script step to select the related records to work on. The step specifies the relationship to use. Often this is done in a separate window.
Use Go To Field () and select one of the field in the portal you want to address. Then you can navigate the portal rows.
The Script is in a menu.
not sure what you need
It create basic entry in the portal, the user then fill the remaining part.
I will try
Just taking that further, the only way, in a script, to choose between portals on a layout is to give each portal a name (as shown) and use Go to Object. This will put the focus on the specific portal, then Go to Portal Row [ last ] will take you to the empty row at the end of the portal, which will be there for data entry purposes if you have check the portal relationship to allow creation of records. you could the use Go to Field to land the cursor in a specific field in that row.
This is a pretty standard method of achieving this particular task.
I have no problem with naming the portal and using go to object but it isn't the only way.
Go To field works fine on it's own.
Go to Field is good shorthand if there is only one instance of the field in the layout.
Object name is always unique in a layout.
Not really as the field in the portal would show as...
"Not really as the field in the portal would show as...
And you've never put two or more portals based on the same relationship on the same layout, perhaps with different portal filters or to set up a "horizontal portal"?
Go To Object is by far the better option.
I agree, in the case of 2 of the same portals with portal filters Go To Object is the best option.
I guess I rarely use portal filters. I usually do the filtering via the relationship so the path to the field is different.
Yes, but you missed part of what I'm trying to say.
Go to field may work perfectly fine now, but will it always work in the future?
Neither you nor I know what changes might need to be made to a layout in the future. And if you change the layout by adding another instance of the same field object--which does not even need to be in a portal as fields from related tables can be added directly to a layout, you may keep your script that uses go to field from putting the focus where it's needed. If you use go to object, you are less vulnerable to such issues.
Please note that scripts that process data in a related table by looping through portal rows are vulnerable to such problems even when Go to Object is used, it just reduces the number of possible failure points. The original question here may be a case of simply using go to portal row to put the focus on a row and leave it here, but if you are looping through the portal rows to add or modify records in a related table, there are other options that are not nearly so "brittle" and I thus avoid such scripting in my own work.
I do get it and mostly agree it is better to use Go To Object. I am well aware of how I integrate these features in my solutions. For the casual developer it is probably better to use GTO.
I am also not a fan of 'walking the portal' to edit related records but there are times when it makes sense.