I am trying to create a segment where the identities have an “IT”-related job code and the entitlements have a metadata attribute (multi-values) of “IT”. When I try to search on the “Define Access” screen, I am either told the search is invalid or I get no results. When I use the same search in the “main” search screen, I see what I expect. How is the search on the “Define Access” different from the search on the main menu?
This works in the main search page:
@accessModelMetadata(name:“Segments” AND value:“IT”)
But in the “Define Access” screen, I see:
Your search query is Invalid. For more information please refer to:Building a Search Query
A post I saw had a different format so I tried:
accessModelMetadata.key:“Segments” AND accessModelMetadata.value:“IT”
With this, I do not get an error, but I also do not get any results. Can someone guide me on the format?
The search syntax available in the Define Access screen is more restrictive than the global Search page. Not all search operators and nested query formats are supported there.
Since your query works in the main search but not in Define Access, it’s likely that:
@accessModelMetadata(name:"Segments" AND value:"IT")
is supported by the global search engine but not by the segment definition UI.
A few things I’d check:
Verify that Segments is indexed as access model metadata for the entitlement objects you’re targeting.
Try searching on a single field first (e.g., just the value) to confirm the metadata is visible in Define Access.
Check whether Define Access expects the metadata field name exactly as indexed (sometimes name vs key differs).
I’ve seen cases where queries that work in Search do not work in Segment/Define Access because those features use different query parsers and supported fields. If accessModelMetadata.key:"Segments" AND accessModelMetadata.value:"IT" returns no results, I’d inspect one of the entitlements via Search/API to confirm the exact metadata structure being indexed.
My suspicion is that this is a limitation of the Define Access search syntax rather than an issue with your metadata itself.
The Define Access screen in segments seems to use a more limited search compared to the main Search page. That’s most likely why @accessModelMetadata(name:"Segments" AND value:"IT") throws “Invalid” there even though it works fine in main Search. I don’t see this documented anywhere, but based on your experience it’s pretty clear the nested @ syntax isn’t supported in that screen.
The dot-notation version (accessModelMetadata.key:"Segments" AND accessModelMetadata.value:"IT") returning nothing also makes sense. The searchable fields doc says metadata attributes on entitlements are nested objects, and nested objects need the @ syntax to match the key and value within the same entry. Dot notation on its own won’t tie those two fields together properly.
What I would try as the quickest path: run your metadata query in main Search, filter to Entitlements, confirm the list looks right, and then go back to Define Access and add those entitlements by name. Should work fine if the number is manageable.
If the list is large, the API route might be worth looking into. You could use the Search API (POST /v3/search, index entitlements) with your working @accessModelMetadata query to pull the entitlement IDs. Then you can PATCH each entitlement to assign the segment. The segments field is patchable. I would recommend doing a GET on one of the entitlements first to see how the segments field is structured in the response, and then build your PATCH payload to match that format. The segments field is also patchable on access profiles and roles, so the same approach should work for any of those.
Also give it some time after saving the segment. Segment changes can take time to show in Request Center, and entitlements can take a little longer than roles or access profiles.