Hey @antony: Greatly appreciate the clarification about this Idea post. Also, I didn’t mean that summary to sound quite as snarky as it does upon re-reading! (The main point being that – while it would be nice if state defaults had a little more sophistication, and after looking at this a lot it’s not clear to me that there’s a good reason for that omission – one can always initialize a custom state on page load via a workflow.)
The point you raise about text concatenation in the Set state dialog’s value field is a good one. As I was playing around with custom states, I did not run into this. BUT, what you observe is absolutely true:
It is not obvious (like, really really not obvious) how to concatenate text values in that field.
The value field there seems to be (for lack of a better term) a “pure, single-expression” field. One cannot mix a text expression with text typed via the keyboard, nor can one chain two dynamic text expressions there. This makes it seem like concatenation may be impossible in that field.
(Further, when we look to see if there’s a :concatenate operator or something like it, we don’t obviously see one…)
We are used to seeing text fields like the one in the text element or in the boolean :formatted as text operators dialog, which DO allow text concatenation. (Spoiler alert: I think we just found the solution…)
So the question becomes: Is there a way to go from the pure expression field to a field where we CAN concatenate text. It turns out that there is: We can do the :formatted as text operator on a boolean expression and, when we do that, we get a more robust text-specific input where we can do all of the text things and return whatever text we want.
Here’s an example of how:
Note that we could have used any boolean expression in the Value field shown above and slapped :formatted as text on it. But what I chose to do is evaluate whether some dynamic text expression (that’s part of what we want to concatenate) “is not empty”.
Here’s how this works: The first part of this expression is a boolean expression. It looks at Current User’s Last Name. If that field isn’t empty, it will return yes/true. If that field is empty, it will return no/false.
Now we put :formatted as text on it to turn those true/false values into a text. And when we do that, we get the handy Boolean formatting dialog, which has full-featured text fields in it (note it even has Rich text editor links!).
For the yes case (Last Name has some text in it), we return concatenated text that’ll be something like “Smith is your last name!” For the no case (Last Name doesn’t have any text in it), we return the empty string (though we could do anything – for example, return “Hey, we don’t know your last name!”).
Having done this, we can see that there are probably other similar approaches like using :search and replace or :replace with regex, which will also present us with full-featured text fields, but I think a boolean :formatted as text is the easiest approach.
As i said, we could use any boolean expression to trigger :formatted as. Note that we always have access to at least 1 boolean expression that’s easy to snag: Current date/time is empty or Current date/time is not empty (take your pick). Current date/time is NEVER empty, so the first expression always evaluates to no/false and the second expression always evaluates to yes/true.
So we could do this:
One caveat: These “pure expression” fields like Set state’s Value field DO seem to have a bug that I often run into. Sometimes, the list of available dynamic expressions seems to go haywire and you’ll find that there are only a few options. If that ever happens to you, just reload the page and when you next click, you should see the full list. This drives me bananas and it seems to happen entirely at random.
You can tell when this is happening as things like Current date/time will not show in the list. While I was constructing this example, in fact, this happened to me. Here’s what the list looks like when it’s behaving properly, BTW:
