#CRM Configuration40 debatiendo

Hello, 

In the database the values are stored as IDS so it does makes sense that the list is is simply displaying what is stored. 

There are a few workarounds to this that I can think of of the bat;

(1) Create a formula field that references the name of the related object and then display that formula field in the related list linked to the ID

(2) Try to how to adjust the syntax so you tell the component to display the name for example Contact__c.Name 

You'd have to try option two for yourself as I'm not sure this will actually work, option 1 should work without any issues. 

Thanks Tom

In the Winter '27 release, this new feature can solve what you're looking for: 

Process Multiple Records with Screen Flows from List Views and Related Lists -

https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_screen_mass_quick_action_264.htm&language=en_US&release=264&type=5

I just completed a new screen flow for one of our long-term requests here and it came out beautiful!

Hi Lisa, 

The short version: this is a limitation of standard quote templates rather than something misconfigured on your end, and the reason it looks arbitrary is that the character count isn't counting what you see. 

Rich text area fields store HTML behind the scenes — paragraph tags, line breaks, bold, font styling, all of it. Character limits in quote templates count those hidden formatting characters along with the visible text. So your 195 visible characters plus the markup wrapping them is hitting the renderer's internal ceiling. That's also why the cut-off point moves around between records: content with more formatting truncates sooner, plain content goes further. Your field's 3,000 character limit governs what Salesforce will store, not what the PDF engine will render. 

A quick way to confirm it: take the same content, strip all formatting so it's plain unformatted text, paste it back in and regenerate the PDF. If it runs noticeably further before cutting, markup overhead is your culprit. 

On what to do about it: 

If you can live without formatting, switching to a plain Long Text Area removes the markup overhead entirely and gets you meaningfully more usable characters, with a predictable cut-off instead of a moving one. 

If you need the full 3,000 characters per line item, standard quote templates aren't going to get you there. The usual routes are a Visualforce quote PDF template, where you control the rendering, or a document generation tool — S-Docs, Conga, Nintex DocGen and similar all handle long per-line-item text properly. More work up front, but it's the only way to stop fighting the limit. 

One thing worth ruling out first: check field-level security on that field for the profile generating the PDF. If a field isn't fully visible to the user, it can render oddly or not at all on template PDFs. Less likely given you're seeing partial text, but cheap to verify. 

Hope that helps. 

Lisa — also worth saying: if the extended line item info is genuinely long, it may be worth asking whether it belongs on the PDF as a line item column at all, versus a terms or details section further down. Line item columns are narrow by design and long text tends to look cramped even when it does render. 

This really resonates.

One thing I've noticed is that most benchmarks focus on whether an AI agent can produce the right answer.

In production, that's only one piece of the puzzle.

The bigger questions become: 

• Can it follow business policies? 

• Can it recover from failures? 

• Can it handle long-running workflows? 

• Can you explain every decision it made?

Curious to see how the industry evolves over the next few years.