New company-owned files share the object layout:
{tenant_id}/{hashable_company_id}/{private|public}/{feature}/...
The company component uses the same HashableId representation as the company's hash. The tenant is the root; there are no additional tenants/companies prefix levels. Hashing is a naming convention, not an access-control mechanism.
Watch the lesson
Private and published files
| Content | Handling |
|---|---|
| Customer/deal files, ticket and internal-comment files | Private company storage with authorized retrieval |
| New chat and social-message attachments | Company-owned storage and current conversation/record authorization |
| Knowledge source documents and new article attachments | Private, metered storage; published reader delivery verifies article and channel access |
| Published widget, shop, form and brand assets | Public company namespace for assets intentionally published |
| Retained import sources, archive sources and generated private outputs | Company-private storage; temporary local processing copies are separate |
The configured private disk uses the S3-compatible Oracle storage service in the reviewed deployment. Private and public buckets must be distinct. Existing chat objects, historical public URLs and supported legacy local/private paths remain in place; this change does not migrate every historic file or revoke an already public historic URL.
Upload and download
Use the record's file action rather than copying an object path into a browser. New uploads check the tenant's finite storage allowance and per-file allowance across its companies. Multiple module references do not create unlimited capacity. A failed upload is not available merely because an object was temporarily written.
Private download checks current tenant, company, record access and attachment membership. A changed, removed or foreign attachment is refused. Short-lived signed delivery is used only where the original authorized flow permits it. Do not treat a file URL as proof of permission. See Mobile Helpdesk for its authenticated, revision-bound native downloads and 50 MB safety limit.
Archives and import evidence
Exports and portable archives contain only the supported authorized scope. Review the manifest and exclusions before relying on a backup. Restore preserves supported relationships after preview; it does not recreate provider credentials or running automation merely by importing records.
Temporary import evidence has an expiry. Operational destination files are separate from temporary source packages. Expiry removes source evidence only after safe checks; records remain, but missing before-images cannot support automatic rollback. Keep your original source exports outside Nviti.
Cleanup and capacity
Abandoned-upload cleanup is conservative. It retains active, referenced and uncertain objects. Storage is released only after physical absence is confirmed; a deletion failure retains the charge for retry. Do not delete an object directly to make a usage display change. Administrators should follow CRM operations for dry-run cleanup and accounting verification.
Media-library ingestion, conversion outputs and archive/output services use the company-file contract. A replacement conversion must commit before its funded original is retired; failure and rollback must preserve recoverable bytes. Historic account-level assets are not silently reassigned to a company.