If you'd be willing to also use the Rules module for actually sending such eMails (together with Webform Rules), you'd have all sorts of flexibility about how you want those eMails to look like.
As an example, consider this custom rule for sending an eMail (in Rules export format):
{ "rules_process_submitted_webform" : {
"LABEL" : "Process submitted webform",
"PLUGIN" : "reaction rule",
"ACTIVE" : false,
"OWNER" : "rules",
"REQUIRES" : [ "rules", "webform_rules" ],
"ON" : { "webform_rules_submit" : [] },
"DO" : [
{ "mail" : {
"to" : "[site:mail]",
"subject" : "A new webform submission has occured",
"message" : "A new webform submission has occured (with form-id \u0022[form-id:value]\u0022). It was submitted by the user with id = [user:id], name = [user:name] and eMail Id = [user:mail] ...",
"language" : [ "" ]
}
}
]
}
}
I intentionally did not include any Rules Conditions here, just to illustrate that by using such basic rule, you do have access to a limited set of tokens related to the user who submitted the webform, such as [user:id]
, [user:name]
and [user:mail]
. In other words, you don't need a Rules Action like "fetch entity by ID" for these kinds of tokens to be available.
But wait, there is more ... You can also include any of the "Webform data" in such eMails. To do so, you could use a technique similar to what is described in my answer to "How to do a data comparison to submitted webform data when using the Rules module?". For short:
- Add an extra Rules Action to
Add a variable
, with a value assigned to it equal to your Webform data you want to use (and with an appropriate data type). You'd need 1 such variable for each Webform component for which you want to access its Webform data.
- In your subsequent Rules Actions (e.g. in which you create an eMail) you can refer to the value of these variables you just added (that's the clue!).