SDF Deployment Tutorial Part 2: Creating Your First SDF Project and Understanding the Project Structure

Welcome to Part 2 of our SDF Deployment tutorial series. In Part 1 we set up the SuiteCloud CLI, installed the prerequisites, and confirmed access to a NetSuite account. Now we’ll create our first Account Customization Project (ACP), explore the folder structure SDF generates, and add a small custom record so you can see how everything fits together.

What You’ll Learn

How to scaffold a new Account Customization Project with the SuiteCloud CLI, what each folder and file in an SDF project means, how to add and validate a simple custom record, and how to keep your project ready for source control from day one.

Step 1 — Create the Project

From your workspace folder, run: suitecloud project:create –type ACCOUNTCUSTOMIZATION –projectname MyFirstSDFProject –publisherid com.mycompany –projectversion 1.0.0. The CLI will create a new folder containing the standard SDF project skeleton.

Step 2 — Tour the Project Structure

The src folder is the heart of the project. Inside it you’ll find Objects (XML definitions for custom records, fields, scripts, workflows, roles), FileCabinet (mirrors the NetSuite File Cabinet folder structure for scripts and templates), Translations (translation collections), AccountConfiguration (account-level settings like features and preferences), deploy.xml (declares what gets deployed and in what order), and manifest.xml (declares project metadata, dependencies, and required features).

Step 3 — Link the Project to an Account

Inside the project folder, run suitecloud account:setup and pick the authID you created in Part 1 (for example, sandbox-dev). This links the project to that NetSuite environment so deployments and imports target the right account.

Step 4 — Add Your First Custom Record

Create src/Objects/customrecord_blog_demo.xml with a basic customrecordtype definition. Give it a scriptid of customrecord_blog_demo, a recordname of Blog Demo Record, and add a single text field called custrecord_blog_demo_name. Then register the object in deploy.xml so it gets included in the next deploy.

Step 5 — Validate Before You Deploy

Run suitecloud project:validate. Validation catches missing dependencies, invalid scriptids, and schema errors before they reach NetSuite. Fix any errors it reports, then run suitecloud project:validate –server to run the same checks against the linked account.

Step 6 — Initialize Git

Run git init in the project root and add a .gitignore that excludes the .suitecloud-sdf folder, node_modules, and any local credential files. Commit the initial project so you have a clean baseline before importing existing objects in Part 3.

Common Pitfalls

Forgetting to register new objects in deploy.xml is the most common mistake — if a file isn’t listed, SDF silently skips it. Another frequent issue is using scriptids that don’t follow NetSuite’s naming rules (lowercase, underscores, customrecord_ prefix). Finally, never commit the cached credentials folder to source control.

Up Next

In Part 3, we’ll import existing customizations from a live NetSuite account into your SDF project so you can bring legacy work under source control. See you there!