Automation: Add "current value" to 'ask user'-option

When setting a field value within an automation to “ask user for input” I would want the current value of that field (if one exists) to be preselected (or at least shown somewhere).
We use a button to estimate tasks - quite often we also reestimate these tasks (with a click of a button) and it would be very helpfull to see the current estimate before giving the input.

1 Like

One minor challenge with ‘prefilling with the current value’ is that a button action could be operating on a batch of entities, in which case, there wouldn’t be a single value to show.
Obviously, this can be accommodated, but it needs to be taken into account.

1 Like

In the case of multiple entities with different values for a field, the “current value” option could simply be shown as something like “<current value>” .

4 Likes

Sorry to revive this topic. I’ve hit this issue a number of times and I thought I should see if there is any movement on this.

I find that the “Ask User” implementation is generally incomplete:

  • You are not able to load current values (this thread)
  • You are not able to assign default values (if empty) that can be changed by the user (reduces the number of repetitive inputs) (related)
  • The context filtering does not work (even if the value of the related field had been previously set or set within the same button run):
    image
  • You are not able to add content to rich text fields (again would be so helpful to be able to load current data and then update)
  • You can’t provide any contextual information to help the user (i.e. no labels)
  • There is no mechanism to define conditions on which fields to display for user input (this is a problem with all of fibery’s input views, so not just a “ask user” issue)

I feel that instead of trying to fix this feature, it would probably much better if we were able to invoke form views from buttons (that can run a pop-up window instead). I think the issues I listed above can then be dealt with as part of the form view enhancements.

6 Likes

Some issues you mention are due to the way that buttons work in Fibery.

When you press a button, the execution of actions is actually done on a batch of entities. If you press a button in entity view, the batch is an array of only one item, but in other views (e.g. table view) it is possible to execute a button on multiple entities at once (by selecting multiple rows).

This means that there is no such thing as a single set of ‘current values’ since each entity on which the button is operating may have different values for the fields.

e.g. I have Tasks A and B, and the status of Task A is Open, and the status of B is In Progress. If I select both of them and execute a button, there is no single default value of Status which you can show to the User.
(it would be possible to show a generic ‘Leave as current value’ which the user can then choose to override, but this is not implemented)

So, many of the things you mention (context filtering, show current rich text, apply conditions for which fields to display, etc.) are just technically not possible.

Wrt form view, it is solely used for the creation of new entities, so most of these issues are not applicable (there are no ‘current values’, there is no context, etc.)
Even if a button could be used to invoke a form, it would not solve the underlying fundamental issue that buttons operate on arrays of entities.

Having said all that, it would potentially be possible to add functionality to the ‘Ask user’ settings in button automations to address some of the things you mentioned, e.g. providing guidance to the user (labels), supporting (hardcoded) default values

Finally, it is already possible to ask the user to provide content for rich text fields:

So in summary:

  • You are not able to load current values (this thread)
    :yellow_circle: Would only be possible as generic (‘Leave as current value’) but not show actual values

  • You are not able to assign default values (if empty) that can be changed by the user (reduces the number of repetitive inputs) (related)
    :yellow_circle: Hardcoded default values would be possible, but nothing conditional/dynamic

  • The context filtering does not work (even if the value of the related field had been previously set or set within the same button run):
    :red_circle: Is not technically possible

  • You are not able to add content to rich text fields (again would be so helpful to be able to load current data and then update)
    :green_circle: Already possible to ask user to provide rich text
    :red_circle: Not possible to show current rich text

  • You can’t provide any contextual information to help the user (i.e. no labels)
    :yellow_circle: Nice idea, could be added

  • There is no mechanism to define conditions on which fields to display for user input (this is a problem with all of fibery’s input views, so not just a “ask user” issue)
    :red_circle: Is not technically possible

