CRM migration

Migrate from MobileWorker to Salesforce Sales Cloud

Field-level mapping, validation, and rollback between MobileWorker and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.

MobileWorker logo

MobileWorker

Source

Salesforce Sales Cloud

Destination

Salesforce Sales Cloud logo

Compatibility

100%

10 of 10

objects map 1:1 between MobileWorker and Salesforce Sales Cloud.

Complexity

BStandard

Timeline

48–72 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

MobileWorker (ArcGIS Online's field-operations user type) stores work assignments, route data, field-collected features, and mobile worker locations in the ArcGIS platform. It has no native CRM object model — contacts, accounts, and deals live elsewhere or not at all. Salesforce Sales Cloud provides Account, Contact, Opportunity, Case, and Asset objects with a relational model that supports complex sales and service workflows. FlitStack AI extracts MobileWorker's work assignments and field data via ArcGIS REST APIs, maps them to Salesforce Case and custom Work_Order__c objects, translates spatial coordinates into Salesforce Field Service geolocation fields, and resolves mobile worker identities against Salesforce User and Contact records by email. Automation logic, routing rules, and offline configurations built in MobileWorker do not migrate — we document them for rebuild in Salesforce Flow, OmniStudio, or Field Service Lightning. The migration runs in a sequenced wave: spatial data export, user/contact resolution, then record creation with field-level validation before the full load commits.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

MobileWorker logo

MobileWorker

What's pushing teams away

  • Pricing is not published on the vendor site — customers must book a discovery call to receive a quote.
  • Reviewer feedback (per Capterra/SoftwareWorld) notes that the platform 'doesn't work when you have no network cable access' — offline behavior may be limited for remote sites.
  • No public API documentation; integrations are configured via vendor engagement.
  • Specialized to UK civil/highways verticals — overseas customers find smaller partner network and localised content.
  • Smaller customer base than mainstream FSM platforms (Jobber, ServiceTitan, IFS) — comparison data is limited.

Choosing

Salesforce Sales Cloud logo

Salesforce Sales Cloud

What's pulling them in

  • The AppExchange marketplace with 5,000+ prebuilt apps gives enterprises integrations for nearly every business workflow without custom development.
  • Native Einstein AI for lead scoring, opportunity insights, and predictive forecasting adds intelligence without a separate platform purchase.
  • Territory management, multi-currency support, and advanced forecasting satisfy the needs of complex B2B sales organizations with structured revenue teams.
  • Slack, Tableau, and CPQ are deeply integrated into the core platform, keeping the sales stack unified for teams already in the Salesforce ecosystem.
  • Organizations with a large, established Salesforce implementation choose it because switching costs — integrations, custom code, trained admins — are prohibitive.

Object mapping

How MobileWorker objects map to Salesforce Sales Cloud

Each row shows how a MobileWorker object lands in Salesforce Sales Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.

Typical mapping — final map is confirmed during the sample migration step.

MobileWorker

ArcGIS Named User

maps to

Salesforce Sales Cloud

Salesforce User + Contact

1:1
Fully supported

MobileWorker identities are ArcGIS Online named users — they have email addresses and display names but no Contact record in a CRM. We extract user emails from the ArcGIS portal API, match them to existing Salesforce Users by email, and create Salesforce Contact records for any ArcGIS users who lack a Salesforce counterpart. Unmatched users are flagged before migration so your admin can provision Salesforce licenses or assign a fallback owner.

MobileWorker

Work Assignment (ArcGIS Workflow Manager Job)

maps to

Salesforce Sales Cloud

Salesforce Case

1:1
Fully supported

ArcGIS Workflow Manager jobs map directly to Salesforce Cases — both track status, assigned worker, priority, due date, and description. We map Job status values to Salesforce Case Status pick-list (New, Working, Escalated, Closed), Worker assigned via email-to-User resolution, and Job priority to Case Priority. Original job-created and job-completed timestamps are preserved in custom datetime fields since Salesforce's CreatedDate reflects migration time.

MobileWorker

Work Assignment (ArcGIS Workflow Manager Job)

maps to

Salesforce Sales Cloud

Salesforce Field Service: WorkOrder

1:1
Fully supported

If your MobileWorker deployment uses ArcGIS Workforce (the dispatch app built on Workflow Manager), assignments map to Salesforce Field Service WorkOrder objects. WorkOrder is a separate object from Case and requires the Field Service Lightning license. We create WorkOrder records with Subject, ServiceAddress (from ArcGIS feature location), and associated Contact resolved by email match. Each WorkOrder gets a link back to the originating Case for audit traceability.

MobileWorker

Field-Collected Feature (ArcGIS Feature Service)

maps to

Salesforce Sales Cloud

Salesforce Custom Object: Field_Inspection__c

1:1
Fully supported

ArcGIS feature layers storing field-collected data (inspections, surveys, asset observations) do not have a standard Salesforce equivalent. We create a custom Field_Inspection__c object with a foreign key to the related Account or Asset. Feature attributes map to custom fields on Field_Inspection__c. Spatial geometry (point/location) maps to a Geolocation compound field (Location__latitude__s, Location__longitude__s) for display in Salesforce Maps.

MobileWorker

ArcGIS Feature Location / Geocode

maps to

Salesforce Sales Cloud

Salesforce Account.Address or Geolocation__c

1:1
Fully supported

ArcGIS stores feature locations as coordinate pairs in WGS84 or a projected coordinate system. We extract the centroid coordinate and write it to a Salesforce Geolocation custom field on the related Account (for service addresses) or Asset (for equipment locations). If the feature has an associated street address, we also populate the standard BillingAddress/BillingLatitude/BillingLongitude fields on Account.

MobileWorker

ArcGIS Mobile Worker Route / Route Layer

maps to

Salesforce Sales Cloud

Salesforce Custom Object: Route__c + custom junction

1:1
Fully supported

MobileWorker routes stored as ArcGIS route layers are decomposed into a custom Route__c object and a Route_Stop__c junction object. Each stop in the route links to the related WorkOrder or Case. Route metadata (total distance, estimated duration, sequence order) is preserved in custom fields. Display in Salesforce Maps requires the Maps for Salesforce app or a third-party mapping integration.

MobileWorker

Asset / Infrastructure Feature (ArcGIS Feature Service)

maps to

Salesforce Sales Cloud

Salesforce Asset

1:1
Fully supported

If MobileWorker manages physical assets (meters, poles, valves) via ArcGIS feature layers, these map to Salesforce Asset objects. The Asset Name maps from the feature's display name or ID field. Related Account is resolved from a spatial join (feature location intersecting an Account's service territory) or from a foreign key stored in the ArcGIS feature attribute table. Asset status from ArcGIS maps to Salesforce Asset Status pick-list.

