Allowing deactived users to be synched from Salesloft
Which connector?:
Salesloft
Additional details:
Request
Add support for syncing deactivated Salesloft users into the users table. This could be a connector setting or the default behavior. Salesloft’s GET /v2/users endpoint returns only visible users unless visible_only=false is passed, and the connector currently doesn’t send that parameter.
Use case
Salesloft keeps historical activity (calls, emails and other records) tied to the user_id of the rep who created it, even after that rep is deactivated. Because deactivated users are missing from users, those records can’t be joined to a user.
Impact in our environment
- About half of our Salesloft users are deactivated (roughly 49%), and none of them appear in
users. - 44% of
callsrows and 45% ofemailsrows reference a user ID that doesn’t exist inusers. - Reporting on historical activity by rep, team or tenure is incomplete or wrong.
Expected behavior
-
usersincludes deactivated users, with theactiveflag preserved so they can be filtered. - A connector setting to turn this on or off would be fine if changing the default isn’t possible.
Workaround today
We have to pull deactivated users ourselves through the Salesloft API and union them downstream. That adds maintenance and a source of inconsistency.
-
+1 to this request. I agree this is crucial and should be supported by the connector.
Without deactivated users the historical reporting is incomplete. It also means we can’t fully migrate off our custom integration to Fivetran. We are forced to mix Fivetran with the workaround Adam described.
This looks like a small change on the connector side (passing
visible_only=false), but it would unblock a full migration for us. I’d really appreciate the chance to see this considered and any update on whether it could be added to the roadmap would be very helpful. Thank you! -
+1, we’re affected too, and this needs to be fixed in the connector.
Salesloft keeps
user_idon calls, emails and other activity after a rep is deactivated, but those users never reachusers. The result is orphaned foreign keys in the connector’s own output. It’s also silent: syncs succeed, row counts look fine, and joins quietly drop or NULL out historical records.Our workaround is a custom pipeline calling the API with
visible_only=false, which defeats the purpose of using a managed connector.This looks like a one-parameter change on
GET /v2/users. Please confirm whether it’s feasible (default or opt-in setting, either works) and whether it can be added to the roadmap. We’d like a clear answer on timing.
Please sign in to leave a comment.
Comments
2 comments