Skip to main content

I find myself constantly writing a field template to ensure that a non-Name field gets hyperlinked to the Id of the record.  This approach has its shortcomings and also required customized HTML, etc.

Would like to see support added to a component field to “treat” it as a nameField whereby the field in read/readonly mode woulda automatically be wrapped in a hyperlink to the Id of the record.  This would behave exactly the way the “Name” field does today, just be configurable to apply to any field.  I could see this working as a field metadata override (preferred so that you only need to do it in once place) as well as a component field option.

Several different options for achieving this behavior, but adding a declaritive option would greatly simplify the experience and avoid requiring HTML or JS.

Use Case - All of our “Name” fields in our custom objects are auto-numbers and we use an SObject specific field for the “Name” (e.g. it might be called Description__c, it might be called Code__c, it might be called Number__c, etc.).  Anywhere we want to “link” to the SObject, we either need a template or custom renderer currently.  Adding a config option brings us to clicks not code.

Thank you!

Totally I agree. I’ve made custom field renderers to meet this need, but it’s a pain to copy/paste the snippet for each field like this.

To extend on this, it would be great to do this on the field in the model, similarly to metadata override.


After some discussions with Pat, another related idea to further expand on this concept…

We’ve both had the need to NOT have a field that would otherwise be hyperlinked NOT be hyperlinked.  In other words, let’s say a Contact has an Account, we would NOT want the account to be hyperlinked.  This doesn’t come up often but it does come up often enough that we’ve both had to write JS renders to solve for this.

So, to expand on the original idea posted here:

1) Would like a way to “configure” a field that would NOT normally be hyperlinked to be hyperlinked to it’s record Id
2) would like a way to “configure” a field that would normally be hyperlinked to NOT be hyperlinked

Ideally, there would be an option at the model metadata level AND an option at the component field level to support both of these concepts.


Question: Do templates not work for you guys in these cases?


  1. {{{Account.Name}}} makes an NO Link version of the account name.


  2. {{FieldName}} makes any field linkable.

I know there are issues with editabilty here. But just wondering.


Hey Rob -

Yes, field templates work as mentioned in the first sentence of my OP - “I find myself constantly writing a field template to ensure that a non-Name field gets hyperlinked to the Id of the record.  This approach has its shortcomings and also required customized HTML, etc.”

JS based solutions are actually better than field templates as they don’t incur these shortcomings.

The reason for the OP wasn’t that there aren’t alternatives/workarounds, it was that since this is such a common need (at least in my situation and it sounds like Pat’s as well so I would assume there are others), it would be nice to have these added as a declarative option (clicks not code).


Man it really would be a best practice to read the original posts.  Wouldn’t it?  I’m sorry.  

I thought you said “custom renderer”  (which Pat did) and wondered why you went to JS when the template worked.   But you are correct.  The template solution is not optimal… 


No worries, but yep, definitely recommended as a best practice 🙂

For a while I was using templates which worked fine in R/O cases.  As things got more complicated with the UI, I built generic JS renderers to handle both scenarios  (one that removes the link, one that adds the link).  The renderers also make training other page developers more straightforward because you don’t have to explain when you “can/can’t” use a certain approach.  The JS renderers always work so it simplifies T&E as well as provides consistency throughout the code base.

All that said, a “config” option at the model field and component field would be ideal. In doing a quick search of the community, this topic has come up in various forms before.  

Is this something that Skuid would consider in a future release?


I’ll mark it under consideration,  but I can’t really speak to timing. 


Thanks Rob.  Understood on timing, was just looking for an answer on whether this would or wouldn’t be considered at some point.