Forum Academy Marketplace Showcase Pricing Features

Button is always clickable when modifying an exisitng entry

I am currently working on a form that:

  1. [Update] button isn’t clickable by default.
  2. When any one of input field’s value changes, the button’s custom state allow_update becomes “yes”,
  3. Which in turn makes the [Update] button clickable.

Here’s the workflow (basically when input A/B/C/D…'s value changes, trigger custom event to make the button clickable) It works well – but I can’t help but think this looks very redundant. I have about 10-20 fields so I have to make 20 events. As far as I understand it doesn’t count to workflow limits, but I still would like to make it as efficient as possible.

Is there any smart way to make a button clickable when any one of input field’s value changes?

Hey @ernie :slight_smile: Just to double-check, if a User changes any one of the inputs’ values - the button becomes clickable? (Similar to a ‘Save Changes’ page with a ‘Makes Changes to a Thing’ workflow?).

That would be one way to do it. A very similar way would be to just have the three purple input workflows change the value of the Allow Update custom state to “yes” themselves?

Hi! @fayewatson Thanks for the idea. When I read your comment, for a moment I thought, “What! I knew this feature! I should probably take a break. :frowning:” So this morning I tried what you suggested and realized the issue still came up.

I think your suggestion works for a new entry (when inputs don’t have “initial content”) When modifying an existing entry, (i.e. initial contents are fetched from a database) the button is always clickable. I made a simple page that mimics this behavior:

Preview: https://sb–

Is this what you meant? Please correct me if I am not understanding your comment.

The other solution, which I am relying on, works fine for three inputs. But it would require 20 workflows for 20 inputs. That looks redundant for me, so I thought there might be a way to have one or two workflows that do this trick.

1 Like

No prob! :slight_smile: I had meant to keep the custom state you have for all of the inputs (just removing the custom event). I am guessing it is now:

  1. When (for example) input-base’s value is changed --> Trigger Custom Event ‘Allow Update’
  2. The custom event runs which changes the value of your custom state to yes (making it clickable).

And instead you could set it to:

  1. When input-base’s value is changed --> set the custom state to ‘yes’. (no custom event needed, but yes would still need to set this up for each input).

Hmm, I see. I wonder if there’s a way to not make 20 workflows for 20 inputs… :frowning:

Is the goal of this to make sure that the ‘Save Changes’ workflow is only run if something is changed? If so, it may not be worth the hassle of setting up those workflows (in my opinion). :slight_smile:

This topic was automatically closed after 70 days. New replies are no longer allowed.