Awesome! Glad it worked out.
Sending a URL parameter would be a different route if you didn’t want to set the page to a specific data type. If for whatever reason your questionnaire page would have been more efficient being type questionnaire or type user or something else, then we would have simply sent that new client data via different means - the URL.
To do that, instead of sending page data, when selecting which page to navigate to in your workflow, you have the option to “send more parameters to the page.” You’ll be prompted to enter a key (whatever you want) and the value for that key (again whatever you want and this can be dynamic).
Key = “client” Key Value = “result of step 1’s create a new client”
In this case the unique id of that new client entry is sent to the questionnaire page. You’ll see your parameter in the URL as “client=uniqueid” at the end of the URL string.
Then to retrieve this data on your questionnaire page, on the same workflow that creates a new questionnaire, you’d still have that client field, but the value is “get ? parameter from page URL” (at the bottom of your dynamic options list) - select that, click on it again to bring up the parameter name input, and type in the parameter you want, in this case “client” - now, when the questionnaire is created, it knows that the value of that client field equals the client key in the URL.
Sending URL parameters offers a lot of flexibility because it’s really dynamic and you can do multiple parameters. Does this make sense?
EDIT: I think both routes are no more or less efficient - it’s hard to say because I’m not sure what the rest of your page structure or workflows are like and overall goals, but they require about the same amount of effort in my opinion.