Every document has a status
A document is never just done or failed. It moves through named states, the same ones you see in your History, and the system reads that status to decide what to do next.
Automatic retries
Things break. Nothing gets lost.
Clouds go down, tokens expire, mail servers time out. None of that should mean a document quietly disappears. So a document is never simply “done or failed”: it moves through states, and every failure has a defined way back.
Retries in practice
Five ways nothing gets lost. One line each.
In Findest
- Attachment saved
- Read and matched
- Written to your cloud
- Archived
Invoice_Endesa_2026-03-14.pdf
- Attachment saved, waiting to be readQueued
- Read and compared with your rulesAnalyzing
- Office electricity matched, sendingUploading
- In Drive, Invoices / ElectricityArchived
Stuck isn't failed
A sweep runs every minute. Any document that hasn't moved for more than three minutes goes back in the queue, up to 5 attempts, without you doing anything.
In Findest
- Reading stalls
- 3 minutes, no progress
- Back in the queue
- Archived next pass
Payslip_Acme_2026-03-31.pdf
- Reading startedAnalyzing
- No progress for 3 minutes, re-queued (attempt 2 of 5)Queued
- Read again, Payroll rule matchedUploading
- In OneDrive, HR / PayslipsArchived
Temporary gets retried, permanent gets flagged
A timeout fixes itself if you ask again later. A revoked password never will, so the connection is flagged, retries stop and you get one email.
In Findest
- Something fails
- Temporary or permanent?
- Temporary: next pass
- Permanent: you're told
Invoice_Vodafone_2026-04-01.pdfMail server didn't answer in time; retried on the next pass
QueuedInvoice_Holaluz_2026-03-28.pdfOffice electricity
ArchivedFindestTo me
Your mailbox connection stopped working
The app password for billing@yourcompany.com was rejected.
We've stopped trying so it isn't sent again and again.
ReconnectEach attachment on its own
If one attachment is corrupt or unreadable, only that one is marked as an error. The others in the same email are read, renamed and filed as usual.
In Findest
- Email with 4 files
- Each handled alone
- 3 archived
- 1 error, logged
S
Supplies DeltaTo me
March invoices and delivery notes
- invoice-0312.pdf184 KBArchived
- invoice-0318.pdf201 KBArchived
- delivery-note-0318.pdf96 KBArchived
- invoice-0325.pdfFile is damaged and can't be opened212 KBError
Retrying is safe because filing is once
Each message claims a key before anything is archived. If the same message shows up again, the key already exists and it's skipped, so a retry never leaves a second copy.
In Findest
- Message seen again
- Key already claimed
- Skipped
- Still one copy
billing@yourcompany.com
- New message, key claimedQueued
- Filed in Dropbox, Finance / SuppliersArchived
- Same message seen again: already recorded, skipped
The journey
Four states, and a way out of each.
Every document carries a status. It's visible in your History, and it's the same status the system itself uses to decide what to do next.
Queued
pending The attachment has been saved and is waiting to be read. It gets here within seconds of the email being seen.
Analyzing
classifying The document is being read and compared with your rules. If this stalls, it isn't marked as an error: after three minutes without progress the sweep puts it back in the queue.
Uploading
uploading A rule matched and the file is being written to your folder. If your cloud refuses it, the error shows the provider's own message, so a full Drive reads differently from a revoked permission.
Archived
uploaded The file is in your folder. Your History shows it with the rule that matched and the exact destination.
A document that matches no rule doesn't fall off this ladder as a failure. It's kept as “No rule” with the reason, which is normal operation rather than something to recover from, and it doesn't send you an email.
The distinction that matters
Not every failure deserves a retry.
This is the part that's easy to get wrong, and getting it wrong is worse than not retrying at all.
Permanent: needs you
A revoked app password. A disconnected account. A permission you withdrew. Retrying these every five minutes would repeat the same failure forever and fix nothing.
Connection flagged You get one email when it goes from working to broken, and no further attempts are made until you reconnect.
Temporary: retried
A mail server that didn't answer in time. A cloud with a bad minute. A network blip. These succeed on their own if you simply ask again a little later.
Queued Left alone and picked up on the next pass, automatically.
Without that split, a password you revoked on purpose would be tried against your mail provider every five minutes indefinitely, which is both useless and the kind of thing that gets an address blocked.
Blast radius
One broken thing doesn't take the rest with it.
A bad attachment
If one attachment in an email is corrupt or unreadable, it's recorded as an error on its own. One bad PDF doesn't cost you the three good ones next to it.
An extra cloud copy
On Business, a rule can file to several clouds at once. If the second cloud fails, the main archive still succeeds, and the failed copy shows in your History with its error.
An unreadable message
If a message can't be parsed at all, it's marked and the mailbox moves on. Retrying an unreadable email forever would only block every message behind it.
Filed once
Retrying must never mean archiving twice.
Every message carries a key built from your account, the mailbox address and the message's own identifier. Before anything is archived, that key is claimed. If it already exists, the message has been handled and is skipped.
That guarantee is what makes aggressive retrying safe: the sweep can pick a document back up as often as it needs to without any risk of a second copy appearing in your folder.
It has been wrong once, which is why it's worth spelling out. The key used to include the connection's internal id, which changes every time you disconnect and reconnect the same mailbox. Reconnecting produced new keys for messages already archived, and filed them again. It's now built from the account and the mailbox address, which survive a reconnection.
You only hear about real failures.
Findest used to email about three things: a failed archive, a document with no matching rule, and hitting a plan limit. Two of those are normal operation and visible in your History, and sending mail about them trained people to ignore the mail.
Now an email means something broke: a document that couldn't be archived, or a mailbox or cloud connection that stopped working. Security events, such as a newly connected account, are separate, and you can turn those off in Settings.
How quickly is a stuck document picked back up?
A sweep runs every minute and re-queues any document that hasn't moved for more than three minutes, so it's back in the queue within about four minutes. It tries up to five times.
Will I end up with two copies of the same file?
No. Each message claims a key before anything is archived, so a retry of an already-archived message does nothing.
What happens if my cloud storage is full?
The upload fails and the document is marked as an error with the provider's own message, so it says the drive is full rather than something vague. Free up space and the document can be filed.
Does a failed extra cloud copy break the main one?
No. The main destination is archived independently; the failed copy is recorded against the document with its error.
What if I revoked the app password on purpose?
The connection is flagged after the first authentication failure and left alone, and you get one email about it. Reconnect it when you're ready and checking resumes.