A custom table has a reference field pointing to the Configuration Item table. The field must offer only operational configuration items whose support group is a group the logged in user belongs to, and the restriction must apply both in the picker on the form and in the reference list every user opens, without any per user setup. Which mechanism meets this requirement?
- AWrite an onChange client script on the reference field that reads the user's groups and clears the field whenever the chosen configuration item does not match.
- BCreate a read access control rule on the Configuration Item table that grants access only when the record's support group is one of the current user's groups.
- CDefine an advanced reference qualifier on the dictionary entry for the field that calls a script include returning an encoded query built from the current user's groups. Correct
- DAdd a UI policy on the custom table whose condition inspects the support group of the selected item and makes the reference field read only when there is no match.
Why A is wrong: Tempting because it does react to the user's own group membership, but it runs only after a value is chosen on a form, leaves the full list visible in the picker and does nothing for records set by server side code.
Why B is wrong: Tempting because it would narrow what the picker returns, but it also hides those configuration items everywhere else on the instance, which is a far wider change than filtering one reference field.
Why C is correct: Correct, because the reference qualifier is stored on the field's dictionary entry and is applied server side to every query behind the picker and the reference list, so all users get the filtered set with no per user configuration.
Why D is wrong: Tempting because UI policies are the no code answer for many form behaviours, but a UI policy governs field state rather than which records a reference field offers, so the unwanted items stay selectable.