Version: eXtendFiles all versions
Audience: Administrator

Use Case

You want customers to upload files from a webstore or public web form and have those files end up on the correct NetSuite record so that they are part of the record’s workflow.

In many webstore/integration setups, the webstore can capture the details before a corresponding NetSuite record exists. That creates a timing problem: eXtendFiles Public Upload needs a specific NetSuite record to attach uploaded files to.

Cause

eXtendFiles Public Upload depends on and relates files directly to an underlying NetSuite record (such as a Quote/Estimate, Sales Order, or a custom record). That underlying record provides the record ID for the attachment as well as the metadata needed to process the upload.

Because of that, a “recordless” upload (uploading a file with no NetSuite record to attach it to) isn’t currently possible for eXtendFiles Public Upload.

Solutions

Use one of the patterns below depending on when the NetSuite record exists in your workflow.

Option 1: Create the NetSuite record first, then use Public Upload to attach files

This is the simplest approach when you can create a NetSuite record early.

  1. Have the integration (or a lightweight script/endpoint) create a NetSuite record as soon as the webstore order is started.
  2. Store the generated NetSuite record information somewhere the web experience can reference (for example, in a hidden field, session value, or integration payload).
  3. Present the user with the eXtendFiles Public Upload link/page that targets that record.
  4. The uploaded files land directly on that record in NetSuite.

Option 2: Upload to a “staging” NetSuite record, then move/copy files to the final transaction

This is a good fit when the final record doesn't exist yet, but you still need to accept files immediately.

  1. Create a dedicated “staging” record in NetSuite (often a custom record like “Web Upload Session” or similar).
  2. Use Public Upload to attach files to that staging record with a unique identifier that identifies where the file will later be associated.
  3. When the webstore/integration later creates the true record, run an automation/script to re-associate the files from the staging record to the final transaction.
    • This can be done by moving/copying the file relationships depending on how you want to preserve history.

Option 3: Upload files to the NetSuite File Cabinet, then use the eXtendFiles Migration service

This approach works well when files can be captured in the NetSuite File Cabinet from the webstore or online form and later migrated to your eXtendFiles storage. Note that eXtendFiles File Migration services require separate scoping and implementation as an add-on service.

  1. Capture file uploads directly to the NetSuite File Cabinet from your webstore or online form.
  2. eXtendFiles migration runs as a scheduled process, looking for newly created files linked to records from your webstore or online form.
  3. These files are migrated to your eXtendFiles storage, connected to the linked NetSuite record, and then deleted from the NetSuite File Cabinet.

Frequently Asked Questions (FAQs)

Q: Can we allow customers to upload files from our website without logging into NetSuite?
A: Yes. That's typically done with Public Upload. The key requirement is that the upload must still target a specific NetSuite record (or staging record).

Q: Can eXtendFiles accept uploads if we don't have a NetSuite record yet?
A: Not directly. eXtendFiles needs an underlying record to attach the file to. If you don't have the final record yet, use a staging record (Option 2) or create the record earlier (Option 1).

Q: Does this depend on the webstore/integration?
A: Usually, yes. The integration design determines when a NetSuite record exists and whether you can store/reference the NetSuite internal ID (or a staging record ID) to make Public Upload work reliably.