Then something was not specified correctly in either your script or your relationship. If you share the details of your script and design, it's possible that we might be able to spot and correct the issue.

And note that, depending on your layout design, modifying a field in the table of related records may create issues for you if it is ever possible that two users might try to select different sets of records from the same set of related records. But there are ways to avoid that issue that select the related records without modifying data in them that can keep one user's selections separate from another's.

Enter find mode
Specify search criteria that selects which records in join_events_documentation that you want to print
Constrain Found set (This must be constrain found set, perform find will produce the wrong result.)

Answer: where are script steps? I forgot to mention that it was the script before the feature of printing a selection of related records.

My relations were good. However, I used for the lay-out of my report the wrong join-occurrence. That did not give a conflict, until I wanted to add my new feature.

In stead of adding the go-to-find-mode is use now directly the constrain found record step. It seems that if you use the go-to-find-mode and perform a search, it searches all records, instead of only the related records of one specific record. The constrain-step limits itself to the related records only.

In it a script uses GTRR to pull up all the records in the portal, then enters find mode, specifies "red" in the color field and uses constrain found set to reduce the found set to just those records in the portal that had "red" in the color field.