Thank you. This helped. What I did was to create my confirm_form function as a menu callback: <?php $items['og/regcode/confirm/%'] = array( 'title' => 'Confirm registration code', 'page callback' => 'drupal_get_form', 'page arguments' => array('og_user_roles_register_confirm'), 'access callback' => 'user_access', 'access arguments' => array('use registration codes'), 'weight' => 10, 'type' => MENU_LOCAL_TASK, ); ?> So, in my submit hook, I do a "drupal_goto" (as opposed to drupal_execute or drupal_get_form) and put the key variable in the argument as part of the url. This works. But, seems to me that it would be much easier to be able to call another form and pass form variables from a submit hook (as I was attempting to do). -ron Earl Miles wrote: Yes, drupal_execute() submits a form. it does not render the form. The idea there is that it happens completely independently. To do what you want to do, you are going to need to cache the values from your first form somewhere (possibly via values on the confirm form) and do your work in the confirm form submit. In addition, you have the problem that there is no communication between FAPI and whatever called drupal_get_form; your submit cannot actually render a form (it returns a value to redirect to, not output) so the only way you can do this without hacking fapi like I did is to set a global variable. You could also install CTools and use the form wizard tool which this is a nice example of, and in fact might make a lovely example of how to do a more complex confirm form than the ones that currently exist.