Skip to main content

Purpose of T() function?

  • August 3, 2020
  • 2 replies
  • 28 views
ScottWorld
Forum|alt.badge.img+35

Could someone please explain to me what the purpose of the T() function is?

I’ve tried using it on a variety of different fields, and it always returns the field value if the referenced field was a text field, and it always returns nothing if the referenced field was a number field.

But — we already knew in advance that one field was a text field, and one field was a number field. So why do we need the T() function? It seems redundant and unnecessary.

Perhaps the one cool thing it does is that it converts Date fields into this format:
2020-03-01T10:30:00.000Z
Which I think might be useful for sending dates to Google Calendar?

2 replies

Justin_Barrett
Forum|alt.badge.img+21

I haven’t used the T() function before. I can see why it might seem useless when you already know what’s coming from a given field. Based on that, my first thought was that it can help you determine the data type when you don’t immediately know what you’re collecting from a field.

However that raised another question: if you’ve designed your base carefully, when would you not know what data a field is sending? Even with a formula field, I want to design formulas to create specific output. Even when there are multiple possible options from a formula, I always know what those are, so I already know if it’s text or not.

Then again, there’s the ever-mysterious lookup field. Sometimes it returns a single value (text or otherwise), but most of the time it returns an array. I suppose that T() could be used as a quick troubleshooting test to see what’s coming from a lookup while you’re setting up a base and expecting text from that field. But once that’s figured out, I’d likely remove T() and go on with the setup. I’m struggling to think of when I might want to actually leave it in a formula.

ScottWorld
Forum|alt.badge.img+35
  • ScottWorld
  • Author
  • Genius
  • August 6, 2020

I haven’t used the T() function before. I can see why it might seem useless when you already know what’s coming from a given field. Based on that, my first thought was that it can help you determine the data type when you don’t immediately know what you’re collecting from a field.

However that raised another question: if you’ve designed your base carefully, when would you not know what data a field is sending? Even with a formula field, I want to design formulas to create specific output. Even when there are multiple possible options from a formula, I always know what those are, so I already know if it’s text or not.

Then again, there’s the ever-mysterious lookup field. Sometimes it returns a single value (text or otherwise), but most of the time it returns an array. I suppose that T() could be used as a quick troubleshooting test to see what’s coming from a lookup while you’re setting up a base and expecting text from that field. But once that’s figured out, I’d likely remove T() and go on with the setup. I’m struggling to think of when I might want to actually leave it in a formula.


Thanks so much for your brainstorming ideas on this, @Justin_Barrett! :slightly_smiling_face:

That’s an interesting idea about using T() as a quick troubleshooting test to see what sort of values you’re getting from a lookup field. Although, like you said, once you figure it out, you probably wouldn’t need to use T() anymore.

Thanks! :slightly_smiling_face:

    Terms & ConditionsAccessibility statement