Migrate from Team Tracker to Salesforce Sales Cloud

Team Tracker users are primarily internal employees. They map to Salesforce Users for internal ownership assignment and to Contacts if the user record also represents an external stakeholder. External-facing user records (e.g., contractors who also appear in Salesforce as Contacts) get both a UserId and a ContactId.

Team Tracker time entries (clock-in, clock-out, duration, idle time) have no Salesforce native equivalent. FlitStack creates a custom Time_Entry__c object with fields: Clock_In__c, Clock_Out__c, Total_Hours__c, Idle_Time_Minutes__c, and a lookup to Contact or Opportunity for billing context. This object stores one record per time entry, preserving the full temporal history for compliance reporting and client billing reconciliation.

Team Tracker tasks split based on context and stakeholder linkage: internal work items without customer attachment become Salesforce Tasks assigned to internal Users. Customer-facing deliverables linked to an Account or Opportunity become Cases when they require tracking and resolution, or Opportunity Line Items when they represent billable deliverables. Task status and priority values map to Salesforce pick-lists with value-by-value translation.

Team Tracker's continuous app/website activity percentages store as time-series data points with timestamps. Since Salesforce has no native activity-monitoring object for employee productivity, FlitStack creates a custom Activity_Log__c object with Activity_Date__c, Activity_Level__c, and App_or_Website__c fields linked to the User's Contact record. Consider migrating daily aggregates rather than per-minute logs to control custom object record volume.

Team Tracker screenshots download from Team Tracker storage and re-upload as Salesforce Files (ContentDocument/ContentVersion) attached to the corresponding User's Contact record or related Task/Case. File size limits apply: Salesforce default 25MB per file; larger screenshots are chunked into multiple files or skipped with a flag in the migration manifest for manual post-migration handling.

Team Tracker leave balances, approved time-off, and holiday records have no Salesforce equivalent in the standard object model. FlitStack creates a custom Leave_Record__c object with Leave_Type__c (pick-list), Start_Date__c, End_Date__c, Status__c, and links to the User's Salesforce User record. Leave approval workflows must be rebuilt as Salesforce Flow approval processes post-migration.

Team Tracker departments and groups map to Salesforce Groups for sharing configuration and to Queues for case and task assignment routing. Department hierarchy (parent/child relationships) is preserved using Salesforce Group nesting or a custom Department__c lookup field on the User record. Queue routing requires mapping each Team Tracker department to the appropriate Salesforce Queue for case and task distribution.

Team Tracker custom statuses and custom fields from the Professional tier require Salesforce custom field creation. Each Team Tracker custom field is assessed for Salesforce field type (Text, Picklist, Number, Date) and created before migration. Custom statuses with specific allowed values become pick-lists with value-by-value mapping; multi-select fields become Salesforce multi-select pick-lists.

Team Tracker overtime tracking (burst hours beyond standard shift) migrates as a custom Number field Overtime_Hours__c on the Salesforce User record. Overtime is tracked cumulatively per period, with each time entry contributing to the running total. Overtime threshold alerts and automated notification triggers do not migrate and require rebuilding as Salesforce Flow rules.

Team Tracker captures GPS location for field employees at clock-in or throughout the workday. This data migrates as a custom Geolocation__c field (using Salesforce's compound Latitude and Longitude format) on the Contact or User record, enabling Salesforce Map integration for territory management if the org's Salesforce edition includes that feature.

Team Tracker's internal record IDs are stored as a text custom field Source_System_ID__c on every migrated record. This field enables traceability back to the source system, supports delta-run de-duplication by identifying which records already exist, and provides rollback support by allowing mass updates or deletion based on source system identifiers during error recovery.