@Rex Kenley Tan I have attempted to stay away from this because of cross environment issues with new records. I promote changes from DEV to UAT, and then to Prod. In the case of a new record, lets say a category, if i make the record in DEV, and then code against the GUID, when i promote, the GUID changes because I have to recreate in UAT the record. Once ultimately in Production, I would have changed by hardcoded GUID 3 times, which can be a pain.
The other issue, is if the referenced GUID record is deleted (hopefully not...) or if the referenced record needed to be changed. In both of those instances you may have a hard time tracing all the instances you referenced a hardcoded GUID over a field (even hidden) that could dynamically set the attribute, retrieved over the API, and could update dynamically. Generally, that is my approach when coding is to create fields to provide me with a way to retrieve the record and just not place the fields on the form, and hide them from search, that way i can update the records as needed without having to go back to my code base.I am interested in what other people think on this as well.
If you've found this thread useful, dive deeper into User Group community content by role