Govern the NetSuite File Cabinet by separating internal folder access, record-linked attachment access and external availability. Test each route with the intended user, not only Administrator. A document hidden from a folder listing may still be reachable through a permitted record relationship, while an online-availability setting can make a file accessible without an ordinary account session.
Start with the document's purpose and audience. Transaction attachments, website images, integration files, scripts and confidential working papers have different requirements. Organizing them into folders is useful, but names such as Private or Finance do not establish an enforced access boundary.
Create a small inventory of file categories, their owners and their access routes. Identify which files are attached to records, embedded in templates, linked from emails, used by scripts or published as website assets.
Record the sensitivity and retention requirement for each category. A public product image can be available to anonymous visitors, while a supplier bank document or employee record needs a much narrower audience. Avoid mixing those categories merely because the same team uploaded them.
Identify system-critical dependencies. A script, template or configuration file can affect account behavior even when it contains no personal data. Its change control deserves attention separate from ordinary document viewing.
Assign an owner who can decide where new files belong. Without an intake rule, users may upload sensitive attachments into whichever folder is easiest to find, undermining an otherwise sensible structure.
File Cabinet access is associated with the Documents and Files permission and applicable folder controls. Internal restrictions are set on folders rather than as a general per-file permission matrix. Review what the actual role can do instead of assuming every file supports an independent view/edit/delete policy.
Folder owners retain access, and Administrator can view restricted and private folders. A test performed only by either of those identities cannot establish what an ordinary user can see. Use non-owner roles and realistic user affiliations for acceptance.
Folder restriction options include organizational values and groups. Subsidiary-based access has its own hierarchy behavior, including access by employees assigned to a parent subsidiary. If that does not match the business requirement, evaluate an appropriate supported group-based design and test it.
Dynamic-group restrictions use a membership snapshot that is refreshed periodically rather than instantaneously. For time-sensitive access removal, account for that behavior and verify the result instead of assuming a group edit immediately changes every folder's effective audience.
A subfolder created after a parent's group restriction can inherit that restriction. Changing the parent later does not automatically apply the new restriction to already existing subfolders. The chronology matters.
Inventory descendants before an access change. Record which restrictions are inherited or separately configured, then apply the approved design to the intended folders. A visual tree can look uniform while its access settings differ.
Test a file in each materially different branch, including an older subfolder and a newly created one. Do not validate only the parent folder and infer the rest. Include owner and non-owner behavior where that distinction affects the result.
Document exceptions. A shared template folder under a restricted operational parent may have a legitimate audience, but that audience should be intentional and reviewable.
Users without the Documents and Files permission can access file content through a file-ID-based URL when the file is related to a record they are permitted to access. This makes the attached record's audience relevant to the document review.
Test the actual attachment from the transaction, customer or other parent record. Also test the relevant file URL under the intended identity. A denied File Cabinet menu does not by itself prove the user cannot read a related attachment.
Review the documents attached to broadly visible records. A customer-facing invoice may be an appropriate home for the invoice PDF but an inappropriate place for an internal negotiation note. The record's commercial purpose does not automatically approve every associated file for the same audience.
Keep custom interfaces and integrations in scope. An application that retrieves or sends files can introduce another access route with its own identity and permissions. Trace the file to its eventual recipient rather than stopping at the File Cabinet setting.
Available Without Login is a distinct external-availability setting. Use it deliberately for approved public assets, and do not enable it on a confidential file merely because an email recipient cannot open a link.
General preferences for Web Site Hosting Files and SuiteBundle files can override individual file-availability choices. Review these settings together with the file's folder and URL routes. An unchecked individual box is not always sufficient evidence of restricted external access.
Upload route matters too. User-interface uploads into hosting folders and files created through scripts or web services can have different default availability behavior. Test how the organization's actual process creates the file instead of relying on the setting from a manually uploaded example.
Changes to public availability can break website images or other assets. Plan the adjustment with the website or application owner and verify both the protected document and the legitimate public output. Security remediation should preserve the approved function where possible.
A fictional business has a Finance parent folder with eight existing subfolders. The administrator changes the parent to a restricted group and creates two new subfolders afterward. There are now ten subfolders, but the later parent change did not automatically update the original eight.
Review finds that six of the original eight already have the intended restriction and two do not. The two newly created subfolders inherit the group's restriction. The resulting count is eight correctly configured subfolders and two requiring correction, not ten confirmed merely by inspecting the parent.
The team then tests three access routes for a representative confidential attachment: folder navigation, the linked transaction and the file URL. A user denied folder navigation can still reach the attachment through an authorized transaction relationship. The business moves the internal-only document to an appropriate approved arrangement and retests the intended audiences.
The example illustrates why folder inheritance and attachment access need independent evidence. It does not prescribe one universal folder structure for every NetSuite account.
Separate file maintenance authority from ordinary document work where the supported account design permits. Identify who can replace a script, modify a template asset or upload a new version of an integration configuration file.
Retain approved source versions and change records outside an informal shared folder. When a file changes, verify the dependent process and the actual deployed or referenced version. A file with the expected name can still contain unreviewed content.
Use available file-change evidence appropriately. System Notes can help track changes, but do not claim a complete log of every read or download without verifying the specific feature and route. Access decisions should not depend on an assumed audit capability.
Keep secrets out of ordinary File Cabinet files unless an explicitly supported secure design requires otherwise. Use the organization's approved credential facilities and ownership procedures instead of embedding passwords or tokens in a convenient text document.
Before removing files, identify record attachments, templates, scripts, website pages and external links that reference them. Old age alone does not establish that a file is disposable. Historical transactions may still require their supporting documents.
Define the retained copy, its identifiers and how authorized users will find it. If files move to another approved repository, test the resulting access and references rather than assuming the migration preserves every link automatically.
Require the appropriate approval for deletion and retain evidence of the exact population. Where recovery is uncertain, treat the action as potentially irreversible. A backup is useful only if its completeness, access and restoration method have been checked.
Build a test record showing file category, folder, owner, associated record, external setting, relevant general preference and expected audience. Execute allowed and denied tests for ordinary employees and any external audience actually in scope.
Repeat the relevant cases after folder changes, new upload automation or a subsidiary reorganization. New files should be checked against the intake policy rather than assuming yesterday's review governs today's different upload route.
For difficult access paths, CuriousRubik's NetSuite support services can help map the account's file usage and verification cases. The useful result is an explainable document-access design with known exceptions and tested business dependencies.
No. Administrator can access private and restricted folders, and the folder owner retains access. Test ordinary non-owner identities when validating the intended boundary.
No. A later parent change does not automatically update existing subfolders. Inspect and apply the approved settings to the relevant descendants.
Yes, through supported record-linked access when the user has access to the related record. Test the attachment and relevant file URL separately from folder navigation.
Not by itself. Relevant hosting or SuiteBundle general preferences can override individual settings. Review the complete configuration and verify the actual external route.
No. Check record, template, script and external-link dependencies along with retention requirements. Preserve the required evidence and obtain the appropriate approval before removal.