Hoe je STRING_TOO_LONG in Salesforce-deployments oplost

Een waarde die naar een tekst-, picklist- of e-mailveld wordt geschreven overschrijdt de maximale lengte die voor dat veld is gedefinieerd.

Treedt op bij: runtime DML, bij data loads, Apex-tests, en Flow- of Apex-stringlogica

Wat het betekent

STRING_TOO_LONG betekent dat een record-insert of -update probeert meer tekens in een veld te schrijven dan de metadata ervan toestaat. Standaard tekstvelden, picklists en e-mailvelden hebben allemaal een gedefinieerde maximale lengte, en Salesforce handhaaft dit strikt: afkappen gebeurt nooit stilzwijgend.

Standaard Text-velden hebben een limiet van maximaal 255 tekens; alles langer heeft in plaats daarvan een Long Text Area- of Rich Text-veld nodig, wat verklaart waarom deze fout vaak een signaal is dat een veld gewoon het verkeerde type was voor de inhoud die het nu moet bevatten.

Diagnose

Veelvoorkomende oorzaken

Data gemigreerd vanuit een systeem met minder strikte limieten
Brondata, vaak afkomstig uit een legacy CRM of spreadsheet, heeft waarden die langer zijn dan de geconfigureerde lengte van het doelveld.
Veldlengte verkleind nadat er al data bestond
De maximale lengte van een veld is verkleind in een latere deployment, en bestaande of binnenkomende data past niet meer.
Samengevoegde waarden in Apex of Flow
Een formule, Flow of Apex-trigger bouwt een string door meerdere velden samen te voegen, en het gecombineerde resultaat overschrijdt de limiet van het doelveld.

De oplossing

  1. Verhoog de veldlengte als de business case dat rechtvaardigt
    Verhoog de maximale lengte van het veld in metadata als de langere waarden legitiem zijn en het veldtype dit toestaat.
  2. Valideer op het punt van invoer
    Voeg een Flow- of Apex-beveiliging toe die te grote waarden inkort of weigert voordat ze de DML-operatie bereiken.
    String safeValue = rawValue.length() > 255
        ? rawValue.left(255)
        : rawValue;
  3. Controleer gemigreerde data tegen het doelschema
    Vergelijk de lengtes van brondata met de limieten van doelvelden vóór een migratie, niet nadat de load faalt.
In de praktijk

Hoe Serpent dit voorkomt

De CI-pipelines van Serpent voeren een veldlengtevalidatie uit voordat een data load een gedeelde org bereikt, zodat een te grote waarde snel faalt in een pipelinestap in plaats van halverwege een deployment. Zie de bibliotheek met Salesforce-deploymentfouten.

Metadata en data in één deploymentflow in Serpent

Preventie

Kies Long Text Area boven Text voor elk veld dat mogelijk groeit
Kies standaard voor een long text area in plaats van een Text-veld van 255 tekens voor vrije-tekstvelden met onzekere toekomstige inhoud, aangezien later verbreden verstorender is dan meteen breder beginnen.
Begrens samengevoegde strings op de limiet van het doelveld, niet van de bron
Kort expliciet in in Apex of Flow wanneer een formule meerdere velden samenvoegt tot één, met de daadwerkelijke lengte van het doelveld als grens.
Profileer brontveldlengtes vóór elke migratie
Voer een MAX(LENGTH(column))-controle uit op brondata voor elk tekstveld dat wordt gemigreerd, en vergelijk dit met de maximale lengte van het doelveld vóór de load.
Veelgestelde vragen

STRING_TOO_LONG, beantwoord

Geldt STRING_TOO_LONG ook voor rich text- en long text area-velden?
Long text areas en rich text hebben hun eigen, veel hogere limieten en hun eigen fout, TEXT_AREA_LENGTH_EXCEEDED. STRING_TOO_LONG geldt voor standaard tekst-, picklist- en e-mailvelden.
Wat is de maximale lengte voor een standaard Text-veld?
255 tekens is het plafond voor een standaard custom Text-veld; alles langer vereist dat je overschakelt naar Long Text Area of een vergelijkbaar type dat is ontworpen voor grotere inhoud.
Telt Salesforce multi-byte tekens anders voor deze limiet?
Nee. De tekenlimiet is gebaseerd op het aantal tekens, niet bytes, dus multi-byte Unicode-tekens (zoals veel niet-Latijnse schriften) tellen even zwaar mee voor de limiet als single-byte ASCII-tekens.

Start gratis. Geen creditcard, geen installatie, geen verplichting.

Binnen 15 minuten ingericht. Geen DevOps-medewerker nodig.

Benieuwd naar sneller releasen voordat je instapt? Laten we praten

Vrijblijvend.