If you pass the actual layout name as a script parameter, you can do this with one step and no variables:
Go to Layout [ Get ( ScriptParamter ]
To do that, you use the "layout name by calculation" option when setting up the Go To Layout step.
If the parameter passed is not an exact match to the actual layout names, you can use a chain of If, elseIF steps to match the parameter passed to the layout you want to go to:
Set Variable [$Layout ; Value: Get ( ScriptParameter) ]
If [$Layout = "first layout" ]
Go To Layout ["Layout One"]
Else If [$Layout = "second layout"]
Go To Layout ["Layout two"]
//and so forth for each possible layout.
Ah ok great - how would I use a similar method to utilize the script parameter in the "Go to Related Record" function?
You'd have to use a script patterned after my second example. You can't refer to a calculation or variable in any of the GTRR parameters so you'd have to put separate GTRR steps inside a seris of IF-ElseIF steps in order to use the script parameter to control exactly which GTRR is executed.
Ok, well in that case I have an efficiency question for you. I already have these scripts defined to go to the related records written and implemented. Since I have several layouts and tables, would it be faster just to leave it as is - and let each script be its own special function - or is actually having filemaker go through all of those if statements and testing conditions (for a bunch of layouts) maybe faster and more concise?
I wouldn't merge the scripts like this for GTRR. If anything, I'd expect it to be slower, not faster and since you can't use indirect references in the GTRR step, there are no real economies in terms of defining and managing your scripts to in the first place like you can with a simple Go To Layout step.
Ok cool - yeah thanks. I managed to merge a bunch of em that didn't need the GTRR functions - but I think it's kinda too inefficient to try to merge all those other ones. thanks again.