初歩的な質問な気がするのですが、対応方法が不明だったため質問差し上げました。
よろしくお願いいたします。
回答ありがとうございます！
そのような方法もあるのですね。
今回は結構複雑なデータを引き渡そうと考えており（あるtypeオブジェクトの中に複数のtypeオブジェクトがlistで入っている等）、値それぞれを個別で渡すよりも整理されたtypeの形式で引き渡したいなと考えている状況です。
どういうデータを渡そうとしているのか気になるので、
１、２ページのコンテンツとページ遷移のワークフローのスクショを共有していただくことは可能でしょうか？
情報不足で恐縮です。
以下、コンテンツとワークフロー、データについて共有いたします。
質問を選択する画面になっています。
テンプレートとなる質問群(repeating group)からチェックした質問をまとめて後述のAsking(type)に格納し、ページ2に送りたいと考えています。
質問の送信先を確認する画面となります。
したがって、ページ1で質問作成しこのページ2で最終的に送信＆Dataへの保存を行いたいと考えています。
Askingはある人が他のユーザーに対して質問したという事実を記録するtypeです。
Askingには一つ以上のQuestionを含みます。また、QuestionはChoice（選択肢）を0~n個包含します。
このようなやや複雑な構造であるため、ページ1の時点でAskingをデータとして作成しそれを渡したいと考えています。
ページ1からの遷移のワークフローについては友人に開発してもらっていてまだ未作成となっています。
そのため、ページ2内でテストデータを作成して対応しようとしている状況です。
Askingのオブジェクトを作って渡すという方式を考えているので、以下の内容でテストできると考えております。
テストなのでサンプルの質問を2個セットしています。
test_askはAsking型の値となっています。
上述のワークフローを実行すると、Dataに値が作成されます。本来はページ2で「送信」（添付画像だと隠れていますが）を押したタイミングでDataに作成したいと考えています。
とはいえ、ワークフローの最後でDelete Result of step3（Askingを削除）をしてしまうと、DataからだけでなくSet stateした値そのものが消えてしまうので困っている状況です。
上述の情報で何かわかりましたらご教示いただけると幸いです。
不足ありましたらお知らせください。
よろしくお願いいたします。
（申し訳ないのですが、外出するので返信遅くなるかもしれません）
ワークテーブルを作成するのはいかがですか？
案）
1ページ目の入力結果をaskingと同じ構造のワークテーブルに保存し、2ページ目に引き渡す。
2ページ目で、引き渡されたワークテーブルの内容を表示し、送信された時はaskingに保存。
保存が正常に完了したら、askingの内容を削除。
この方法の場合、ユーザーが2ページ目を間違って消してしまっても、ワークテーブルにデータが残るので、再入力の必要はなくなる。
また、2ページ目でそれぞれの項目を編集された時に、ワークテーブルに都度上書きできるので最新の編集データを一時保存もできる。
ワークを作りたくない場合は、askingに一時保存のフラグを持たせて2ページ目ではそのレコードには上書きせずに保存→保存完了後に一時保存フラグのデータを消去
ページはbubbleのuidではない別のキー（slugなど）で表示制御をするとうまくいくと思います。
詳細共有ありがとうございます！！！
今回の質問の意図としては、
ページ２の開始時点でCreate a thingでデータを作成することを嫌っている理由としては、例えばユーザーが途中で作業をやめて離脱したときに、作成されていないAskingが残ってしまうというのが問題ということでしょうか？？？
そういう理由であれば、yukikunさんがおっしゃられている方法が良さそうですね！！！
別テーブルに流すか一時保存フラグで運用するかして、それらのデータを定期的にバッチ処理で削除するなどでその問題は対処できそうですね。
ご提案ありがとうございます！
確かに、ワークテーブル作ってしまった方がシンプルでよさそうですね。
その方法で実装しようと思います！
ページ２の開始時点でCreate a thingでデータを作成することを嫌っている理由としては、例えばユーザーが途中で作業をやめて離脱したときに、作成されていないAskingが残ってしまうというのが問題ということでしょうか？？？
はい、まさにその通りで、不正になりうるデータを正式なテーブル(type)に入れるということにかなり抵抗がありました。（という意図をお伝えしておくべきでしたね…）
フラグで持つとバグを作り込みやすいかなという印象があるので、一旦別テーブル保持で実装しようと思います！
アシストありがとうございます！
もう一つの案として、そもそもページを分けないことですね。
Groupを2つ作って、
1の確認用ボタンを押した際は、1を非表示にして2を表示。
2の確定ボタンが押された時はcreate record
2の修正ボタンが押された時は、1を表示して2を非表示に。
回答ありがとうございます！
確かに、言われてみるとそもそも分けずに同一画面に表示させてもいいかもしれませんね。仕様検討しようと思います。
