Skip to main content
Docs
Feature Requests Onboarding Trust Center Status Page

Community

Fivetran Feature Request — capture deletes on the Clockify TIME_ENTRY table

Answered
Developer YOLO User

Which connector: Clockify

Please add hard-delete capture for the Clockify TIME_ENTRY table (soft-delete via _fivetran_deleted = TRUE), as already supported for CLIENT, PROJECT, USERS, TASK, TAGS, WORKSPACE, etc.

Additional details:

-  When a time entry is hard-deleted in Clockify, the connector does not detect the deletion during normal incremental syncs. The corresponding destination row keeps _fivetran_deleted = FALSE and lingers indefinitely, so it stays in every downstream model until someone manually runs a full historical re-sync.

- Confirmed by Fivetran Support: delete capture is currently not supported for TIME_ENTRY (only for CLIENT, GROUPS, HOLIDAY, INVOICE, PROJECT, TAGS, TASK, USERS, WORKSPACE and their child tables).

- TIME_ENTRY is the highest-volume, most business-critical Clockify table — it drives all time/consumption reporting. Undetected deletes silently inflate every metric built on it.

 

Real example in our data (BigQuery destination):

  • Time entry 6a5a80fa95204e6a92579c6b — a timer left running over a weekend (PT59H42M26S, ~59h42) — was deleted in Clockify by the user.
  • It still exists in the destination with _fivetran_deleted = FALSE (_fivetran_synced frozen at 2026-07-20 while the connector otherwise syncs hourly).
  • Result: a beneficiary's 30h plan is reported as 70h consumed — a false "red / over-budget" alert built entirely on a phantom row.

Periodic full re-syncs are a heavy, easy-to-forget workaround for a table that changes constantly; they don't scale as a permanent answer for TIME_ENTRY.

 

Please sign in to leave a comment.

Comments

2 comments

Date Votes
  • Official comment
    Unnikrishnan Nair Fivetranner

    Hi Florent,
    Thank you for the exceptionally clear report and you are right that periodic full re-syncs are not a workable long-term answer.
    We have added this to our active backlog.
    We are trying to evaluate webhooks as an option, while also checking what can be done through APIs if that is not available. One question that would help us pick the right window for a automated resync (if we go down that path): how far back in time do your users typically delete entries? If deletions almost always happen within a few days, we can scope this much more efficiently than if they can occur months later.

    We will keep you updated on this thread.

  • Developer YOLO User

    Hey,

    We analysed the time entries marked as deleted by our latest historical re-sync. Among 60 deleted entries, only 7 were at most 7 days old. The median entry age was 24 days, the 90th percentile was 56 days, and the maximum was 68 days; none were older than 90 days.

    This measures the entry age when the re-sync detected the deletion, so it is an upper bound rather than the precise deletion timestamp. Still, it shows that a window of only a few days would miss most cases. A 60-day window would cover 97% of the observed cases; we would recommend 90 days as a safety margin.

    Thanks a lot for being so quick to follow this topic !