MobileWorker

Mobile Worker GPS Track / Location History

maps to

Salesforce Sales Cloud

Salesforce Custom Object: Worker_Location__c

1:1
Fully supported

ArcGIS Workforce and Field Maps log worker location points as track features in a geodatabase. These are stored as a time-stamped point feature class with no standard Salesforce equivalent. We create Worker_Location__c records with Location__latitude__s, Location__longitude__s, and Timestamp__c for each tracked point, linked to the related Salesforce User. Location history is preserved for audit purposes but Salesforce does not natively display live worker tracks — this requires a custom LWC or third-party field service app.

MobileWorker

Attachment / Photo from Field Data

maps to

Salesforce Sales Cloud

Salesforce ContentDocument / Attachment

1:1
Fully supported

Photos and attachments captured in ArcGIS Field Maps and attached to work assignments are exported from ArcGIS REST API as binary blobs. We re-upload them to Salesforce as Salesforce Files (ContentDocument/ContentVersion) and link them to the related Case, WorkOrder, or Field_Inspection__c record. File size limits apply: Salesforce Files default to 25MB per file; larger files require Salesforce CRM Content or External Data Integration.

MobileWorker

ArcGIS Offline Map Area / Tile Package

maps to

Salesforce Sales Cloud

No Equivalent in Salesforce

1:1
Fully supported

ArcGIS offline map areas and tile packages are platform-specific caching artifacts with no Salesforce equivalent. These do not migrate. We document the offline area boundaries (bounding box coordinates) as a custom field on the Route__c object so your GIS team can recreate the offline maps in ArcGIS Field Maps post-migration. Salesforce's offline capability is managed separately through the Field Service Lightning mobile app.

Gotchas + challenges

What specifically takes care here

Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.

MobileWorker logo

MobileWorker gotchas

High

No public API documentation for schema or endpoints

High

No documented bulk export mechanism

Medium

Authentication method not publicly documented

Salesforce Sales Cloud logo

Salesforce Sales Cloud gotchas

High

Workflow Rules and Process Builder are retired

High

Bulk API batch quota exhaustion during large imports

Medium

Storage overage billing is non-obvious

Medium

Account-Contact many-to-many relationship mapping

Low

Territory and team member import ordering dependencies

