Continuing the discussion regarding asking user input for rules, I thought this probably deserves its own feature request.
Currently, asking for user input is only available for button automations. However, as was discussed in the topic, it would be very useful to have available as part of automation rules. There are quite a few instances where this might be useful, for example:
When a new item is created (in a view or inline in rich text fields/documents), there are often some important fields that should be filled in quickly. Being able to ask user input for select fields as part of on creation rule would be a great way of doing this. Currently, you have to click (or Alt+click) to open the full entity view to be able to enter this data. A simple example of this would be when creating a new task during a meeting, you would want to capture things like assignee, due date, priority, etc right away. This is also extremely useful when the name of the entity is formula-based.
As part of a particular workflow, there is often a need to capture bits of information as you go through the workflow. So It would be helpful if you are able to define rules when a particular update to a workflow/single-select field would trigger a rule and ask for particular information to be added or updated. An example of this would be approval process for vacations/purchasing/expenses where in the multi-step process, the individual decisions might need to be captured.
@Oleg identified some challenges with this, in particular since rules can be triggered by a variety of situations where there is no user to ask for input. There were a number of interesting suggestions:
Setting up default values (which is already possible for drop downs but might be useful for other fields) that would be used when input is not available
Applying the rule to situations when the action is triggered as part of a user UI action
I also have tried to automate setting up âintelligentâ default/initial values for Tasks when created from within a Rich Text field. The main problem for me is that I havenât found a good way for a Rule to determine the context in which the new entity is created (i.e. the RichText and its containing entity).
I agree that it would be very useful to be able to prompt the user for more info situations like this, to save them from having to explicitly open the new entity and navigate through all its fields to find the ones that should be set. It is much more efficient if the user is simply presented with all the fields that need to be set.
If a ânew entity createdâ Rule could be triggered/selected by specific circumstances of the entityâs creation â e.g. âFire when a new Task entity is created inline in a Rich Text Fieldâ â and if the Rule could also ask for user input like you suggest â that would be a neat solution. Especially if such a Rule also could use the entityâs creation context (i.e., in which Rich Text field it was created, within which entity). That context should actually be something that the Rule can test as part of its criteria; e.g., âonly fire if the new entity is being created in a Meeting Notes Description fieldâ. Then the rule could intelligently use the creation context to set up some default field values (e.g. assign the Taskâs Project, via the Meeting Notes entity), as well as prompting the user for initial values like Assignee and Due Date.
Running into some situations where prompting a user to enter the a field value when a rule is triggered would be very helpful.
Itâs pretty basic/essential functionality for any CRM applicationâŚwe do this in Hubspot pipelines all the time.
Like, when user triggers update to a dealâs state from âquote generatedâ to âquote approvedâ, automatically prompt user to assign âaccount managerâ to deal.
I know I could create a button that says âApprove Quoteâ that would do this, but there ends up being so many buttons for all the different scenarios and itâs much more natural to contextually prompt users instead.
With the current Fibery design, it is unlikely to be possible to achieve this for two reasons:
rules run on the backend so can only operate on the data in the workspace, they canât affect the UI
the things that can trigger an automation can include events where there is no user involved, e.g. a formula update, or a scheduled automation. In such cases, there is no guarantee that a user is actually logged in and able to be prompted.
Iâm assuming that in Hubspot, the triggers for these prompts to appear are guaranteed to be immediately related to an action a logged-in user has taken.
Creating a database âUser Inputâ, related to the database that you are working on with the script. To make it more visible put the User Input relationship collection field at the top of your current entity, and use an appropriate view so values can be easily read and edited.
An automation that needs user input needs to be split up in multiple automations:
Part one of the automation up to the point of user input, then make the script create a new entity of type User Input and link that to the currently viewed entity. When executing, this will show up and the user can fill in fields.
In the User Input database, another automation triggers the user input change, and activates another automation and script,
âŚand so on.
The User Input database automation can also be an entity creation button so that entity values can be prompted using the regular automation button popup
I think the closest you could get to this is to something something like @Yuri_BC 's suggestion of an âUser Input DBâ, which could generate a Notification linking to the required input â and hope & pray the user actually sees it
This is actually a pretty good general solution, since an âintermediate inputs DBâ is really a sort of task queue of abstract things that need some kind of attention to continue - either from a human or some other script, etc. - and it could automatically trigger its ânext stepâ once it gets its required values. It starts to sound like a Workflows system!
The biggest weakness is the existing Notifications system, which is arguably too subtle/quiet. But it should be possible to hook into it and pop up a âlouderâ user alert, using a custom browser extension.
