This is a duplicate to: https://support.fivetran.com/hc/en-us/community/posts/28865101834007-Connector-Improvement-Xactly-Connector-Capture-Deletes-on-all-models-offered

However, the gentleman who filed that ticket is no longer a Fivetran user. 

Xactly is critical to report on Sales Commissions and Hierarchies, but the connector only identifies deletes for `COMMISSION_SUMMARY` and `QUOTA_SUMMARY` tables, according to your docs. 

This makes this connector almost unusable, as critical tables such as 'Position Hierarchy' and 'Sales Credit' (among others!) do not remove deleted records, meaning that any reporting based on extracted data is wrong, duplicative, or otherwise unusable.  

What makes this even worse is that you can't 'correct' for this by running full-table resets, due to 'Priority First Sync'.  The full table reset does not actually remove deleted records.  This has been confirmed by Fivetran Support, who has confirmed that you cannot disable Priority First Sync to specific connectors.  From correspondence with Fivetran Support, the options are:

• Ideal Scenario: Ideally, when a record is deleted in your source system, the source API should stop returning that record. Upon a re-sync, our system would detect the absence of the record and mark it as deleted in your destination.
• Alternative Scenario: If the source API continues to return deleted records, we need a specific column in the API response (e.g., "is_deleted: true," "status: inactive/deleted") to identify and process these deletions.

Regardless if the data is hard-deleted or soft-deleted in the destination (either would be acceptable IMO, although soft deletes (_fivetran_deleted = true) probably aligns better with how the system works elsewhere), the Xactly API does not provide deleted records- so it would be a Fivetran scan to 'detect' the deletes.

Thanks,

Mark