SDF Project Scope and Deploy Ordering Across Four Accounts
Halcyon Retail runs NetSuite production plus a sandbox refreshed from production every 30 days, and two acquired brands operate in separate NetSuite accounts. A developer builds a SuiteCloud Development Framework account customization project containing a custom record customrecord_halcyon_promo with two custom fields, a user event script customscript_halcyon_promo_ue whose source looks up that record by scriptid, a script deployment record, a client script, and a workflow. Running suitecloud project:deploy against the sandbox fails on the first object with a message that the object references a nonexistent object, and the log shows the user event script was processed before the custom record. After manually reordering the objects, the sandbox deploy succeeds and nobody edits the project again. The same project then fails in a brand account at the client script with a permission error for the deploying role, and the workflow never appears in that account. The team wants one repeatable pipeline for all four accounts.
1. Why did the sandbox deployment fail on object order, and what should change in the project so ordering is handled without manual reordering?
Read the worked answer
The failure is a dependency-resolution gap, not a bug in the custom record. SDF builds a deploy order from references it can see between objects in the project, but a scriptid embedded as a string inside a JavaScript file is invisible to that analysis, and the script record can therefore be queued before the object it names.
What to change:
- Treat script source references as declared dependencies. Either keep the dependent objects in a separate, later deployment (a base project with record/field/list objects, an automation project with scripts and deployments), or maintain an explicit
deploy.xmlorder and stop letting the tool regenerate it. - Run a validation pass against the target before the real deploy so reference errors surface without a half-applied project.
- Prefer scriptids over internal IDs everywhere, since internal IDs differ between the sandbox and the brand accounts.
- Do not rely on manual reordering: a one-time fix in the manifest is lost the next time the project is regenerated, which is exactly the failure mode that will hit the brand accounts.
Manual reordering also masks the real risk. If the project only deploys when a human fixes the order, the pipeline cannot run unattended, and the failure will reappear on the next new object.
2. Is an account customization project the right vehicle for all four accounts? Recommend an approach and state what must change.
Read the worked answer
No. An account customization project is designed for a single account and its sandboxes; it is not the distribution mechanism for shipping the same content to unrelated accounts. The symptom set already reflects this: the sandbox succeeds, then a different account fails at a permission error and silently skips the workflow, because the target account's feature enablement, role, and object support were never part of the model.
Recommended approach:
- Move distributable content into a SuiteApp project and ship it as a bundle with a stable bundle ID and a version. Bundles are the supported path for installing the same objects into many accounts and upgrading them later.
- Keep an account customization project per account for genuinely local content layered on top of the bundle (subsidiary-specific fields, local approvals), never as the source of truth for shared objects.
- Before committing, confirm each object type in the project is supported for packaging. SDF coverage of workflow objects is narrower than for records and fields, so the workflow may need to be excluded from the bundle and created another way, or simplified until it is supported.
- Add a bundle installation script so install-time configuration (preferences, default values) is repeatable rather than a runbook step.
The decision rule: one account or one account family means customization project; many unrelated accounts and a lifecycle means SuiteApp and bundle.
3. The brand account deploy fails at the client script with a permission error. What do you check first, and in what order?
Read the worked answer
Work from the environment outward, because the cheapest causes are also the most common.
- Feature enablement in the target account. Client SuiteScript and Server SuiteScript must both be enabled before script records and deployments can be created. A brand account provisioned for finance users may never have had them turned on.
- Role permissions for the deploying identity. The role needs the SuiteScript permission, plus permissions on Script Deployment, Custom Record Types, and the objects the scripts touch. If script files live in the File Cabinet, file access matters too.
- Object-level permissions on referenced records. A client script that reads a field on a custom record fails if the role cannot see that record, and the message often surfaces as a generic permission error against the script.
- Deployment status and audience. A deployment in Testing status only runs for the audience roles, which looks like a broken script during testing.
- Only then read the script log on the target account; the stack trace usually names the object that was actually denied.
Do not fix this by granting administrator to the deploying role. Capture the required permissions in a role definition deployed alongside the bundle, so the fourth account does not repeat the same failure.