* Sales Cloud - Best Practices *

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.

There isn't really a single "best practice" doc for this, it depends on your sales cycle and how much attribution nuance you want, but here's how most businesses I've seen land on it: 

1. Store the GCLID from the first click and don't overwrite it. Google Ads' own attribution models (data-driven, last click, etc) are built to handle crediting the right click internally, so trying to replicate multi-touch logic yourself in Salesforce is usually more work than it's worth. Some businesses do keep every GCLID as a related record for their own reporting, but that's extra complexity most people don't actually need. 

2. Yes, you still assign the GCLID even if the conversion happens weeks later through a different channel. Offline conversion imports in Google Ads support a conversion window (up to 90 days), so as long as the GCLID and conversion timestamp fall inside that, it gets counted correctly regardless of what touched the deal in between. 

3. Associate it with the contact/lead rather than campaign members. Campaign membership can get reassigned or changed later, but the GCLID is really tied to that person's session, not the campaign object, so it's cleaner to keep it on the person record. 

The one thing I'd flag before you build any of this is volume. You're planning to send back really late-stage events (opportunity created, sale complete), so the real question is how many of those actually happen per month. 

The ad platforms need a decent amount of conversion data to optimise. Google Ads wants roughly 50+ conversions a month, and Meta says 50+ per week to get out of the learning phase. If your late-stage events aren't hitting those numbers, then all the effort of architecting this is largely wasted because the algorithms never get enough signal to work with. 

If that's your situation, you're usually better off sending a conversion when a lead is first created instead. It's a weaker signal in terms of lead quality than a completed sale, but without the volume to feed the platforms, the stronger signal doesn't actually buy you anything. 

Source: I run a conversion tracking SaaS called Converly, which works with Salesforce, so I see this a lot (particularly the volume issue).

Hi @Jaime Blalock -  Unfortunately, the standard Email Template Monthly Engagement report doesn’t expose Account-level fields, and Salesforce doesn’t currently allow a custom report type for that engagement data. 

A practical workaround is to export the report and calculate unique Account IDs externally in Excel/Sheets. If you need this directly inside Salesforce, you would likely need a custom solution that captures engagement against Contact/Lead records and relates it back to Account for reporting. 

It Depends. 

Use Cadences if you're focused on standardizing outreach practices—such as standard follow-ups, periodic check-ins, or onboarding flows for multiple accounts.

Use Sales Account Plans if your goal is to build strategic alignment and planning with individual accounts over the long term. 

It may make sense to use both especially since you need to use work arounds and third party apps to get the Opportunity involved (which is where most of the sales process and customer journey during the closing of a sale occurs). 

To combine the two, create a scalable and repeatable system that helps reps engage consistently day-to-day while aligning with long-term growth strategy for key accounts. 

Is this a use case challenge you are currently facing?  Perhaps I can help.