Notes Cut Off at 255 Characters After a Sync

A note that arrives shortened is not one bug. A receiving system does one of four things with a value that is too long for the field: it rejects the write and blocks the record, it clips the value and keeps going, it drops the value entirely, or it stores the whole thing and only shows you part of it. Which one you get depends on the receiver, not on how long the text was, and the standard advice to "add a truncate step" is the right fix for exactly one of the four. The case to fear is the quiet clip inside a two-way sync, because the shortened copy goes back as a fresh edit and overwrites the original.

Four things a receiver does with text that is too long

Every limit in the table below comes from the vendor's own documentation, checked September 2026. The column that matters is the last one.

Receiver	Limit	What happens at limit plus one
Salesforce Text, Text Area	255 characters	Rejected. The API returns STRING_TOO_LONG and the record does not save.
Salesforce Text Area (Long)	131,072 characters, default 32,768 at creation; each Enter counts as two	Rejected at the API. Reports and formatted exports show only the first 255 characters of a custom field (999 for a standard one), but the stored value is whole.
PostgreSQL varchar(n)	n characters, not bytes	Rejected with an error, unless the excess is all spaces. An explicit cast to varchar(n) clips silently instead.
MySQL VARCHAR(n)	n characters	Rejected in strict mode, which is the 8.4 default. With strict mode off, clipped to fit with a warning.
Google Sheets cell	50,000 characters	On Excel import, a cell over the limit is removed, not clipped. The value is gone.
SharePoint single line of text	255 characters	A Power Automate flow writing a longer Forms answer into it fails.
Airtable single line and long text	100,000 characters	Airtable documents that edits at or near the limit can fail with a generic error or an unresponsive page.

Read the last column as a classifier. Rejection is loud: somebody sees a failed run, a sync error, or a red row within the hour. Display truncation is harmless: the record is fine and the person who complained was looking at a report. The dangerous middle is the silent clip and the silent drop, because the run reports success, the record exists, and the only evidence is a note that ends mid-sentence, which nobody reads until a technician is standing in a customer's basement asking why the gate code is missing.

MySQL is the row worth staring at. The same table behaves as a rejecter or a clipper depending on one server setting. Strict mode is the default in 8.4, but a database inherited from an older install or a hosting panel that ships a permissive sql_mode will take your 600-character note, keep 255, and file a warning that no automation platform ever surfaces. PostgreSQL has the same split in a different place: the write fails by default, but any query that casts the value to varchar(255) on the way in clips without a word. PostgreSQL notes that both of its exceptions, the trailing-space clip and the cast clip, are required by the SQL standard, so neither is a bug you can report.

Where the oversized value came from

Long values enter a pipeline from a few predictable places, and the source usually has a larger limit than the target, or no limit at all.

Forms are the biggest one. HubSpot documents that a single-line or multi-line text property holds 65,536 characters when edited in the CRM, and when the value comes in through a form, there is no limit. So a "tell us about the project" box on a landing page can produce a value the CRM's own editor could not create, and the first system to enforce a limit is whatever the form syncs to. A Microsoft Forms long answer allows 4,000 characters and a SharePoint single-line column takes 255. A HubSpot multi-line note mapped to a Salesforce Task Subject hits the same wall at the same number.

Accounting systems are the second. QuickBooks Online's invoice API documents a 1,000-character customer memo, a 4,000-character private note, and a 21-character document number. A field app that lets a crew write freely in a job notes field, then pushes those notes onto the invoice, exceeds the memo limit on the first job with a complicated access instruction. This is the shape we design for in field operations systems that move crew notes into billing: the notes field in the field tool is effectively unbounded, and the invoice memo is the first place anyone wrote down a number.

AI steps are the newest source. A summarization or drafting step has its own output length, which is measured in tokens and set by a completely different knob, and nothing ties it to the character limit of the field it lands in. An "AI summary" property populated by a model that was asked to be thorough is a 3,000-character value heading for a 255-character field.

The clip that syncs back over the original

Here is the failure that turns a cosmetic problem into data loss. A CRM holds a 2,000-character note. A sync copies it to a second system whose field clips at 255, silently. That write updates the second system's modified timestamp. On the next pass, the sync sees a newer edit on that side, carries the 255-character version back, and overwrites the 2,000-character original. The full note now exists nowhere except, maybe, in field history.

