A NetSuite attachment integration must manage both the file and its relationship to the business record. Uploading a document successfully does not prove that the right user can open it from the right transaction, that a retry will avoid duplicates or that the file remains private.
Define file ownership, record linkage, access, versioning and recovery before building the flow. This guide covers the decisions that matter when documents move between NetSuite and another business system.
Identify what the document proves and who needs it. A supplier invoice, delivery confirmation, customer agreement and public product image have different audiences and handling requirements.
Decide which system holds the authoritative copy. The integration may copy content into NetSuite, retain a controlled external link or move metadata while another repository owns the document. Each choice needs a clear access and retention design.
Record whether users need the original file, the latest approved version or the exact version associated with a transaction at a point in time. “Always show the newest file” can be wrong for evidence tied to a signed agreement or an approved invoice.
Oracle's current File Cabinet REST documentation supports working with file and folder records through the document service. It describes synchronous execution and a 10 MB upload and download limit for that service. Confirm the operations, payload format and account behavior needed for the actual flow rather than relying on older claims that File Cabinet REST is unavailable.
Check the complete path: create or locate the file, obtain its identifier, attach it to the intended record and verify access. A connector may support some of these operations but not expose all of them in the same way.
For a larger file or an unsupported operation, evaluate an approved alternative. Do not split or transform an evidentiary document merely to fit a limit without agreeing how the business will use and verify the result.
Oracle's REST attach and detach operations define relationships between record instances, including supported file relationships. They are separate from creating the file content itself.
Track the stages explicitly:
If upload succeeds but attachment fails, retrying the whole process can create another file. Recovery should first locate the existing uploaded content and complete the missing relationship where appropriate.
Keep a durable source document identifier, target file identifier and target record identifier together. File names alone are weak duplicate keys because different documents can share a name and a legitimate new version may reuse the old name.
Decide what should happen when the source sends the same document twice, a new version of the document or a different document with identical content.
A content fingerprint can help detect repeated bytes, but it does not establish business meaning on its own. Two records may legitimately reference the same file; two versions may have different approval status even when the visible filename is unchanged.
Use an explicit version policy. Possible choices include preserving each approved version, replacing a controlled working copy or linking to a repository that maintains the authoritative history. The business owner should approve which behavior applies to each document class.
Document how a removed or superseded source document affects NetSuite. Deleting a source file should not automatically remove required transaction evidence unless that behavior is authorized and consistent with retention obligations.
Oracle explains that File Cabinet access can depend on folder permissions, the user's permissions and the related record. Some users without general Documents and Files access can still open a file through a supported relationship to a record they can access. Test the actual route the intended user will take.
Folder restrictions also have inheritance details. Oracle notes that changing a parent folder's restriction does not automatically update an already-created subfolder's restriction. A folder structure that looks organized is not proof that access is consistent.
Test at least an intended user, an unintended user and any external center role involved in the process. Include direct links and record attachments in the review where applicable.
Do not place private business documents in a location designed for public website assets. Oracle documents global availability preferences for certain system folders that can override an individual file's Available Without Login setting.
Review the destination folder, file preferences and relevant account-wide settings together. A single unchecked box should not be the only evidence that the document is private.
Use a dedicated, appropriately controlled document location where the design calls for one. Changes to permissions or public availability require the organization's authorization process. The integration should not make files public as a workaround for an access error.
Agree the accepted file types, size limits, naming policy and required metadata. Validate the actual content type rather than trusting only the filename extension. Apply the organization's approved malware-scanning and document-handling process where required.
Keep sensitive information out of filenames and broad diagnostic messages when it is not needed. A file called with a full employee identifier or bank detail can expose information even when its contents are protected.
For each document, retain the source identity, type, version, business record reference, received time and processing result. Log safe references rather than file contents. If the external repository uses expiring download links, define how the integration obtains the content through an authorized route and recovers if the link expires.
A warehouse system sends a delivery confirmation for a customer order. The integration uploads the file to NetSuite but fails before linking it to the target transaction. The source retries the notification.
The recovery process finds the existing target file using the maintained source-document identity and content evidence. It completes the missing attachment relationship rather than uploading a second copy. A warehouse user then opens the document through the intended transaction, while an unrelated role is denied access under the approved design.
A later corrected confirmation arrives with a new version identifier. The integration follows the documented version policy instead of silently overwriting the earlier evidence. This hypothetical example illustrates the lifecycle controls; actual supported attachment relationships must be verified in the account.
Include the following cases in acceptance:
| Test case | Expected control |
|---|---|
| Same document delivered twice | No unintended duplicate file or relationship |
| New approved version | Version policy followed and history retained as required |
| Upload succeeds but attach fails | Existing content reused during recovery |
| Target record is not yet available | Dependency held with a visible owner and next action |
| File exceeds the supported limit | Clear exception and approved alternative route |
| Source link expires | Recoverable retrieval failure without unsafe sharing |
| Intended user opens the attachment | Access works through the real business path |
| Unintended user tries a direct link | Approved access boundary remains effective |
| Source document is removed | Retention and relationship policy followed |
Use controlled test files. Do not test public availability with real confidential documents.
A NetSuite document integration should report documents received, files created or reused, relationships completed and exceptions still open. Reconcile at document identity and version level, not only by upload count.
Include folder ownership, access tests, version rules and recovery steps in NetSuite support documentation. When a user reports a missing attachment, support should be able to distinguish retrieval, upload, relationship and access failures quickly.
No. File creation and the relationship to the business record are separate steps. Verify both and track their identifiers for recovery.
Not reliably by itself. Use a durable source-document identity and a defined version policy, with content evidence where useful.
No. Review folder permissions, related-record access and applicable account-wide availability preferences. Test the intended and unintended access paths.
Use an approved alternative that preserves the document's business purpose and access requirements. Confirm the current limit for the exact service rather than applying a general File Cabinet limit.
Only when the approved lifecycle and retention policy explicitly requires it. Source deletion alone should not silently remove necessary business evidence.