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:
- 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.
- 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 
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 
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:
