I branched this off to it's own discussion as it was not part of the original question.
I am not exactly sure what you are attempting to achieve as you are mixing in Entitlements with SR Variable mappings and conditions which are 2 separate functionalities.
Entitlements are done at the SRD level and not part of PDT variable and conditions so a answer to a question cannot determine who can see the Service Request in the catalog.
Entitlements however are highly configurable and can base these on Company, Individual Username, Group (group of individual users), Location or use an Advanced qualification.
If talking about routing within the PDT using Conditions, as there is a Yes/No path you can base your Conditions on the SR Fields by populating a variable for use within the condition. You can also concatenate more than one field into a variable, so you can make use of say Country and Site in the one variable. You conditions can include more than one qualification check, thus being able to reference several "Countries" in the one condition.
E.g. var_Site = "United States" OR var_Site = "Australia" OR ..... etc
The SR_Field dropdown on the Mappings tab will show what fields are available from the SR for use with the variable mapping. Again you could also use a question if the actual field you are after is not available OOB (noting that some of these fields are not shown to the user on the Service Request).
You have a lot of flexibility with what you can do, let us know if this does not cover your scenario.
I am aware that I was making references to both entitlement rules as well as SR variable mapping and completely understand that they are two different pieces of functionality. All I was trying to do was demonstrate how I am able to configure an entitlement rule based on "country" to restrict upfront access to some SRs . . . but unable to use a similar "country" field within the actual SR to control conditional routing within the PDT. :-)
I suppose what my question really comes down to is how easy/difficult would it be to map the requester's "country" to one of the 47 generic SR fields (SR Type Field 1-47) . . . thus keeping it hidden from the user and not requiring a question prompt within the request . . . but ultimately allowing me to reference the field and use it for PDT conditional routing. This would seem to be the only way to handle this requirement since Site Country isn't one of the many fields on the SR available for mapping.
Hopefully that makes sense. As always, I appreciate your great insight!!
as that field does not exist on the SRM:Request form, you would have to customise the form to add the field then update the workflow to populate this field on Submit (as the DVF for a normal Service Request is a compiled jar file and you cannot send additional fields).
You would then need to add the new field to the SYS:Form Field Selection data to be able to see this field in the dropdown menu for the "SR Field" Mapping option.
Alternately, the use of a AIF would allow for you to capture the Country Details and map down to a SR Type Field.
I suggest you raised this as a enhancement to BMC to include the "Country" as OOB.