I've seen a few different questions/ideas around changing {form} defaults based on {if} conditions or other variables, and I have some specific needs to add:
formmenu: when trying to put if/else conditions on the default for a single-select formmenu, I get the error "Cannot specify more than one default if "multiple" is not "yes"." I have many, many places where only one item should be selected from a formmenu, but the default is dependent on other variables.
e.g. For a template that enters notes in our CRM: if a customer is >70% installed (as indicated by other variables), their default onboarding status (formmenu) should be "Complete", elseif they are >70% installed, the default should be "Failed to Launch"
formtext: according to this post, this is one field where conditions are allowed, but if I try to make the default dependent on another {form} field, I get "[Error - "default" cannot depend on form data here]"
e.g. For another note template, if a "Call Result" formmenu selection is "Connected", the default formtext for "Call Notes" will be different than if "Call Result"=="Other"
formtoggle: no matter how I arrange the if/else conditions for a formtoggle default, I get the error "Cannot convert "[Error - Invalid default value for form command.]" to yes or no."
e.g. For an email template: if a previous selection indicates that a customer's software does not have an integration available in our app marketplace, the formtoggle for sending our API documentation should change from default=no to =yes
All in all, it would be great if {form}s could be nested within {if} conditions (or vice versa) and have the defaults obey any dependencies based on this nesting.
You can't use {if} within a command, but we do support a ternary operator that allows you to do conditional logic.
See this example below:
Is it after noon?:
{formtoggle: default={=yes if {time: HH} > 12 else no}}
(Note that this could also be expressed more simply as):
{formtoggle: default={={time: HH}>12}}
I think the above addresses your last point.
To your second point, as you note default values can't depend on other form data. This is a hard constraint at the moment. We hope to be able to loosen it in the future, but it's not going to change in the near term. Note though that you should be able to currently implement anything you could with this capability, it just might be a bit more complicated.
To you first point, this can't be done solely with a formtoggle, but you can combine it with a supplemental formtext element to set the default value. For example:
{note}This just is a placeholder to store the default value for the menu below {formtext: name=time menu; default={="after noon" if {time: HH} > 12 else "before noon"}}{endnote}
{formmenu: name=time menu; after noon; before noon}
Thanks for clearing up the error message on the formtoggle; unfortunately, my needs are pretty much dependent on (1) having default values dependent on other form data, and (2) using full {if} logic nested within {form} commands.
Our template customizations aren't usually dependent on external factors like time/date, but on customer progress or other data entered by users. We're getting by with defaults that are based on the "most common" selections, and I try to add help text as a substitute for dynamic defaults:
{note: trim=yes}
Onboarding Status: {formmenu: name=OB_status; default=Complete; FTL; Unresponsive; Returned}
{if: OB_status<>"Returned"; trim=left}
Customer Progress:
{formtoggle: name=Dashboard; default=no}Created{endformtoggle}
{if: dashboard; trim=left}{created="created dashboard"}
{elseif: not dashboard and not (devices or app or training); trim=left}Status should be Unresponsive!{created=""}
{else: trim=left}Invalid selection!{created=""}
{endif: trim=left}
{formtoggle: name=Devices; default=no}Installed{endformtoggle}
{if: dashboard and not devices; trim=left}Status should be FTL!
{elseif: devices; trim=left} | How many? {formtext: name=active; cols=9} of {formtext: name=purchased; cols=9}
{installed=concat("installed ", active, " of ", purchased, " devices"); trim=left}
{if: active<>"" and purchased<>""; trim=left}{calc_perc=(100*active/purchased)}
{else: trim=left}{calc_perc=0}
{endif: trim=left}
{if: calc_perc<70; trim=left}Status should be FTL!
{else: trim=left}Status should be Complete!{endif: trim=left}
{else: trim=left}{installed=""}{calc_perc=0}
{endif: trim=left}
{formtoggle: name=App; default=no}Downloaded{endformtoggle}
{if: app; trim=left}{downloaded="downloaded Fleet app"}
{else: trim=left}{downloaded=""}
{endif: trim=left}
{formtoggle: name=Training; default=no}Accessed{endformtoggle}
{if: training; trim=left}{accessed="accessed training center"}
{else: trim=left}{accessed=""}
{endif: trim=left}
{if: OB_status=="FTL"; trim=left}
CS POC's reason for FTL: {formtext: name=FTL_notes; default=e.g. said they've been too busy to install; cols=30}
{endif: trim=left}
{selected=filter([created, installed, downloaded, accessed], v -> v<>""); trim=left}
{if: selected==[]; trim=left}{progress="not yet created dashboard"}
{elseif: selected==["created dashboard"]; trim=left}{progress="created dashboard but not installed devices"}
{else: trim=left}{progress=join(selected, "BLAZE_AND")}
{endif: trim=left}
{endif: trim=left}
{endnote}
{if: OB_status=="Complete"; trim=yes}
{time: M/D/YY}: Customer {=round(calc_perc)}% installed - close-out{key:tab}Customer has {=progress}. Ready for close-out
{elseif: OB_status=="FTL"; trim=yes}
{time: M/D/YY}: Customer FTL, {=round(calc_perc)}% installed - close-out{key:tab}Customer has {=progress}. CS POC {=FTL_notes}
{elseif: OB_status=="Unresponsive"; trim=yes}
{time: M/D/YY}: Customer unresponsive - close-out{key:tab}Customer has not created dashboard nor responded to contact attempts
{elseif: OB_status=="Returned"; trim=yes}
{time: M/D/YY}: Customer returned - OB n/a{key:tab}Return initiated in SFDC - OB no longer necessary
{endif: trim=yes}
Sadly, it sounds like I'll have to keep using {if} logic for help text until/unless I can have (1) and/or (2)!