Helpdesk migration
Field-level mapping, validation, and rollback between Tiflux and Salesforce Service Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Service Cloud.
Tiflux
Source
Salesforce Service Cloud
Destination
Compatibility
8 of 11
objects map 1:1 between Tiflux and Salesforce Service Cloud.
Complexity
BStandard
Timeline
4-7 weeks
Overview
Moving from Tiflux to Salesforce Service Cloud is a cross-platform schema translation with language-layer complexity and a strict API rate ceiling. Tiflux stores ticket data in Portuguese-labeled fields (ticket, cliente, contato, contrato, apontamento, entidade) that require explicit mapping to Salesforce's English standard object and field names. SLA deadline tracking in Tiflux maps to Salesforce Entitlement Processes and Milestones, and apontamento hours (the native time-tracking entries that IT consultancies rely on for billing) migrate into custom fields on the Case object. Tiflux's Entidades are customer-defined field groups that must be created in Salesforce before any ticket records are imported, or every ticket reference to them fails silently. We sequence the migration: entities, clients, contacts, contracts, then tickets, then attachments and knowledge base. Child tickets and ticket groupings require a dependency graph to ensure parent records exist before children link. Tiflux's v2 API enforces 120 requests per minute per licensed user, so we throttle bulk reads, batch in chunks, and coordinate multi-license parallelism for large datasets. Workflows, automated rules, and chatbot flows do not migrate; we deliver a written inventory of every automation configuration for the customer's admin to rebuild in Salesforce Flow or Omni-Channel.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Source platform
Tiflux platform overview
Scorecard, SWOT, gotchas, and pricing for Tiflux.
Destination platform
Salesforce Service Cloud platform overview
Scorecard, SWOT, gotchas, and pricing for Salesforce Service Cloud.
Data migration guide
The complete Salesforce Service Cloud migration guide
Data model, import mechanisms, field mapping strategy, pitfalls, and cutover — by the engineers running it.
Destination checklist
Salesforce Service Cloud migration checklist
Pre- and post-cutover tasks for moving onto Salesforce Service Cloud.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Tiflux object lands in Salesforce Service Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Tiflux
Ticket (Chamado)
Salesforce Service Cloud
Case
1:1Tiflux Tickets map 1:1 to Salesforce Case. The Tiflux ticket ID is stored as tiflux_ticket_id__c as an external ID for dedupe and reconciliation. Ticket status (aberto, em atendimento, pendente, resolvido, fechado) maps to Case Status picklist values we configure in the destination org. SLA deadline timers from Tiflux link to the Case's associated Entitlement Process and Milestone. Child tickets (ticket filho) and ticket grouping are resolved via a dependency graph: parent Cases are inserted first, then children with their ParentId resolved from the mapping table.
Tiflux
Client (Cliente)
Salesforce Service Cloud
Account
1:1Tiflux Clients map to Salesforce Account. Client annotations (anotações) migrate as Account Description or a custom rich-text field. Resource group linkages are preserved in a custom field client_resource_group__c. The client's associated Contract records are imported after Account creation so that the Account lookup on Contract is satisfied at insert time.
Tiflux
Contact (Contato)
Salesforce Service Cloud
Contact
1:1Tiflux Contacts belong to a Client and are the requester on Tickets. They map to Salesforce Contact linked to the Account resolved from the parent Client mapping. Name, email, phone, and extension fields migrate directly. Tiflux contact extension fields require a custom Phone extension field on Contact if the destination org uses phone extensions.
Tiflux
Contract (Contrato)
Salesforce Service Cloud
Contract
1:1Tiflux Contracts link a Client to service agreement terms and SLA rules. They map to Salesforce Contract with AccountId resolved from the Client-to-Account mapping. Contract hours, billing terms, and SLA rule references migrate as custom fields since Tiflux SLA structures do not map directly to Salesforce Entitlement Processes without configuration.
Tiflux
Custom Entity (Entidade)
Salesforce Service Cloud
Custom Object or Custom Fields
lossyTiflux Entidades are customer-defined field groups attached to tickets, clients, or other objects. Each Entidade has a type, ID, and field values retrieved via the v2 API. Because entity schemas are customer-defined, we identify all Entidade types during discovery, pre-create equivalent Salesforce custom objects or custom field sets in the destination org, and import entity records before any ticket that references them. If the customer created Entidades manually in Tiflux without capturing their API IDs, we extract entity records via the v2 API and help the customer establish the mapping table before ticket import begins.
Tiflux
User (Usuário)
Salesforce Service Cloud
User
1:1Tiflux Users include name, email, role, and permission group membership. We match by email against the Salesforce destination org's User table. Tiflux permission groups do not map 1:1 to Salesforce profiles and permission sets, so we map the most granular role assignment as a custom field and flag any group memberships that require manual profile assignment in Salesforce. Missing Users go to a reconciliation queue for the customer's admin to provision.
Tiflux
Knowledge Base (Base de Conhecimento)
Salesforce Service Cloud
Article (Knowledge)
1:1Tiflux Knowledge Base articles link to Clients and Catalogs. We export article content, categorization, and client associations. The category structure and visibility rules require field-level mapping to Salesforce Knowledge article types (which the customer's admin configures during scoping). Articles are imported after Account and Contact to preserve client linkage.
Tiflux
Activity and Schedule (Atividade e Compromisso)
Salesforce Service Cloud
Task and Event
1:1Tiflux Activities are scheduled tasks and calendar commitments tied to tickets or general workflows. We export activity records with periodicity, dates, and assignee. Mapping to Salesforce Task and Event requires resolving the assignee to the User mapping established earlier. Event records are inserted with WhoId pointing to the Contact and WhatId pointing to the Case.
Tiflux
Attachment (Arquivo)
Salesforce Service Cloud
ContentDocument and ContentVersion
1:1Files attached to Tiflux tickets at creation or within conversation threads are exported as attachment URLs and metadata. File content transfer depends on whether the Tiflux API returns binary content or only references. We download files from Tiflux, upload them to Salesforce as ContentVersion records, and link them via ContentDocumentLink to the parent Case. Large attachment sets require chunked processing to stay within the 120 req/min API ceiling on the source side.
Tiflux
Group and Permission (Grupo)
Salesforce Service Cloud
Group and Permission Set
lossyTiflux Groups manage resource allocation and permission scoping. We export group membership and linking to Users and Clients. Destination permission models vary significantly between platforms, so we map group names and membership to a written permission matrix document that the customer's admin uses to configure Salesforce Groups, Queues, and Permission Sets post-migration.
Tiflux
Apontamento (Time Entry)
Salesforce Service Cloud
Custom Time Tracking Fields on Case
1:manyTiflux apontamento de horas are time entries logged against tickets for billing and consultancy purposes. Each apontamento record (hours, date, description, user) is aggregated and stored in custom fields on the parent Case: apontamento_hours__c (decimal), apontamento_entries__c (long text summary), and apontamento_users__c (text list). This preserves the billing-relevant data without requiring a separate custom object for time entries.
| Tiflux | Salesforce Service Cloud | Compatibility | |
|---|---|---|---|
| Ticket (Chamado) | Case1:1 | Fully supported | |
| Client (Cliente) | Account1:1 | Fully supported | |
| Contact (Contato) | Contact1:1 | Fully supported | |
| Contract (Contrato) | Contract1:1 | Fully supported | |
| Custom Entity (Entidade) | Custom Object or Custom Fieldslossy | Fully supported | |
| User (Usuário) | User1:1 | Fully supported | |
| Knowledge Base (Base de Conhecimento) | Article (Knowledge)1:1 | Mapping required | |
| Activity and Schedule (Atividade e Compromisso) | Task and Event1:1 | Fully supported | |
| Attachment (Arquivo) | ContentDocument and ContentVersion1:1 | Fully supported | |
| Group and Permission (Grupo) | Group and Permission Setlossy | Fully supported | |
| Apontamento (Time Entry) | Custom Time Tracking Fields on Case1:many | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Tiflux gotchas
API v1 is discontinued; only v2 is active
API rate limit of 120 requests per minute per user license
Entidades require pre-existing IDs to link ticket records correctly
Child ticket and ticket grouping dependencies must be sequenced
Salesforce Service Cloud gotchas
Data Export 512MB file size cap breaks large org exports
API Daily Request Limits vary by license edition
No automatic data backup in base Salesforce
Picklist dependencies silently break records when unmapped
Workflow rules fire unexpectedly during data load
Pair-specific challenges
Migration approach
Discovery and API compatibility check
We audit the source Tiflux account via the v2 API (exclusively; v1 is discontinued), documenting ticket volume, client and contact counts, contract records, Entidade types and usage, child-ticket relationships, apontamento history, knowledge base article count, attachment file count, and group structures. We also verify the Tiflux API is reachable from our migration environment and confirm the 120 req/min rate limit applicability to the customer's license tier. This produces a written migration scope with record counts per object, a dependency graph for child tickets, and an Entidade inventory requiring pre-creation.
Destination schema design and Entitlement Process configuration
We design the Salesforce destination schema in a Sandbox. This includes creating custom fields on Case for apontamento aggregation, custom fields for any Entidade mappings that cannot be native custom objects, Salesforce Knowledge article type configuration, Entitlement Processes and Milestones mapped from Tiflux SLA timers, and Group/Queue configurations mapped from Tiflux permission groups. Tiflux's Portuguese field labels are translated to English Salesforce equivalents during this phase and documented in the mapping specification.
Sandbox migration and reconciliation
We run a full migration into a Salesforce Sandbox using production-like data volume. The customer's admin reconciles record counts (Accounts from Clients, Contacts from Contatos, Contracts, Cases from Tickets, Articles from Knowledge Base), spot-checks 25-50 random cases for correct SLA milestone linkage, apontamento field population, and Entidade reference integrity, and signs off before production migration begins. Any Entidade mapping corrections or SLA-to-Entitlement Process adjustments happen here.
Owner and User provisioning reconciliation
We extract every distinct Tiflux User referenced on Tickets, Activities, and Apontamento records and match by email against the Salesforce destination org's User table. Any Tiflux User without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision. Migration cannot proceed past this step because OwnerId and assignee references on Case and Task require a valid Salesforce User.
Production migration in dependency order
We run production migration in record-dependency order: first Entidades (pre-created in step 2, now populated with data), then Accounts (from Clients), Contacts (with AccountId resolved), Contracts (with AccountId resolved), Cases (with EntitlementId and MilestoneId linked, apontamento data aggregated into custom fields, ParentId resolved for child tickets via the dependency graph), Tasks and Events (with WhoId and WhatId resolved), Knowledge Articles (after Account to preserve client linkage), Attachments (ContentVersion and ContentDocumentLink), then Group/Queue configuration mapping. Each phase emits a row-count reconciliation report before the next begins.
Cutover, validation, and automation rebuild handoff
We freeze Tiflux writes during the final cutover window, run a delta migration of any records created or modified during migration, then switch the customer's admin to Salesforce as the system of record. We deliver a written inventory of all Tiflux automated rules, chatbot flows, and SLA escalation configurations requiring rebuild in Salesforce Flow, Omni-Channel, or Entitlement Processes. We support a one-week hypercare window for reconciliation issues. We do not rebuild Tiflux automations as Salesforce Flow inside the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
Tiflux
Source
Strengths
Weaknesses
Salesforce Service Cloud
Destination
Strengths
Weaknesses
Complexity grading
Standard Helpdesk migration. 1 of 7 objects need a manual workaround.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Tiflux and Salesforce Service Cloud.
Object compatibility
1 of 7 objects need a manual workaround.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Tiflux: 120 requests per minute per licensed user.
Data volume sensitivity
Tiflux doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Tiflux to Salesforce Service Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Tiflux to Salesforce Service Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Tiflux
Other ways to arrive at Salesforce Service Cloud
Same-Helpdesk migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.