You could put your merge variables in the rows of a portal based on your Organization table occurrence; one portal row will show for each associated organization. Alternately, you could use a script to populate a variable with a list of the memberships to display as a merge variable instead of using the merge fields, perhaps using an OnRecordLoad script trigger.
research the List() function and how it gives you a return-delimited list of ALL related information.
List ( children::name ) - in Bob's record gives you:
The List function is pretty swell, but if tm9 is pulling data from two different fields in the same related record, using one List call for both fields will only pull from the first related record, and using two List calls — one for each field — the function will not necessarily preserve the association between.
If you prefer the scripted <<$$mergeVariable>> idea to the portal, using ExecuteSQL will be one more advanced way to get the data for that variable, and doing a Go To Related Record then gathering the data from the related records one-by-one is another way — the latter is more cumbersome, but you don't have to know SQL to do it.
Another option, if you have space constraints and/ or, you don't want to get tangled up with ExecuteSQL or GTRR connipulations:
1. Have a calc field that tells you how many related records there are (use the Count() function).
2. Have a calc'ed text field along the lines of, 'if there's more than one related record, then show the top portal row's information, plus a note which says something like " plus 2 other roles", otherwise, just display the top portal row's information.
If there's more to see, this alerts the user that it may be worth their while to take a look.
Yes, List() only works with one related field. This is where a calculated field maybe helpful!
Or use ExecuteSQL.