When building a filter expression, the search (magnifying glass) feature does not show new values recently added for that particular field (like Group, Category, etc.).
This is by design. The new values will not appear in search results for a particular Xtraction view until the new values appear in at least one record from that view that the user has access to. Even though the value does not appear in the search results, the user can still build a filter expression by manually typing in the value instead of searching for it (see the screenshot below).
The short explanation is that it works this way to simplify the security configuration.
The longer explanation is that a primary focus of Xtraction is to keep every aspect of Xtraction as simple as possible. We often times have to strike a balance between functionality and simplicity. In this case, the filter search results work the way they do in order to greatly simply the configuration.
Probably the easiest way to understand it is to look at an example:
A service provider stores the service management incident data from many customers in one table. When each customer looks at a dashboard, they should only see the results based on their own data. A customer should never see another customer's data. So, a security policy for Customer A is put into place where the Incident view only includes records where the Customer field is "Customer A". Perfect. Now, when Customer A goes to design a dashboard and wants to report on a specific group, they go to search on that group. At this point, the service provider wants Customer A to only see Customer A's groups and not the groups of all the other customers. This would most likely be true of other fields, like contacts, configuration items, categories, locations, cost centers, etc. Other fields, like priority, might be common across all customers.
One way to limit what a customer sees for the Group field would be to establish the rule for limiting what is displayed. But, that rule would also have to be created for every other field that needs to be limited. This could result in dozens (or even hundreds) of security rules for each Xtraction view. This would NOT be a simple process to set up.
So, we went a different route. Continuing with the above example, if Customer A is restricted to only seeing their own incidents, then the only thing we know for sure is that they should be able to see the information related to their Incidents. If a particular group is assigned to their tickets, presumably they are able to see that group. If a particular group is not assigned to any of their tickets, that could be because the group is not relevant to them (it belongs to another customer) or the group is a valid group for them and they simply don't yet have any tickets assigned to that group. So, if we filter all "filter searches" to only show values actually found in the incidents that Customer A has access to, they will only ever see values that definitely apply to them. The trade-off is that they won't see other values that are valid but have yet to been used in their tickets. In this way, only that initial security filter is required: Customer A can only see Customer A's incidents. When Customer A builds a filter expression for incidents and does a lookup search, all lookup searches are filtered through their incident records. This makes for a very simple security setup with a minor loss of functionality. And, even though a particular value may not appear in the search results, the filter expression can still be created by simply manually entering the value, as shown in the screenshot above.