Pair-specific challenges

  • ArcGIS spatial geometry requires preprocessing before Salesforce geolocation fields accept it

    ArcGIS stores feature locations as geometry objects (GeoJSON or ArcGIS JSON) with coordinate reference system metadata. Salesforce Geolocation compound fields accept only WGS84 decimal degrees. We extract coordinates from the geometry object, reproject from the source coordinate system (often State Plane or UTM) to WGS84 using EPSG transformation rules, and write the resulting latitude/longitude pair. Features without spatial data or with null geometry are flagged for manual review. This preprocessing step adds 15–30 minutes of processing time per 10,000 features and must complete before the Salesforce insert phase begins. If your ArcGIS data uses a custom datum or lacks a defined CRS, coordinate transformation may introduce sub-meter positional error — we document the transformation chain for your GIS team to validate.

  • ArcGIS Workflow Manager job status values need explicit value mapping to Salesforce Case Status

    ArcGIS Workflow Manager defines its own job lifecycle with status values that differ from Salesforce's Case Status pick-list. A 'Paused' or 'On Hold' status in Workflow Manager has no direct Salesforce equivalent — the standard pick-list only supports: New, Working, Escalated, Closed. We map these to the nearest Salesforce values and flag any status values that require a custom status category or a pick-list value addition in Salesforce. Custom Case status values require the Status Category (Open/Closed) setting to be configured per value in Salesforce Setup — this is a Salesforce admin action that must complete before the migration runs or Case inserts will fail validation.

  • ArcGIS mobile worker identities do not automatically create Salesforce Contact records

    ArcGIS named users have email addresses and display names but the ArcGIS platform does not store company name, phone, job title, or mailing address — the fields a CRM Contact record requires. We resolve ArcGIS users to Salesforce Users by email match, but Salesforce Contacts are a separate object that must be explicitly provisioned. If your Salesforce org has no Contact record for a field worker, we create a minimal Contact (Name + Email) to support Case and WorkOrder ownership. Contacts created this way lack account association and must be manually linked to the correct Account after migration if your processes require Account-Case relationships via the AccountId field on Case.

  • Field Service Lightning licensing is required for WorkOrder objects to function

    Salesforce WorkOrder is a standard object but several WorkOrder fields and the Field Service Lightning mobile app require a Field Service Lightning license add-on ($75/user/month on top of Sales Cloud licensing). If WorkOrder is in scope but your org lacks the FSL license, we create WorkOrder records with core fields only — scheduling, service territories, work type, andFSL-specific fields are omitted. This is a licensing decision your Salesforce admin must make before migration planning finalizes. WorkOrder without FSL still provides record-keeping for field assignments but does not enable the dispatcher view, service crew management, or skill-based routing features that FSL adds.

  • Offline map areas and tile packages cannot be migrated to Salesforce

    ArcGIS offline map areas are cached tile packages and feature data stored locally on mobile devices for offline field work. These are device-specific binary files with no Salesforce equivalent — Salesforce does not have a feature layer caching system. We export the offline area definition (bounding box, scale range, layers included) as metadata stored in a custom text field on the Route__c object. Your ArcGIS administrator uses this metadata to recreate the offline areas in ArcGIS Field Maps after migration. Field workers lose offline access during the transition window between MobileWorker decommission and Salesforce Field Service Lightning setup — plan a parallel-run period if field operations run in low-connectivity environments.

Migration approach

Six steps for a successful MobileWorker to Salesforce Sales Cloud data migration

  1. Extract ArcGIS data via REST API and map coordinate systems

    FlitStack AI connects to the ArcGIS Online organization REST API using a named-user service account with feature service read permissions. We export Workflow Manager job records, feature service layers (field inspections, assets, routes), and worker location tracks in batches. Each geometry object is extracted and reprojected to WGS84 decimal degrees using the source coordinate system's EPSG code before any field mapping begins. We also export the offline map area definitions as JSON metadata. A pre-migration report lists all ArcGIS layers, record counts, geometry types, and coordinate systems detected — this is reviewed with your GIS admin before the migration plan is finalized.

  2. Resolve ArcGIS user identities to Salesforce Users and Contacts

    ArcGIS user emails are matched against existing Salesforce User records by email address. Matched users are linked directly. Unmatched users trigger a flag: either the Salesforce admin provisions a User license before migration, or we create a fallback Contact record without a Salesforce User seat. We also create Salesforce Contact records for any ArcGIS users who have associated account/company data in the source — if the ArcGIS feature layer includes a 'company' attribute, we link that Contact to the matched Salesforce Account. Owner resolution on Case and WorkOrder records uses the matched Salesforce UserId.

  3. Create Salesforce custom schema for Work_Order__c, Route__c, and Field_Inspection__c

    Before any data loads, FlitStack AI creates the custom objects and fields required for the migration: Work_Order__c, Route__c, Route_Stop__c, Field_Inspection__c, Worker_Location__c, and all associated custom fields (Geolocation compound fields, source ID fields, metadata fields). We deliver a schema setup plan as part of the migration package — your Salesforce admin reviews and approves the object and field creation in a sandbox before we proceed. This step also creates the pick-list value mappings for status and priority fields so validation rules fire correctly during the load phase.

  4. Run a sample migration with field-level diff and coordinate validation

    A representative slice of 200–500 records migrates first — spanning work assignments, field inspections, assets, and route segments. We generate a field-level diff between the ArcGIS source JSON and the Salesforce inserted records so you can verify coordinate precision, status mapping, owner resolution, and cross-object foreign key linkages (Route_Stop__c to Work_Order__c, Field_Inspection__c to Account). The coordinate validation step specifically checks that latitude values fall in the valid range (-90 to 90) and flags any geometry records that failed the coordinate system transformation.

  5. Execute full migration with delta-pickup window and rollback audit log

    The full data migration loads all ArcGIS work assignments, field inspections, assets, routes, and worker location records into Salesforce. A delta-pickup window (24–48 hours) captures any ArcGIS records modified during the cutover window — field workers can continue creating work assignments in MobileWorker until the go-live decision is made. Every insert, update, and error is captured in FlitStack's audit log with source record ID, destination record ID, field mapping applied, and transformation outcome. One-click rollback reverts all Salesforce records created by the migration if reconciliation fails. Post-migration, we deliver a reconciliation report comparing ArcGIS source record counts against Salesforce destination record counts by object type.

