Files on records

A record can carry files: a logo on an account, a signed agreement on a deal, a photo on a contact. Sloose imports them from a folder, a set of files or a zip, and attaches each to the record a row of your sheet says it belongs to.

There are two halves, and they are two sources of one import:

1. A files sheet: one row for each file you give Sloose, made on Source.
2. A file field on Map fields: a column of your records’ sheet that names the file, so a row finds its file in the files sheet.

The examples here are a Deals file and a folder of documents for made-up companies.

Add the files

On Source, the Files and folders tab takes files, a folder or a zip: drop them on the box, or use Choose files or Choose a folder. Nothing is sent yet. Sloose looks through what you chose first, in your browser, and says what it found, for example 312 files to add · 4 left out (3 hidden system files, 1 program) · 2 renamed because another file has its path · 5 already added. Then Add 312 files reads and sends them.

What is looked through and left out, each said by its count:

• Hidden system files such as .DS_Store and Thumbs.db, unless you tick Include hidden system files.
• Programs and installers, left out here by their extension (.exe, .sh, .dll and so on, even if the file is only text). When an upload finishes, Sloose’s server checks again by what each file actually is, from its first bytes, and refuses a program whatever it is called.
• Empty files, and a name that cannot be kept.
• Repeats: a file you chose twice, or one already added, is counted and not added again.
• A zip is opened in your browser, and each entry is a file of its own, in a folder named for the zip. A zip inside a zip is kept as the file it is.

The limits of what you choose: up to 5,000 files in one source; a zip of up to 10,000 entries that unpacks to no more than 2 GiB (all the zips of one choice, 4 GiB), and an entry of 1 MB or more that unpacks to more than 200 times its packed size is refused as a zip bomb. One file may be as large as 5 GB, or the lower ceiling an administrator sets under Settings → Usage & credits, in the Files section (it can only restrict, and files already stored are not affected). What an organisation stores at once is held to its plan: 1 GB on Free, 10 on Team, 100 on Business and 500 on Enterprise. When that space is full, only new uploads are refused and nothing stored is deleted early.

The sheet

The files become an ordinary sheet, one row for each, that the rest of the wizard takes as it takes any file: it can be filtered, rows can be left out, and its columns can be read by a formula. Its columns are File, File name, Name (without the extension), Extension, Path, Folder, a column for each folder level (Folder 1 to Folder 8; deeper ones stay in Path), Size, Size (bytes), Type, Modified, SHA-256, a Duplicate of column where two files hold the same content, and, where a file’s format says them, its own facts: the pages of a document, the size of an image, the length of a recording, and a few more. A column no file has a value for is not shown.

• File holds the id Sloose gave each file. It is what a run reads, so a cell of it cannot be edited, and it is never sent to the AI.
• Type is what Sloose’s server read from the file’s own content once it was stored, not what the name says.
• The first four kilobytes of a stored file are all the server reads, to find its type and refuse a program. A file’s name and folder are your sheet’s own cells: they are not in the paths files are stored under, and they follow your organisation’s AI data setting like any other column.

How long they are kept

A file is due for deletion the plan’s days after the latest of three moments: its upload finishing, its being added to the sheet, and a run using it. That is 7 days on Free and 30 days on Team, Business and Enterprise (the Files section above says it for your plan). A file you took out of the sheet that no run used, and an upload that never finished, are due after a day. When an import is deleted, its files are not erased on the spot: each is marked removed and is due after a day if no run used it, or at its own date (the last use plus the plan’s days) if one did. A nightly sweep deletes what is due, so “due” is when a file may go, and the sweep is what removes it. Files go with the organisation if it is erased.

Name the file on Map fields

A field that takes files has a files badge in the field list. Map it as you map any field: a column of the records’ sheet, a formula, or a fixed value. What the value says is chosen under it:

