Yes. After feed processing, the add-on writes the Dropbox URL (or failure detail) to gf_entry_meta against the entry. That's what SleekView reads. Without the add-on installed, the meta keys don't exist; SleekView's Dropbox columns are inactive.

Yes, through the add-on's feed processor. SleekView's bulk action calls the same processing hook the default admin uses, so retries fire the standard success/failure flow. Conflict detection prevents re-pushing entries that succeeded between when you opened the view and clicked retry.

The Dropbox file remains; Gravity's Dropbox add-on doesn't clean up Dropbox itself on entry deletion. SleekView reflects the entry deletion immediately, but the orphan file remains in Dropbox until a separate cleanup workflow runs.

Yes. The add-on writes the feed ID into gf_entry_meta as part of the processing record. Add that as a column to audit which feed handled which entry, useful when multiple feeds target different Dropbox folders on the same form.

Yes. The upload field is what triggers the feed in the first place. The file lands in gf_entry_meta as a local URL too; SleekView shows both the original-upload URL and the post-feed Dropbox URL so you can verify the round-trip.

Yes. Filtered views export to CSV honouring the current column set, so the export contains the Dropbox URLs alongside entry context (form, date, email). That's the difference between a usable handoff and a raw entry dump.

Token expiry is handled by the add-on itself. SleekView surfaces the downstream symptom (failed feeds clustering after a date) as an actionable filter; you re-auth in the add-on settings, then bulk-retry the affected entries from the SleekView.

Yes. The stored value is a Dropbox share URL; SleekView renders it as a clickable cell. Open the file in a new tab without leaving the table, useful for spot-checks during audits.