There may be some clever workaround in the future whereby some of the currently impossible things are supported if the array of entities being acted on has only a single item, but I suspect the resulting behaviour might be confusing for a lot of users (“Why does it work as intended when I trigger in entity view but not in table view?”)

3 Likes

Thanks @Chr1sG for the detailed response.

This makes sense. I think it is actually quite helpful to be able use buttons on a multiple entities and update some fields to a value in one go while also being able to run some follow-up actions. I do wonder though if the button execution logic could be improved to:

  1. Check to see if the array of entities has only one member, in which case it would load the current content for user to update.
  2. However, if there are multiple entities, then it wouldn’t load current content and instead allow the user to, as you suggested, to check a box if they would like to “Leave current value” in which case the input field would be disabled.

I feel this addresses both the need to be able to see current value for single entities and also allow button automations applied to multiple entities to be more flexible (and potentially less dangerous) as the user has the option to effectively tell the automation, I want you to only update selected fields and reduce the need to have multiple buttons with different set of fields.

This makes sense and as you said does not affect this thread. However, I had two thoughts:

(1) Form View should be an option for new entities
The form view has been designed with an eye to making it easier for the (external) users to create new entities whereby they:
(a) don’t need to see all the fields,
(b) are provided more contextual information on what to enter,
(c) are able use rich text fields and actually have formatting options, and
(c) (hopefully when it is available everywhere) may be provided with some prepopulated information.

I think this would be very useful for situations where a button is being used to create new related items. The “Add [Relation Entity] Item” action is quite useful, especially when paired with “Ask User”. However, you are not able to provide any context or labels to help your user understand what the button is doing with your input and most importantly the current implementation doesn’t allow you to ask users for input into rich text fields. I often try to use this workflow to allow users to add quick “Updates” to a project (in our setup we track updates as separate entities). However, I realize quickly that while I can create the new related entity and set some of its fields, I can’t ask the user to type in long form text :cry:

Given the investment in the Form View, I think it is a shame to not re-use it in more places and context. I do want to stress that I like the way the button/ask-user shows-up in a modal window, so it would be a matter of rendering forms in the same way.

(2) I think consolidation of data entry experience makes sense
I know this thread isn’t about form view, individual layouts, etc. . However, I think at the end of the day, the entity view, form view and “ask-user” modal are essentially data entry forms. I’m sure there are good reasons why fibery keeps these things separate from each other, but it would be so much easier if the data entry/form experience was consolidated/unified. I think this will eventually allow the team to focus on expanding features that benefit all different contexts.

Thanks for pointing this out. I had totally forgotten about this. I think most users might also be confused by the fact that this needs to be specified in a separate action (ie. not part of the normal fields “Update”) but fibery is smart enough to show the two input request together :smiling_face: So for other users benefit, if you want to ask users for information about normal fields and a rich text field, then you can define them one after the other and fibery will group them:

Thanks for the details.

Seems like this is somewhat relevant:

but there is also the case of making use of Forms from within automations.

1 Like

Specifically to this, it’s fair to say that Form view and Ask user are data entry mechanisms, but I would say entity view is much more than just that.

This has certain implications, for example, Form view and Ask user could support validation of entered data (i.e. you can’t press to ‘submit’ until certain criteria are met) and indeed the required fields in Form view are an example of that.

However, it is harder to imagine how this would work with Entity view, since there is no ‘submit’ mechanism.
This makes it hard to design a good UX for data validation - it would be very difficult to prevent someone from modifying the data in entity view in such a way as to violate validation criteria. For example, if a user clears the value in a required field, it might be possible to highlight the problem, and/or make it hard from them to navigate away until this is fixed, but what should happen if they close the browser window?
Should the change be ignored (not typically a good idea)?
What if they made a whole bunch of changes? Should only the changes that violate the validation criteria be rejected, or all changes?

Anyway, I mention this only since I do think a unification of Form view and Ask user could indeed be worth considering, but trying to unify with Entity view may be a bridge too far.

1 Like