Extending the Salesforce–Zuper Integration Across Assets, Jobs & Master Data

Introduction

A field service organization already running a bidirectional Salesforce–Zuper integration for asset-driven job creation and job-driven case creation wanted to extend that relationship across the rest of the service lifecycle. This case study covers the design of eight additional synchronised capabilities spanning asset updates, case-initiated jobs, live status, attachments, master data, asset lifecycle, cancellations and historical migration — building a continuously synchronised relationship between the two platforms rather than a handful of one-off triggers.

Problem Statement

With only the original asset-to-job and job-to-case flows in place, several everyday touchpoints across the service lifecycle still relied on manual work. Edits made to an asset after its job existed had no way back into Zuper. Cases that were themselves service requests couldn't generate field jobs automatically. Status changes beyond simple completion never reached the linked case, so service teams answered customer queries from stale information. Photos, signatures and service reports stayed in Zuper with no path to Salesforce, master reference data drifted between the two systems, completed jobs didn't update asset service history, and cancellations or deletions risked leaving orphaned or duplicated records on either side.

Solution

We extended the existing Salesforce ↔ Zuper integration with eight event-driven capabilities, all built on the record links already established by the base integration — the Zuper Job ID held on the Salesforce case and the Salesforce Asset ID held on the Zuper job.

How It Works

Case-initiated job creation illustrates the pattern shared across the extended flows — a qualifying record on one side resolves its parent references, creates a linked record on the other, and writes the identifier back to close the loop:

1. A case is created in Salesforce that represents a service request requiring field work.
2. The case is evaluated against the agreed qualification criteria, such as case type or record type.
3. The account, contact and asset on the case are resolved to the corresponding Zuper organization, customer and asset.
4. A job is created in Zuper with the mapped title, description, category, priority and service address.
5. The Zuper Job ID is written back to the case, so the reverse completion flow never generates a duplicate case.

From there, status changes, attachments, asset updates and master data keep flowing between the two linked records for the life of the job, with every update flagged at source so the receiving system never triggers the opposite flow.

Implementation

Implementation carried forward the record links already established by the base integration, so every extended flow could resolve its parent record without new identifiers to manage. Where the same record was edited in both systems within the same synchronisation window, the most recent change was applied and the conflict logged for review. No flow was allowed to create a record where its required parent reference couldn't be resolved — those cases were held as exceptions instead of failing silently.

Salesforce was treated as the system of record for account, contact and product master data, with records matched on an agreed unique key and deactivation mirrored as inactive rather than propagated as a deletion. Historical migration was scoped as a one-time, sandbox-tested exercise, executed in controlled batches outside business hours with a reconciliation report produced afterwards.

Results & Achievements

The extended scope turned a handful of one-way triggers into a continuously synchronised relationship across the full service lifecycle: