This tip is specifically for Reference Filters.
Introduction
As a refresher, for reference filters we have to define filter references, where we choose a table and field that references the filter's table. When choosing the field, the OOTB UI validates that it references the filter's table, and rejects it according to the validation's result.
In that scenario, have you ever came across a valid field you need to use, but the validation logic disagrees?
Example One
You have a Sprint [rm_sprint] filter, and you want to filter the Metric [metric_instance] table for metric_instances where the id is the Sprint. The field you need to use is a document id field and CAN be a valid reference to rm_sprint.
Example Two
With a User [sys_user] filter you want to filter the User [sys_user] table for user records where the sys_id is the User. The field you need to use is a GUID field and is a valid reference to sys_user.
The Problem
Both of those examples reflect a valid filtering concept, where the field either completely (sys_id) or could possibly (document id) reference the filter's table, but do you think the validation logic in the field selection UI lets you use them? No, it does not, as it recognizes neither document ids nor GUIDs as potential or valid references, even though they work in practice. Since they work, yet the validation logic does not recognize them, I call these "irregular" filter references, instead of "invalid".
So, what do we do so that we can use these irregular filter references as needed?
The Solution
First of all, these references both can be created with gr.setWorkflow(false) and successfully function as intended when created. So, as admins, we could take up the onerous task of writing an ad-hoc script to insert one every single time we need an irregular filter reference. Quite tedious, however, and also a bad end-user experience for non-platform admins, since there's no delegation of the task to add it to their repertoire. There is a better way.
I propose the creation of a "Create Irregular Reference" UI action for the Interactive Filter [sys_ui_hp_publisher] table that A) asks the user for the table and field, B) validates that the table and field both exist and are potentially valid filters (with a more expansive validation logic), C) enhances the UX by providing as much enhanced context as possible - reminders of what their input(s) were, explanations of and helpful pointers for invalid inputs, disclaimers for complex fields like document_id and glide_list - D) creates the irregular filter references if the validation checks out, and E) is only available for report admins on reference filters.
The Preview
Here are some previews of what the UX of my proposal looks like.
 |  |
 |  |
 |  |
 |  |
 |  |
Conclusion
Combined, this should allow our report admins to use these irregular filter references as needed and provide a good UX for doing so, whose validation logic & role restriction (report_admin) also eliminates much of the risk of this offering. Perhaps somedays SNC will update the validation logic to allow us to use GUIDs and Document IDs as needed, but until then this solution should satisfy your report admins.
I've packaged this for convenience in the attached update set. Enjoy!
