Getting files in
Bulk import and review
How Gemist moves large batches of variant images into Kabana's catalog builder, and what gets checked before a single file is saved. The review below is running on a sample delivery — the problems it flags are real checks, not screenshots.
01 — Connect a folder
Renders are big and there are thousands of them, so nothing is uploaded through a browser form. Instead you point the catalog builder at a folder you already use. It pulls the files directly from the service, in the background, and resumes on its own if the connection drops.
Dropbox
Each person on the Gemist team signs in to their own Dropbox and picks a folder. Kabana never sees or stores a password.
OneDrive
Works with both work and personal Microsoft accounts, including SharePoint folders shared with the team.
Google Drive
Same sign-in, same folder picker. Useful when renders are produced in Drive and never leave it.
Sign-in happens inside the catalog builder, where your Gemist login lives.
02 — What "secure" means here
- —Each person signs in to their own account. Access is granted by them, to their own folders, and can be withdrawn by them at any time.
- —No passwords are shared with Kabana and none are stored in the catalog. The connection is a revocable permission, not a credential handover.
- —Kabana reads the folder you point at. Nothing is written back to your Dropbox, OneDrive or Drive.
- —Access is read-only, scoped to the folder you pick, and logged: every import records who ran it, from which account, and what came in.
- —Imports are staged. Files land in a review area that is not visible on kabana.com until each one is approved.
03 — Review before anything is saved
Every batch stops here first. The filename is read as an item number and checked part by part against the code tables. Nothing is attached to a style, and nothing appears on kabana.com, until the batch is approved on this screen.
| File | Item number | From | Status |
|---|---|---|---|
| GPIF036MW-CH.jpg2.4 MB | GPIF036MW-CH | Dropbox | CheckGPIF036MW-CH appears more than once in this batch. The first file is the one that will be used. |
| GPIF036MQ-CH.jpg2.2 MB | not readable | Dropbox | Blocked"MQ" is not a Kabana stone code. Use one from the stone table — codes are never invented. |
| GPIF036MW-CH.jpg2.4 MB | GPIF036MW-CH | OneDrive | BlockedGPIF036MW-CH already appears earlier in this batch. Only one image can be attached to a variant. |
| final_render_v3.jpg3.0 MB | not readable | Dropbox | Blocked"FINAL" is not an item number — it does not start with a metal code (G, W, N, XG, XW, XN, P, S, GS). |
| GPIF900MW-CH.jpg2.1 MB | GPIF900MW-CH | Google Drive | BlockedGPIF900 is not a style in the catalog. Check the number against the spreadsheet. |
| GEIF088OX.jpg0 B | GEIF088OX | OneDrive | BlockedTransfer interrupted — OneDrive returned 0 of 2.1 MB. |
| GRIF112CT.psd88.4 MB | GRIF112CT | Dropbox | Blocked.psd is not an image we can attach. Send jpg, jpeg, png, tif, tiff, webp. |
04 — The one rule that makes this work
A file attaches to a variant only when the complete item number — stone code included — is the start of the filename. Anything after a space or an underscore is ignored, so GPIF036MW-CH_v2.jpg is fine. A file with no readable item number cannot be placed and will always be blocked.