Skip to main content

I would like to use the open lookup action (clicking the lookup icon) as a start action for a process flow.
This would allow us to guide user actions when they click this icon.

We often find that users click this icon while editing or adding a row because the lookup column did not display the object they needed. So they open the lookup and often need to disable a prefilter to see the rows they needed. Our users complain that this is hard to understand and to much of a hassle.

With a process flow we would be able to automatically disable prefilters when they open the lookup, making the entire process more intuitive. Using a process flow for this allows us to configure which prefilters should be disabled and which may remain active.

Implementing this also opens up all kind of nice features since so many things are already possible using process flows. We could also configure it to send a user to a form in edit mode so they can immediately add a missing row without any extra clicks for example.

To illustrate how this feature could help, I have an example we are all very familiar with:

Lets say I’ve been asked to review code in a branch that currently isn’t active for me. The ‘Branch’ lookup column doesn’t contain my colleagues’ branch so I open the lookup:

It’s still hidden by the prefilter, which I need to disable to find the branch. This particular lookup is quite slow for us so this entire process is slightly infuriating.


It would be very nice to immediately have the prefilter be disabled by a process flow so I only have to wait once and to save me a click.
 

Hi @J. de Lange,

Opening a look-up can occur in multiple states, such as in Edit mode and Non-edit model. But also if the field with the look-up has a value or not, that also impacts the look-up after as the look-up will filter on the input value.

Would it be a better solution if you could enforce a prefilter on the dropdown recordset which is not enforced when opening the look-up popup? That way you could limit the recordset in the dropdown to your liking but keep the entire/bigger recordset when opening the look-up. Like in your example, the dropdown would be limited to branches that are within the My branches prefilter set, and when opening the look-up, this prefilter is not active therefore showing all branches of the model.

New→Needs feedback

Hi @J. de Lange,

Opening a look-up can occur in multiple states, such as in Edit mode and Non-edit model. But also if the field with the look-up has a value or not, that also impacts the look-up after as the look-up will filter on the input value.

Would it be a better solution if you could enforce a prefilter on the dropdown recordset which is not enforced when opening the look-up popup? That way you could limit the recordset in the dropdown to your liking but keep the entire/bigger recordset when opening the look-up. Like in your example, the dropdown would be limited to branches that are within the My branches prefilter set, and when opening the look-up, this prefilter is not active therefore showing all branches of the model.

This would definitely solve most of our current use cases and would be a very welcome addition.

I do feel that somehow linking this to process flows would allow for even more options which rely on already existing features in the SF. It would also avoid adding yet another very specific setting under subject settings. Would it be an option to add Edit mode, and input value as output parameters of this start action? That way we can decide what to do in the process flow.

This is only a suggestion of course. You are in a far better position to decide what would be the best way to implement this in the Software Factory. 

Needs feedback→Under review

We can certainly consider starting off process flows when opening a look-up. However, it is a bit contentious to start process flows during editing/task execution. Furthermore, the GUI already performs certain actions depending on the state, such as navigating to a form or applying a filter or go-to-row to the current value.

For this situation I’d consider an alternative instead:

Allowing the user to expand the available values in the look-up to include items outside of the default look-up prefilters would resolve this situation without process flows required for every look-up.

It would also be available for any existing look-up without developers having to set up anything.

 

Would something like this be a viable alternative?

Under review→Needs feedback
Updated idea statusNeeds feedback→Open

We can certainly consider starting off process flows when opening a look-up. However, it is a bit contentious to start process flows during editing/task execution. Furthermore, the GUI already performs certain actions depending on the state, such as navigating to a form or applying a filter or go-to-row to the current value.

For this situation I’d consider an alternative instead:

Allowing the user to expand the available values in the look-up to include items outside of the default look-up prefilters would resolve this situation without process flows required for every look-up.

It would also be available for any existing look-up without developers having to set up anything.

 

Would something like this be a viable alternative?

This does sound like a good alternative. How would you define which prefilters are switched off when clicking “Load other available items”? Without a way to configure this, it might cause problems with pre-filter groups or otherwise mandatory prefilters.

Terms & ConditionsCookie settings