After user update automation: can it trigger from one required field, while optionally including other profile/custom fields if present?

Support
1

I’m trying to use the Create post script with the After user update trigger for a new-user introduction / notification workflow, and I’m not sure whether I’m understanding the documented limitation correctly, or whether there is a supported workaround.

I’ve already read:

My use case

I want to create an automated post when a new user completes a required signup/profile field.

At the same time, I would like that post to also include some optional custom user fields if the user filled them out, for example things like:

So the intended behavior would be:

  • one required field guarantees the automation fires
  • other optional fields are included in the post only if they happen to be filled

Where I’m getting stuck

The documentation for the trigger says:

The automation will only trigger once the user has filled in all of the specified fields.

And the UI also says:

Will trigger only if the user has filled all these fields

So as I understand it, if I add optional fields to the trigger configuration so I can use their placeholders, they stop being optional for the purposes of the automation, because the automation won’t fire unless they are all filled.

That seems to create a catch-22:

  • if I include the optional fields in the trigger, the automation may never fire for users who skip them
  • if I don’t include them in the trigger, then I may not be able to use their placeholders reliably in the post

My questions

  1. Am I understanding the current behavior correctly?
  2. Is the documented limitation still accurate today?
  3. Is there any supported way to:
    • trigger the automation from one required field
    • but still access other optional custom/profile fields in the post content if present?
  4. If not, is there a recommended workaround for this use case?

Ideal behavior

What I’m hoping for is something like:

  • trigger when any required trigger condition is satisfied
  • replace optional placeholders when values exist
  • leave optional placeholders blank, unchanged, or omitted when values do not exist

But I’m not sure whether that is already possible and I’m just configuring it incorrectly.

Any guidance would be appreciated.

Thanks!

2

You should be able to trigger on your custom field and add the profile fields to the post content section.

So say the trigger is confirming the guidelines, then in the post content you could do:

Hello! I'm new here
{{#pronouns}}My pronouns are {{pronouns}}{{/pronouns}}
{{#languages}}I can speak {{languages}}{{/languages}}

Is that what you’re looking for?

3

It is.

So I should have mentioned the exact field names. Sorry.

  • Pronouns/gender
  • Languages
  • Community Guidelines (understood)

The post I am generating is just going to a running staff thread to give a heads up about new users.

I don’t understand how to use the format you suggest, or how to convert the field names with symbols. I’m just going for a list. Would I do

* {{#pronouns/gender}} {{pronouns/gender}}{{pronouns/gender}}
* {{#languages}} {{languages}}{{/languages}}
* {{#community_guidelines_(understood)}} {{/community_guidelines_(understood)}}{{community_guidelines_(understood)}}

Do I just drop the symbol characters in the field names?

I could just keep experimenting, but since these fields are optional (and I’m not keen to create a bunch of test new users) it may take some time to test.

4

Oh good question, at a quick glance I think the field names with symbols would actually prevent the automation from working… we might need a little update on our end to strip them out for this kind of use.

Could you remove the symbols from the custom fields for now? {{pronouns_or_gender}} and {{community_guidelines_undersood}} should work fine in the automation without them.

5

I put in the language one for now since there are no symbols. I will also try out the others.

Can you explain the pattern of {{#foo}} {{/foo}}{{foo}}?

6

Sure, so {{foo}} is the field itself, and the {{#foo}} {{/foo}} around it is a conditional block. So if foo isn’t filled out, nothing between {{#foo}} {{/foo}} will render.

So if you did

My name is {{foo}}

and foo wasn’t defined, you’d get “My name is” in a post

but if you use

{{#foo}}My name is {{foo}}{{/foo}}

and foo is not defined, “My name is” will also be excluded from the post

7

Oh! Fancy!

So, I’m wondering if there is any way that testing out variations would cause the whole thing to fail? Meaning a new post wouldn’t be created at all. If not, then I can just try all sorts of combinations of the fields with symbols and see what works more quickly.

8

OK, great news.

This works:

* Languages: {{languages}}

However these do not:

* Pronouns: {{pronouns_gender}}
* guidelines: {{community_guidelines_understood}}

As a reminder, theses are the field names:

Pronouns/gender
Community Guidelines (understood)

I will try

* Pronouns: {{pronouns/gender}}
* guidelines: {{community_guidelines_(understood)}}

If that doesn’t work, maybe we need a code fix? I’d rather not change the field names.

9

OK, turns out that it doesn’t.

And keeping the parens in breaks the automation. Got this in the logs:

Mustache::Parser::SyntaxError (Unclosed tag
  Line 12
    * guidelines: {{community_guidelines_(understood)}}
                                        ^
)

So, do I need to submit a bug/feature request to have symbols be stripped from field names?

10

oh yes sorry that was unclear, if you remove the special symbols from the custom fields only then will they work in the automation… Discourse needs some adjustment to strip out the special characters automatically so they can be used in automations as you currently have them configured