Platform deep dives

Context on both ends of the pair

MobileWorker logo

MobileWorker

Source

Strengths

  • Targeted vertical fit for UK civil engineering, construction, highways, plant hire, and traffic management.
  • Lone-worker protection built in (rare among general FSM tools).
  • Vehicle telematics and driver behavior tied to job records.
  • Mobile forms and document attachments cover compliance/site-handover workflows.
  • Free trial without credit card.

Weaknesses

  • No published pricing.
  • Reviewer comments on offline behavior suggest connectivity dependence at remote sites.
  • No public API documentation.
  • UK-centric vertical focus limits overseas fit.
  • Limited third-party reviewer footprint for benchmarking.
Salesforce Sales Cloud logo

Salesforce Sales Cloud

Destination

Strengths

  • Largest enterprise app ecosystem in CRM with 5,000+ AppExchange integrations covering nearly every vertical workflow.
  • Native Einstein AI delivers lead scoring, opportunity insights, and predictive forecasting without a third-party layer.
  • Advanced territory management, multi-currency, and flexible forecasting satisfy complex B2B revenue structures.
  • Deep platform extensibility: Custom Objects, Apex, Flow, and the Metadata API allow full schema customization.
  • Well-documented REST API, Bulk API, and Composite API with published rate limits for programmatic migration.

Weaknesses

  • Pricing model is layered and opaque in practice: per-seat fees plus storage overages, add-on subscriptions, and annual uplifts compound to 30–40% above sticker price.
  • Workflow Rules and Process Builder are deprecated, forcing all orgs onto Salesforce Flow — a migration task that catches many teams by surprise.
  • Steep administrative complexity: meaningful configuration requires a dedicated Salesforce admin or consultant.
  • API rate limits are edition-gated (100k/day base for Enterprise) and easily exhausted by large historical imports without throttling.
  • Data export is exportable via Data Loader but preserving relationship integrity across 30+ objects requires careful ETL sequencing.

Complexity grading

How hard is this migration?

Standard CRM migration. 1 of 8 objects need a manual workaround.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across MobileWorker and Salesforce Sales Cloud.

  • Object compatibility

    B

    1 of 8 objects need a manual workaround.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    MobileWorker: Not publicly documented.

  • Data volume sensitivity

    B

    MobileWorker doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your MobileWorker to Salesforce Sales Cloud migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about MobileWorker to Salesforce Sales Cloud data migrations

Answers to the questions buyers ask most during MobileWorker to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your MobileWorker to Salesforce Sales Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most MobileWorker to Salesforce migrations complete in 48–72 hours of clock time for under 25,000 work assignment and feature records. Larger deployments with 200,000+ records, multiple feature layers, and complex coordinate system transformations extend to 5–10 days. The longest planning step is schema setup — creating Work_Order__c, Route__c, and Field_Inspection__c custom objects with pick-list values and geolocation fields requires Salesforce admin review in a sandbox before the load phase begins. Coordinate reprojection from non-WGS84 source coordinate systems adds processing time that scales with record count.

Adjacent paths

Related migrations to explore

Ready when you are

Move from MobileWorker.
Land in Salesforce Sales Cloud, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day