• Files from: which files sheet. It is asked only when the import has more than one.
• The column holds: what each cell is.
  • The file name, such as logo.png.
  • The name without its extension, such as logo.
  • The whole path, such as brands/acme/logo.png, or the end of the path, such as acme/logo.png, which also finds 2026/brands/acme/logo.png.
  • A pattern, built by a formula. * is any run of characters inside one folder level (never across a /) and ? is one character. Nothing else in a pattern is special: it is never read as a regular expression.
  • This row’s own file, offered only when the sheet you are mapping is a files sheet, one row to a file. Then the row names no one else’s file but its own.
• Several in a cell, split on: where one cell names more than one file (logo.png; banner.png), the character between them, at most five characters.

Names are compared ignoring letter case, and an accented letter is the same letter however it was typed. A blank cell names no file and leaves the field exactly as it is: a blank cell never clears the files a record already holds in its own file fields. (A subform is different: it is rebuilt, below.)

When a name finds no file, or several

Under the column, two answers:

• If no file is found: Leave the file out (the default), Skip the Deal (the module’s own word), or Ask me.
• If several files are found: the same three.

Skip says what it skips in the module’s own word, and it skips different amounts in different places: for a file field written with the record it skips that module’s record (the row’s other modules, such as an Account beside the Deal, are still written); for a field Sloose adds after the save (an attachment) it skips only that file and the record is still written; and for a subform’s file column it leaves the parent’s whole subform as it is, since a subform is replaced from all its rows or not at all, so the parent’s other rows are not written either. Validate says which, before you run.

With Ask me the run stops at the row and asks. The question is headed with the field and what the name came to (No file found or Several files), and, for several, shows each file with its path and size to choose from. The answers are Leave the file out, Skip this Deal (or Leave this file out where only the file is skipped), and Cancel import, and every time this run gives this field the same answer for the rest of the run. Leave the file out writes the row without the file the name asked for; any other file the same field names is still sent, and may replace the ones the record holds.

What the CRM takes

Under the controls Sloose says what the connection declares for the field, in words: how many files it holds, how large one file may be, how large they may be together (the CRM counts what the record already holds), which kinds it takes, and whether a record that has files has them replaced or added to. Where the CRM declares no limit, the row says no limit known; Sloose never makes a number up.

For a Zoho CRM:

• A file upload, multi-file or image field holds as many files as the field’s own length (1 for a single-file field, 5 for a multi-file one), and all the files the field holds must total less than 20 MB (20 MiB, so one file of 20,971,519 bytes is taken and one byte more is refused, the same as for a single file). An image field takes only jpeg, jpg, png, bmp and gif; anything else is refused (“The image format is invalid”).
• A write to a record that already has files replaces a single-file field’s file (the old one is removed in the same write) and adds to a multi-file field’s. Validate warns where files are added to the ones a record holds, and its limits count what is there.
• Two rows that update one record’s single-file field: where the field replaces, the last row’s file is the one the record ends with; where it adds, the second file is refused as too many and its row fails. Validate says it where it can tell the rows meet.

The 25 MB cap, and why it is not 20

Sloose itself sends no single file over 25 MB (25 MiB), whatever the field declares. The largest file a field may take is the lower of the two numbers, so a Zoho file or image field, which declares 20 MB, is held to 20 MB, and an attachment, which Zoho declares no size for, is held to Sloose’s 25 MB. Validate and the run read the same per-file number. Validate judges the files each row names, and not the files the record already holds in the CRM, so a new file can pass Validate and still be refused at the write, for example a 6 MB file added to a multi-file field that already holds 15 MB. That row fails with the CRM’s reason and Retry failed rows takes it again.

Attachments

Every record module takes attachments except Zoho’s own stores of history: Notes, Attachments, Emails and the Activities list. On Map fields such a module has a field named Attachments, beside its fields and its note fields.

• An attachment is added after the record is saved, as a note is, and it only adds: it never replaces a file the record has.
• A file the record already holds by its current name and size is not sent again, so a Retry, a Resume, or importing the same folder a second time does not pile up copies. Sloose reads no content to decide this: two different files with one name and one size look alike to it. And a file whose name the record already has, with another size, is stored by Zoho under a changed name (never refused, never replaced), so a later import, which compares the file’s original name and size with the names Zoho now holds, does not recognise it and attaches it again. Give different files different names before you import.
• Zoho declares no count or size limit for attachments, so Map fields says no limit known and Sloose’s 25 MB cap is the only one: Validate holds each file to it.
• An attachment needs only the permission to write records that every import has: it never asks for a reconnect.

