Misleading Designer search result

Hi, I am doing some analysis to find references to some application objects that I'd like to refactor and have found some misleading results from Designer.

When searching for a rule by name, I was presented with 2 results from the old Designer (/suite/designer), but 1 result from the new Designer (/suite/design).
Additionally, when searching for the same rule by UUID, I was presented with 0 results from the new Designer.

The rule in question has dependencies and has been added to 11 application packages in this environment.

This is making me nervous that my analysis results are not going to include all the results that it should.

OriginalPostID-267832

  Discussion posts and replies are publicly visible

  • I think more information is needed to verify if there's a true issue between old/new designer or if this is a user error. Here are some questions that came to mind.

    1. When you saw the 2 results in old designer, did you bother drilling into both results to see why 2 results with the same name came up? This shouldn't be possible as Appian restricts any 2 (or more) objects from having the exact same name which is done when a user tries to name a rule. Maybe there are similar named copies floating around in the environment.

    2. Could you identify which version of Appian are you working on? It's a long shot, but this could be a version issue..

    3. Are you certain that another user would have not interfered/disrupted your analysis with modifying the object (deleting/recreating the object/etc.) ? I ask because unless the UUID was copied wrong, I find it strange your result would come up 0 given a UUID's uniqueness. If the UUID you have obtained is for the object in question, there should be at least 1 result unless the object was deleted.

    4. When doing your searches in new designer, were you searching with the "Objects" tab selected? It's a tedious question to ask, but just wanted to verify.

    5. Another tedious question, but could you verify that the 2 searches from the old designer view actually have the exact same name by mousing over each search result and seeing the entire object's name? Maybe there's a slight difference in their naming that make them seem to be the same.
  • Thanks for your reply Reginald. Answers:

    1. Yes I loaded both results. There were 2 unique results (one rule name was the 'plural' of the other, i.e. there was an 's' at the end).

    2. Appian 16.3 (on appiancloud)

    3. The latest modification to either rule was in 2015.

    4. Yes, searching from the Objects tab.

    5. They have slightly different names, but have the same prefix.

    I've attached screenshots of the two results (I just re-ran the searches).



  • I found that if I saved a new version of the rule, it would then show up as a search result in the new designer. Possibly indicating an issue with the Search Server not being updated.

    While this workaround has enabled me to get achieve what I needed today, it does make me concerned about other times when a rule search is done via designer and some results are missing.

    Can the search method used by the new designer be updated so it achieves the same results as the old designer?
  • One thing to consider is that the rules might be of different types. Are both of the rules that show up in /designer (old designer) expression rules? And do you have filters turned on in the /design search?
  • @brettf I think they're of the same type. Take a quick look at one of Mike's previous comments that has screenshots.

    @mikej117 I was going to suggest creating 2 test rules of the same type (either via old/new designer) and see if the same end result happens. If the same result happens, then maybe there's an issue with the configuration for the Search Server (I would start here forum.appian.com/.../Search_Server.html) but if not, then I'm not sure what could have been done to 1 or both of those rules to make the search results differ.
  • Thanks for your input guys. I think a refresh/reload of the search server index might fix the issue, but ideally this would be automatically flagged as an issue when the user attempts to do a search against an incomplete index.