Hi @mccues
I hope you’re well today!
I’m not quite sure if I correctly understand the goal here but let me try ??
In general, the form is not “submitted to email” but rather just “submitted” and then
– it can be set to store submission in DB or not
– and can have e-mail notifications created.
At least one of above options should be set if you want to actually receive any data from the form but they don’t have to. You can as well use the form without storing any data; for example if you only want to provide fields for user that will later be used in redirect URL as parameters.
But anyway, you can set e-mail notifications (as many as you want to) and in those notifications you can set recipients to be either “fixed” e-mail addresses (so that’s when you use actual e-mail address in recipient field) or “dynamic”.
The “dynamic” part relates to the e-mail field on form. So you can e.g. set notification to be sent to a person that submitted the form, to their e-mail address, provided that you put e-mail field on the form. Let’s say you have one e-mail field on the form – then you can use {email-1} as recipient in notification.
Or you can have multiple e-mail fields and e.g. set conditions for notifications to be sent or not based on other fields’ values; or e-mail routing – in a similar way.
There is no macro/placeholder for “recipient email” per se because usually:
– if “fixed” recipient e-mail is set in notification configuration – it’s easy enough to just copy it to e-mail content if you want to include it
– if “dynamic” one is set – it’s using email field for the form; so such field can also be included in e-mail content (sticking to earlier example: you can put {email-1} into the notification content.
But with all that said, I’m not quite sure how this recipient e-mail should work and where the actual address would/should come from. Perhaps you could describe it a bit more? Some example case scenario would be great so we could understand it better.
Kind regards,
Adam