Files in a subform

A subform’s file column is a file field like any other, and each row of the subform names its own file. What a column holds is counted for each row of the subform. The rows are written with the parent, which replaces what the parent held, so a skipped row leaves the parent as it was (above).

A subform is rebuilt, not edited. Zoho deletes the parent’s old rows and inserts the sheet’s, so a row that leaves its file cell blank is written with no file: the old row’s file is not kept, as a record’s own file field keeps it. Name the files you want kept in every row of the subform. See Rows inside a record.

The permission to upload files

A Zoho file upload, multi-file or image field, and a subform’s file column, need one more permission than a plain import: the permission to upload files to Zoho’s file store. It only adds files. It reads and deletes none. A connection made before Sloose asked for it works as it did and is asked to reconnect only when a file field is first used.

A file field of such a connection is shown on Map fields, marked, and not hidden. Validate stops the run on it (the field cannot take files until the connection is made again with the permission to upload them), and, once the import maps a file field, the connection’s tile on Target says Cannot upload files until reconnected: reconnect to import files and offers Reconnect. A connection that is your own has no Reconnect: its tile says Cannot upload files: choose another connection for imports with files, and so does Validate. Attachments need no reconnect.

What Validate says

Validate judges the files the import would send, and it waits until it has the list of what the server holds: while it is read, Validate says the files are being read, so they are not checked yet and the run waits, and where the list cannot be read it says so as a warning and checks no file (reload the page to check them again). It is read again whenever a file lands or the sheet changes.

It says	Stops the run?
The field’s connection must be made again for the permission to upload files	Yes
The field is mapped but nothing says which files sheet or what the column holds	Yes
The mapping names a files sheet this import does not have	Yes
This row’s own file is mapped on a sheet that is not a files sheet	Yes
A formula over the row’s other records names the files (only a column, a value or a formula of the row’s own columns can)	Yes
This row’s own file names a file that is no longer stored (an expired one)	Yes
A file is larger than the field takes, or the files of a record total more (the figure is the field’s, or 25 MB)	Yes
Rows name a file of a type the field does not take (an image field, a .txt file)	Yes
Rows name more files than the field holds	Yes
Two rows set one single-file field of one record	Yes
Rows name no file that is in the sheet (a name or path whose file has expired is one of these)	Warning: what happens is said (left out, skipped, or the run will ask)
A name or path matches more than one file (a pattern takes every match, and a separator names several on purpose, so neither is this)	Warning: the same
A file name contains the separator the cell is split on, so it could never be found by name	Warning
Files are added to the ones a record already holds	Warning

Each finding says its rows (the first five, and how many more), is on Map fields in the module that has the field, and can be explained by Ask AI like any other. The AI is shown a file’s name only as it is shown any value of your file: the AI data setting decides.

Running, and the results

A file is read from Sloose’s storage and sent to Zoho through Sloose’s API: a call’s files are uploaded one after another, and then the record is written. The browser never downloads a file to send it again. A dry run writes nothing, so it sends no file.

A refused file is a failure of the row for a field written with the record (a record is never saved quietly missing its file), and of that file only for an attachment. On the row’s detail the failure begins with the file’s name, and the results file’s Error column names the field and then the file: for example the field’s name, then “logo.png”, then Zoho’s own words. Retry failed rows takes only the failed rows, and an attachment already on the record is not attached twice.

What the AI sees

The contents of a file are never sent to the AI. The File column (ids) is never sent either. The rest of the sheet (names, folders, sizes) is an ordinary column and follows the AI data setting. The AI does not propose a file field’s mapping: map it yourself, from a files sheet by name or path.

Where it is in the API

The routes that reserve an upload, sign its parts, finish it, list, read, download and remove a file, and the organisation’s file settings, are in the API reference under Imports and Orgs. An upload goes straight to storage by a signed address, and a stored file is never an import’s own object: its clock is the one above.