Right-click Show Where Used

Perhaps I’m just overlooking it, but in the App Search tool, I don’t see that it is possible to find everywhere a workflow is used. This is important for all custom workflows but especially for those in reusable elements.

If someone can show me how to do this search, I would be grateful.

Even if it’s there, and idea for improving this would be adding to the right-click menu of workflows an option to show everywhere the workflow is used. It would be much more natural while inspecting reusable workflows to determine the impact of making modifications to them.

1 Like

Hey there @laurence.

You’ve probably already found these, but just in case…

You can find the triggering of specific custom events like this:

And for api workflows:

The few times I’ve looked at the App Search tool, it has been non-intuitive to me. Since I’ve managed to get by without it, I haven’t dug very far.

Thank you for giving me a reason to dig deeper.

I still think there are golden opportunities for right-click menu options to go from where you are (workflow, action step, element) to where it is used, as if searched for in the App Search tool.

Again, I thank you.

1 Like

Here I go again, spending more time than should be necessary using the App search tool to find where workflows are used. Currently, it’s unreasonably tedious and error-prone.

Although Ken showed me the way to search for triggerings of reusable workflows, the search tool is not nearly as helpful as it could and should be. One case in point:

Above is a partial list of the 26 instances of the workflow “Copy and Open Action”, with nothing to differentiate one from another. If you really need to find where the workflow that resides in a reusable element is triggered, you need to step through every one of the identical names, performing the search and moving on to the next one. And it’s very easy to accidentally skip over one since you have to scroll through the list of all possible workflows every time.

When you have a substantial app, with dozens of pages and dozens of reusable elements, this becomes a very expensive process.

Seems like a valid concern, @laurence, but it also makes me wonder if some type of naming convention might be helpful.

My current project is far smaller than yours in terms of number of pages and reusable elements, so I don’t know how feasible that is.

I really like your idea of a right-click contextual menu item though! :+1:

I hate this solution, but it seems to work:

Delete the workflow, then step through any issues that are raised. That will take you directly to where the workflow is triggered, whether locally to the containing element or by any other page or element.

Yuck!

The only way this would solve the search problem is by adding to every workflow some phrasing that identifies the context (e.g. reusable element) where it resides. That means making every workflow name harder to read, thus making everyday work in the app unnecessarily tedious, thus wearing down the little gray cells faster, thus bringing on the need for happy hour earlier every day, thus shortening productivity every day AND causing more damage to gray cells, thus leaving more work for the next foreshortened day, thus lending more stress to the beginning of every day, thus doing further damage to gray cells, and on it goes.

For want of a good search tool, the app is lost.

I appreciate the suggestion, but the real problem is the search tool. I use solid naming conventions that help with my productivity. Being forced to use bad conventions to work around a limitation of the development tool is not something I’ll support.

As much as I dislike it, I’d prefer to use the delete and resolve approach mentioned previously (and pointed to below.)

Yeah, it seems some relevant contextual info could be displayed in addition to the name.

1 Like

Agreed!

1 Like