Jobber Imports That Keep the Relationships That Make the Data Useful

A folder full of Jobber CSVs is not a customer history. It is a folder full of CSVs, which is impressively literal but operationally unhelpful. This Local Business Pro feature update recognizes the supported Jobber report pack, uses Jobber source identities to connect parent and child records, preserves supported recurring-work and payment history without creating live billing activity, and shows skipped, failed, ambiguous, or review-required outcomes at the row level.

The Local Business Pro Import & Export workspace handles files, mappings, dry runs, progress, and history. This Jobber-specific layer adds report recognition, connected identities, historical continuity, bounded placeholders, and visible exceptions.

What changed for Jobber migrations

Useful field-service history is relational. Flatten it into unrelated rows and the values may survive while their meaning disappears. Local Business Pro uses supported Jobber IDs to preserve the chain where the source evidence is clear:

Contact → property → one-off or recurring job → visit or quote → invoice → transaction

Source quality still matters. One missing anchor may qualify for a bounded historical placeholder; several possible parents can remain unlinked; and a recognized report may still require review.

Which Jobber reports can Local Business Pro recognize?

Local Business Pro recognizes the current 15-report Jobber pack, but “recognized” and “automatically importable” are different promises.

Eight core report types can enter the reviewed import flow:

• client contact information;
• property lists;
• one-off jobs;
• recurring jobs;
• visits;
• quotes;
• invoices; and
• transactions.

Seven additional report types are recognized but intentionally require review:

• requests;
• products and services summaries;
• lead sources;
• client re-engagement;
• client communications;
• aged receivables; and
• timesheets.

Those seven files can be classified without inventing a migration stance. They do not quietly become contacts, products, or financial records because a column name looks familiar. Positive thinking remains available; it is simply not the mapping strategy.

How are contacts, properties, jobs, and invoices kept connected?

Local Business Pro prefers Jobber source IDs. Client and property IDs distinguish customers and service locations; job, recurring-job, quote, invoice, and transaction IDs preserve the rest of the chain.

For an HVAC replacement, the customer and property arrive first. The one-off job and quote retain those references, the invoice keeps its supported job evidence, and a completed transaction contributes historical payment context. The office gets connected records rather than five rows sharing a familiar last name.

On a reviewed reimport, established source relationships can be reused or stale mapping evidence corrected when identity is clear. Names, phone numbers, invoice numbers, and job numbers are not universally authoritative keys.

The destination records remain visible through connected contacts and properties, jobs, invoices, and transactions.

What happens to Jobber recurring jobs?

Supported recurring jobs can become historical membership or subscription records preserving customer, service, cadence, and source context. Related visits can attach when the source evidence is sufficient.

Historical is the important word. Importing a recurring record does not charge a saved card, create a processor mandate, promise every future appointment, or activate live billing. The migration records what happened and what the source described without pretending to reenact it.

For a pest-control company, clients and properties come first, followed by historical plans, connected visits, and customer invoices—without turning an old quarterly program into an unexpected new charge.

Payments and refunds complete part of the invoice picture

Supported completed transactions can add historical payment and refund evidence to invoices and update recorded paid state. Tips remain separate from invoice principal.

This is not live payment settlement. It does not move money, reconcile a payment processor, certify the books, or create a new customer payment method. An imported transaction explains historical activity; it is not permission to charge anyone.

What is a historical shell?

A historical shell is a limited continuity record for a supported downstream row with one trustworthy missing anchor. It preserves the relationship; it is not a complete job or invoice.

If an invoice clearly references one Jobber job ID but the jobs file is absent, Local Business Pro may create a historical job shell. A later master row can complete it.

The rule is narrow. A shell cannot manufacture scope, crews, dates, pricing, or status. It preserves one supported anchor instead of filling blanks with confidence.

Ambiguous is a result, not an invitation to guess

An arborist may have two properties under the same customer name. Property IDs keep them distinct. If an invoice refers to several possible jobs, the relationship remains unlinked or blocked instead of attaching to whichever tree-removal job appears first.

The row outcomes tell different stories:

• Skipped means the row did not proceed under the reviewed rules.
• Failed means a blocking problem prevented completion.
• Ambiguous means more than one relationship is plausible and none should be selected automatically.
• Review required means the report or row is recognized but needs an operator decision before import.
• Shellable means one missing anchor may qualify for the limited historical-continuity path.

A completed batch can include clean records alongside these exceptions. Completion is not a synonym for perfection.

How do queued imports and recovery work?

A larger report pack can run in the background. The workspace shows queued and in-progress status and lets the office reload or return through history to inspect retained outcomes.

After blocked or failed rows, the operator reviews the evidence, corrects the source or mapping, and decides what belongs in a new run. Automatic retry is not promised; one uncertain transfer does not need an equally uncertain twin.

An electrical office can review the full pack, dry-run it, monitor background progress, and use history after a reload to plan recovery from evidence rather than rumor.

Three practical Jobber-to-LBP workflows

Pest control: recurring work with historical boundaries

Import clients and properties first, then recurring jobs, visits, invoices, and transactions. Confirm that the recurring records are historical and imply no live charge or automatic future schedule.

HVAC: preserve a replacement chain

Use source IDs to connect the customer, property, replacement job, quote, invoice, and completed transaction. If one job master is missing but one trustworthy reference exists, review a historical shell as a continuity record.

Arborist: keep shared names from becoming shared records

Use property IDs to separate service locations. If an invoice has several job references, leave it unlinked or blocked. A visible ambiguity is safer than a beautifully organized mistake.

Permissions, compatibility, and source quality still matter

The operator needs data-management access plus relevant contact, job, invoice, transaction, and other record permissions. Imports remain isolated to the correct business.

The Jobber update covers the recognized report structures and supported fields described here. It does not promise compatibility with every Jobber export, custom report, historical variation, or undocumented field. It also does not guarantee that a damaged or incomplete source pack becomes lossless after review.

Export the relevant reports together, preserve source ID columns, and review the pack as a connected set.

Frequently asked questions

Will Jobber contacts and properties stay linked?

Yes, when supported source IDs and parent references provide sufficient evidence. Missing or ambiguous relationships are surfaced.

Are all 15 recognized Jobber reports imported automatically?

No. Eight core types enter the reviewed flow; seven recognized reports intentionally require review.

Do recurring jobs create live memberships and billing?

They create supported historical plan context, not live billing, card charges, processor mandates, or promised future visits.

Can invoices, payments, and refunds be imported?

They can add historical payment and refund evidence and update recorded invoice state. They do not settle funds.

What happens after a failed or interrupted import?

Use status, row outcomes, and history to diagnose it, correct the source or mapping, and decide what to run again. Automatic retry is not promised.

Start with the full report pack and review the evidence

Export the relevant reports together and keep source IDs intact. Analyze them as one batch, separate core from review-required reports, resolve blockers, and dry-run the connected records. Then inspect created, updated, skipped, failed, ambiguous, and review-required outcomes separately.

The goal is not a perfect-looking progress bar. It is connected operational history your team can use—and a clear record of anything that still needs a human decision.