Four SDF deploy errors and what they actually mean
SDF validation is strict and its messages are literal. The fix is usually one line. Finding the line is the problem.
Building customizations as SuiteCloud Development Framework projects means everything — custom records, fields, scripts, deployments — is XML, validated before anything reaches the account. Validation is a gift. The error messages are less so. Four we hit, with what each one means.
1. LONGTEXT is not a field type. CLOBTEXT is.
The UI calls it Long Text. SDF doesn’t:
<fieldtype>LONGTEXT</fieldtype> <!-- rejected -->
<fieldtype>CLOBTEXT</fieldtype> <!-- Long Text in the UI -->Same field, same capacity, different name. If you generate object XML from a script, fix it in the generator so it doesn’t come back.
2. Features you depend on must be declared
A project with custom records and server-side scripts can fail validation complaining about elements that need a feature. Declare what the project requires in manifest.xml:
<dependencies>
<features>
<feature required="true">SERVERSIDESCRIPTING</feature>
<feature required="true">CUSTOMRECORDS</feature>
</features>
</dependencies>The related trap: declaring a feature ID that doesn’t exist, or one with a slightly different spelling, also fails. Copy feature IDs from a project that deploys rather than typing them from memory. Some optional elements on custom records, such as mail-merge flags or numbering settings, also trigger feature warnings; if you don’t need them, leave them out.
3. <setting> is not valid on a script parameter
Script parameters are scriptcustomfield objects inside the script XML. They look like other custom fields, and it’s tempting to copy elements across. One that doesn’t belong:
<scriptcustomfield scriptid="custscript_example_limit">
<fieldtype>INTEGER</fieldtype>
<label>Batch limit</label>
<setting>SCRIPT</setting> <!-- remove: invalid here -->
</scriptcustomfield>4. Mandatory parameters need a value on every deployment
Mark a parameter mandatory and every deployment of that script, in the same XML, must give it a value. Leave one deployment without it and the whole project fails validation:
<scriptdeployment scriptid="customdeploy_example_weekly">
<status>SCHEDULED</status>
<custscript_example_limit>500</custscript_example_limit>
</scriptdeployment>If a parameter genuinely has a sensible default, it often shouldn’t be mandatory at all: make it optional and default it in code.
The habit
Run project:validate before every deploy, and read each error as literal. SDF isn’t vague; it names exactly the element it rejects. The trouble is only that its vocabulary isn’t the UI’s.
Related: SuiteScript 2.1 before the deadline, and fixing “(intermediate value).warn is not a function”.