On Dropbox, the audience is a property of the folder
A company Dropbox account mixes two things in the same tree. There are the shared folders, where somebody once decided who was allowed in. And there is the account's own space, where files live without anyone ever having had to answer that question.
The connector reads a single signal to settle it, the member list of the shared folder holding the file. When every one of those members belongs to the same department of your organisation, the file is filed under that department and an AI working for that department can use it. In every other case the file is filed nowhere and waits for an administrator to decide. Those other cases are more common than you would think.
- The file is in no shared folder at all, it lives in the connected account's own space.
- The folder is shared with a Dropbox group, and the connector does not open a group to list the people in it.
- The folder holds an invitee who has not joined the share yet.
- Dropbox does not return the address of one of the members.
- The member list could not be paged through to the end.
- The members span several departments, or one of them is unknown to your organisation.
- The file is opened by a public link.
What is read, and what never is
Scope reads in two halves. What the connector goes and fetches from Dropbox, and what it never asks Dropbox for at any point.
The member list serves to pick a department, it is not copied into your Kastel. What is noted beside a file holds no address, only its Dropbox identifier, its path, the account that brought it in, its name, its revision and the department it is filed under. A signature request is not a Dropbox file and does not come through this connector, it belongs to Dropbox Sign.
What Dropbox's change feed says, and what it does not
Dropbox can say what has moved since the last read. Each pass starts from a marker, collects the modified files, and collects the deletions too, which appear there as named entries. A disappearance is therefore recorded on the ordinary pass, with no separate treatment to wait for.
One thing never appears there. Membership of a shared folder is not part of a file's metadata, so removing somebody from a folder moves no file at all in the eyes of that feed. On this precise point Dropbox behaves differently from Google Drive, whose change feed does surface permission changes.
Your Kastel therefore goes looking for that information elsewhere, on the reconciliation pass. That pass rereads the make-up of the shared folders it tracks and moves the files whose department changed, in both directions. A folder narrowed down moves its files into the new department and retires the note filed under the old one. A folder widened across several departments puts its files back on hold.
Two precautions in this connector are worth naming, because they cost you a little time and spare you gaps. The marker never advances past a file that failed, so that file is reread on the next pass rather than forgotten. And when the marker grows too old for Dropbox, the connector relists the whole account instead of assuming the gap held nothing. Filing a file that the share does not designate is a decision, and that decision is taken in the governance of your context.
The questions we get about Dropbox
Are the files in my own Dropbox space read?
Yes, they are read and copied into your Kastel, like every file the connected account can see. No shared folder covers them, so they are filed under no department and no connected AI reaches them. An administrator can decide to file them, and does so file by file.
I share a folder with a Dropbox group. What happens?
The files in that folder go on hold. The connector does not open a group to list the people in it, so it can derive no department from it. The same folder shared by name with those people can, for its part, file itself.
I removed somebody from a shared folder. When is that taken into account?
On the next reconciliation pass, not the second you remove them and not on the ordinary read pass. Dropbox does not report that change, so it has to be fetched. Between two reconciliations, the files in that folder keep the department they had.
Does a file deleted in Dropbox disappear from my Kastel?
No. It is marked there as gone at the source and kept, readable by the same people as before, until an administrator decides to erase it. The ordinary pass records the disappearance, since Dropbox's feed names it, and erasing stays a separate act.
What this connector does not do
It does not follow a sharing change by the second. Removing somebody from a shared folder does not appear in Dropbox's change feed, so the correction happens on the next reconciliation pass. In between, a file stays readable by the department that was already reading it. We would rather write that here than let you find it out.
It does not sort what it copies. Every readable file the connected account can see comes into your Kastel, including those in a space that was never shared with anyone. They stay on hold there and no AI reaches them without an administrator's decision, which is not the same thing as having left them out.
It does not read a file of any size. Past the download ceiling a file is refused before it is even downloaded, based on the size Dropbox declares, and that refusal is written into your log. It is never taken in halfway, which would be worse.
It writes nothing into Dropbox. The authorisations requested cover reading only, and the connector refuses to start if it is handed a write authorisation. Removing the connection stops the reading and removes nothing of what already came in, because erasing is a distinct act that requires a decision.
Start by looking at what your Kastel refuses to file on its own.
The product page shows how your Kastel builds its context, what it exposes to the AIs you plug in, and where the decision to open an access is taken. The core is free to self-host, with every connector, Dropbox included.
See the product