Maybe is doing a lot of work in that sentence. Salesforce documents that when a field longer than 255 characters changes, field history records only that the field was edited and does not store the before and after values. So the audit trail confirms that the note used to be different and cannot tell you what it said. Other systems keep property history with values, but you should verify that for the specific field before you count on it.

The rule that prevents this is short. A field that gets clipped anywhere must not participate in a two-way sync. Either make the clipped copy write-only, meaning the sync never reads that field back from the receiver, or stop clipping it and route overflow some other way. If you already have a bidirectional sync on a notes field, this is the same conflict an overwriting two-way sync produces from concurrent edits, with the twist that here the "edit" was made by your own integration.

Which unit is the limit measured in?

Three different units hide behind the word "characters," and a length gate written in the wrong one passes clean on plain English and fails only for some customers.

PostgreSQL and MySQL count characters for the column length, though MySQL's row size ceiling of 65,535 bytes is shared across all columns and depends on the character set. HubSpot's rich text property limit is 64 KB, a byte count that includes embedded images. JavaScript, which is what runs inside a Code step in Zapier, Make, or n8n, counts UTF-16 code units: MDN documents that a single emoji has a length of 2 and that the count can differ from the number of Unicode characters. That same emoji is 4 bytes in UTF-8. Salesforce adds a wrinkle of its own by documenting that every Enter pressed in a long text area adds a line break and a return character, both of which count toward the limit, so a 200-line note carries 400 characters of line endings that a source counting a single newline per line does not see.

The practical consequence is the same one that shows up when accented characters arrive garbled: a check that is correct for ASCII is wrong for exactly the rows containing names like José or a thumbs-up in a customer's message, so it fails rarely enough to survive testing and often enough to matter. Write the gate in the receiver's unit, and run one test before going live: send a value of exactly the limit plus one, containing at least one accented letter and one emoji, and watch what the receiver does. That single write tells you which of the four behaviors you are dealing with and whether your count agrees with theirs.

Decide per field what overflow does

Once you know the receiver's behavior and unit, truncation becomes a decision you make at the hop instead of a side effect you discover later. There are three acceptable answers, chosen by what the field is for.

Clip with a marker for fields that are previews. Email subject lines, task titles, SMS bodies, and list-view columns exist to be scanned, and losing the tail costs nothing as long as the full text lives somewhere reachable. Clip to the limit minus the length of your marker, append the marker, and put a link or record ID to the full text in the same payload. Zapier's Formatter has a Truncate transform with a max length and an optional ellipsis for exactly this. An SMS is the extreme case, since a long body does not get clipped so much as split into segments you pay for, which is why automated texts that stop delivering need a length gate of their own.

Split into an overflow field for fields that must arrive whole but cannot fit. Airtable's own guidance for a long text field near its cap is to move part of the text into a second field. The same pattern works for a 255-character target: write the first 255 to the mapped field and the remainder to a companion field or an attached note object, and make sure the receiving side's readers know to look in both. This is the answer for notes that need to be searchable in the receiver.

Reject to review for fields that are load-bearing. Access instructions, safety notes, scope-of-work language, anything a customer or a crew will act on, cannot be shortened by a rule that does not know what it is cutting. A clip that removes "do not enter through the side gate, the dog is loose" is not a formatting problem. Route the record to a review queue with the field name and the two lengths attached, the same way a blank merge field should block a send rather than render a wrong message. Blocked is not dropped; the record must land somewhere a person will see it, with enough context to fix it in one step.

Whichever branch you pick, log the length before and after the hop. A pre-clip length next to a post-clip length is the cheapest signal in an automation's run record, because a ratio that drifts toward zero over a week tells you a source started producing longer text long before anyone reads a clipped note.

Where to start

List every text field in each sync where the source limit is larger than the target limit, or the source has no limit at all. Forms feeding CRMs and notes feeding invoices will be most of the list. For each one, run the limit-plus-one test and write down which of the four behaviors the receiver showed, then mark the field as preview, overflow, or load-bearing. Any field that is currently clipped and also part of a two-way sync gets fixed first, because that one is losing data today.

If the list runs longer than a dozen fields across a CRM, a billing tool, and a field app, the limits are a symptom of nobody owning the shared record layout, which is the work behind workflow automation systems built around one data model rather than a stack of connectors. If you want a second opinion on which fields should be allowed to clip, tell us what you are syncing.