#CRM Configuration토론 중인 항목 43개

@mathew0406 micheal

Of all the things to do in the world, literally ALL of the the options available (here's just a few)     

• Teach a child to read 
• Help an elderly person
• Donate to a food pantry
• Adopt an animal from a shelter 
• Plant a tree

Instead, you chose to post spam in this Community.  Your parents must be so ashamed of you.

@Kanishka Vohra

Of all the things to do in the world, literally ALL of the the options available (here's just a few)     

• Teach a child to read 
• Help an elderly person
• Donate to a food pantry
• Adopt an animal from a shelter 
• Plant a tree

Instead, you chose to post spam in this Community.  Your parents must be so ashamed of you.

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.