Catalog item "Please select position" lookup returns "none" for a valid HR job record — OOB HR Security Data Filter restricts visibilityIssue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } A catalog item variable (reference/lookup select box) that queries the sn_hr_core_job table — for example, a "Please select position" field driven by a reference qualifier such as: job_active=true^user=<requested_for_sys_id> returns no matching record ("none") for some target users, even though a job record clearly exists for that user and the ACL evaluates as passing when checked directly. The same catalog item, run against a different target user, correctly returns their position. This can look like a version-to-version regression, or a broken reference qualifier/ACL, since the ACL itself does not appear to block the query. Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Any Cause<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Record-level visibility on sn_hr_core_job is governed by an out-of-the-box HR Security Data Filter (sys_security_data_filter_1d9bbfeb7f085210a2e502284d866518), separate from and in addition to the table's ACLs. The filter shows a job record to a requesting user only if: the requesting user is the user on the job record, or is that user's manager, unless the requesting user holds one of these roles, either of which grants broader visibility regardless of the self/manager relationship above: sn_hr_core.managersn_hr_core.profile_reader Because this is a data filter, not an ACL, it silently narrows the result set at query time — the ACL check alone (e.g. via GlideRecord + manual ACL evaluation) will appear to pass, which is what makes this look like a bug rather than by-design behavior. The ACL is not blocking; the data filter is filtering rows out before the ACL is even evaluated against them. How to confirm this is the cause (not a defect): Identify the acting/requesting user and the target "requested for" user's sys_id.Check whether the acting user is the target's self or manager, and whether they hold sn_hr_core.manager or sn_hr_core.profile_reader.Impersonate the acting user and query sn_hr_core_job directly for the target's record (list view or background script). If none of the above conditions are met, zero rows is the correct, expected result — not a bug.Repeat with a target user who does satisfy one of the conditions to confirm the same filter returns the expected row, isolating the variable to the requester/target relationship rather than environment/release. Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } No code defect exists — this is expected OOB HR data-visibility design. Two remediation paths depending on the customer's actual requirement: Educate requesters on eligible targets. Clarify that the lookup will only populate for people the requester is the self/manager of, or when the requester holds sn_hr_core.manager or sn_hr_core.profile_reader. Outside those conditions, "none" is expected, not an error.Extend visibility via the filter. If broader access is genuinely required for the workflow (e.g. HR admins/delegates submitting on behalf of employees outside their own reporting line), the platform admin can add a new security attribute/custom role to the Security Data Filter — alongside the existing sn_hr_core.manager and sn_hr_core.profile_reader roles — and grant it only to the specific users who need the additional access. This preserves the OOB self/manager rule for everyone else while opening visibility for a defined, controlled set of roles.