Your CRM stops reading at character 255
Every target field has a ceiling. Some systems reject text that is too long, others keep what fits, throw away the rest and return a success code. What that costs when the field holds a key rather than a comment, and how to handle length limits properly.
Your CRM stops reading at character 255
Text fields have ceilings, and 255 is the one you will meet most often, inherited from the days when the length of a string had to fit into a single byte. Salesforce still caps custom text fields there. The Notion API takes 2,000 characters per text block, a Google Sheets cell holds 50,000. An SMS splits after 160, and drops to 70 as soon as one emoji or curly quote turns up in it.
What matters more than the number is the behaviour on overflow.
Some systems reject the write. Notion returns a validation error, the run stops, the log turns red. Nobody enjoys that, but it is the version you want: you lose a record and you know about it.
Others keep what fits and throw the rest away. No error, no warning, HTTP 201, green run in Make or n8n. Plenty of older ERP interfaces work this way, so do databases in non-strict mode and a fair number of APIs on fields they treat as low stakes. Your automation reports success on data it has just damaged.
The target's own interface then shows the shortened value with no marker on it. To the person in sales support, that is simply what the field contains. When a customer rings up and reads out what they ordered, it sounds like a misunderstanding on the phone rather than an integration fault.
Characters, bytes, and what is actually counted
Below the limit sits a second number that documentation rarely gives you, which is the unit it counts in.
"Straße" is six characters and seven bytes in UTF-8, because ß takes two. An emoji takes four, a composed one takes more. If the ceiling is measured in bytes while you budget in characters, the same text passes for one record and fails for the next. Customer Meyer goes through, customer Müller-Schöneberg does not. From the outside that looks arbitrary, which is why people lose a day to it.
Cut blindly at byte 255 and the cut can land inside a character. The field then ends in a replacement box or a mangled umlaut, and whoever finds it files an encoding bug and searches in the wrong place.
The dangerous cut is the one in a key field
A clipped delivery note is a nuisance. Someone calls, someone looks up the original, the process carries on. We watched that happen this spring at a plumbing supplies wholesaler whose webshop fed order comments into a 60-character ERP field. The drivers started calling because the loading bay instructions stopped halfway through a contact name.
Composite keys are where the same mechanic turns expensive. A workflow builds an external ID from customer number, site and product group so the next sync updates the right record instead of creating a new one. Push that ID past the limit and two distinct values collapse into one. The second customer overwrites the first customer's record. Nothing errors, because as far as the system is concerned the write was valid, and you find out when an invoice arrives carrying someone else's line items.
Email addresses usually fail safely. The truncated address does not exist, the message bounces, you hear about it. The unsafe version is rarer and much worse: cut a long company domain short and you may land on a domain that genuinely exists, in which case the order confirmation goes to strangers and the bounce you were waiting for never arrives.
Signed download links, API tokens, IBANs and tracking numbers belong in the same category. Shortening those is corruption. Free text can be cut; a key that does not fit should stop the run.
When a key has to go into a field that is too short, replace it rather than trim it. A hash of the complete key, cut to the permitted length, stays different for different inputs and fits anywhere. It is unreadable, and it is unambiguous.
In a chain, the shortest field wins
An automation rarely ends at one system. The webshop comment travels through middleware into the ERP, from there into the nightly export for reporting and into the shipping notice sent to the carrier. Every stop has its own ceiling, and the smallest one decides what survives.
What makes this awkward is that every stop cuts again. If the ERP holds 60 characters and the export allows 40, the report shows you 40 and you will read that as the ERP's field length. Fix it there and you have widened the wrong limit.
So we map every stop on a data path, not just the last one. Raise a ceiling anywhere and every stop behind it has to move with it, otherwise the cut simply relocates one hop further down.
Model output has no length guarantee
We build far more workflows now where a language model writes text that goes straight into a fixed field: a ticket summary in the CRM, a short product description in the item master.
"Summarise this in three sentences" is a request, not a constraint. In testing, a short enquiry comes back at 280 characters. In production, a detailed complaint comes back at 900. With a 255-character target field the summary ends mid-sentence, and it does so on exactly the cases that were complicated enough to need summarising. Enforce the length in the workflow, where you control it.
What we settle before a workflow goes live
We write down every target field with its ceiling: field name, limit, unit, behaviour on overflow. It takes half an hour, because the numbers are scattered across vendor documentation and local field configuration, and the list stays accurate for years. Where the documentation says nothing, we send 300 characters through and read back what arrived.
Shortening happens in the workflow, on purpose. Cut at the last word boundary before the limit and append a visible marker, so the reader knows something is missing instead of trusting a sentence that stops early. The full text stays in the source system and the target holds a reference to it.
Testing uses the longest record that actually exists, not "Test 123". One query for the maximum field length in the source produces it in seconds. At the wholesaler that record was a 340-character delivery instruction, complete with opening hours and two phone numbers.
One query tells you whether it already happened
Count the records in the target whose field length is exactly the limit. Text written by people almost never lands precisely on a ceiling. If 900 of 14,000 orders carry a delivery note of exactly 60 characters, that is the shape of the cut. Confirm it by checking whether those entries stop mid-word.
Repair only works from the source, and only while the source still holds the complete value. If the cut already happened on the way into the first system, in a form with a limited field for instance, the rest of that text exists nowhere. Which is the argument for checking early: the longer you wait, the larger the share nobody can restore.
That is how the wholesaler found out, at one order in sixteen since the integration went live. The ERP field was widened to 255, the workflow now shortens on its own terms and writes the customer's full comment into a long-text field alongside. The drivers stopped calling the week after.