How California ADU Builders Clean Duplicate Permit Opportunities

Table of Contents

Toggle

Why Do Repeated Permit Rows Matter to California ADU Builders?

In this anonymized composite scenario, a California accessory dwelling unit (ADU) builder imports public permit data into Salesforce and creates two bid Opportunities for one permit application because the feed lists multiple address rows. A different permit on the same parcel is a real, separate project. An illustrative 15,000-row review shows how the admin can distinguish source rows from bid opportunities, preview corrections in ZaapIT, and protect supported changes with backup, bulk undo, and restore.

Why California Permit Data Can Inflate a CRM Project List

San Francisco’s Building Permits dataset warns that one permit number can appear in multiple rows when an application covers multiple addresses; its published data also distinguishes a deduplicated primary-address view. In a separate 2024 UC Berkeley Terner Center analysis, researchers joined California ADU application and permit data by assessor parcel number and grouped multiple applications on one parcel for their research question; they also noted missing or erroneous submissions. Their Los Angeles, Orange, and San Diego county study is not a finding about any San Francisco contractor or Salesforce org. Together, these sources show the exact data-grain trap in the composite below: a public permit row is not necessarily a unique permit or a unique bid, while a shared parcel alone cannot prove that two permits are the same project. California’s housing progress reporting includes applications and building permits statewide, making clear why builders encounter several related but distinct record types.

Use Case: Repeated Permit Rows Create Duplicate Bid Opportunities

A San Francisco-area ADU contractor brings a permit-feed export into a custom Permit Intake object. One building permit application appears twice because the city lists two addresses for the same application. An integration creates an Opportunity from each row, and two estimators unknowingly prepare bids for what the contractor considers one solicitation and scope. Pipeline reports overstate active prospects and task activity is split. A later, separately numbered permit for a different scope on the same parcel is legitimate and must remain visible.

The admin defines the CRM identity grain as one contractor bid opportunity for an approved permit application and work scope. The permit application number is a strong grouping key, but it is not the whole commercial decision: addenda, phases, separate trade scopes, and new permit numbers may warrant separate Opportunities. Multiple public addresses and several permit contacts remain attributes or related records, not automatic reasons to create another bid.

Why Salesforce Needs a Permit-Specific Import Key

Salesforce Help’s matching-rule map lists standard matching rules for Accounts, Contacts, and Leads, not a ready-made building-permit identity rule. Salesforce’s custom-object import guidance describes matching by name, Salesforce ID, or external ID and warns that name matching is case-sensitive. For this scenario the admin uses a reviewed permit-source key on the intake record, then separately checks whether the contractor already has an Opportunity for that application and scope. A name or street address alone is too weak. Salesforce duplicate-rule considerations also describe situations where duplicate rules do not run or do not compare records in the same simultaneous save. Test the actual import path and custom rules instead of assuming alerts will catch a batch of repeated source rows.

A Controlled ZaapIT Review of 15,000 Illustrative Rows

1. Establish a baseline: export the illustrative 15,000 Permit Intake rows and linked Opportunities with Salesforce IDs, permit numbers, parcel IDs, addresses, work descriptions, stages, owners, amounts, quotes, and open tasks. Restrict private contact details to authorized reviewers.
2. Profile repeated rows: filter by issuing agency and permit application number, then inspect address and contact variants. Keep a separate list for missing permit numbers or ambiguous work scopes.
3. Validate the bid grain: an estimator and operations owner confirm whether each cluster is one solicitation or several legitimate scopes. Record the retained Opportunity ID and all source-row IDs; do not use parcel alone as the merge key.
4. Preview and back up: use ZaapIT to preview approved field corrections and a small pilot. Back up affected rows and test the supported bulk-undo or restore route before a broad change.
5. Run controlled batches: update permit keys, owner, and report grouping where approved. Review quotes, activities, and integrations before removing any duplicate Opportunity; do not assume a record merge is appropriate for the object’s relationships.
6. Reconcile and recover: compare unique permit-plus-scope bids, pipeline Amount, tasks, and source-row links with the baseline. Use bulk undo or restore for supported ZaapIT actions if a mapping is wrong, and correct the upstream feed separately.

The 15,000 count is an illustrative review population, not a claim that every row is edited or that an actual contractor achieved a result. ZaapIT’s bulk-update guidance and user guide describe backup and restore for supported actions; the team must verify the exact object, operation, and related-record scope in its org.

How the Team Knows the CRM View Is Trustworthy

The composite team samples both consolidated and deliberately separate projects. It checks the official application number against the public source, confirms each Opportunity’s work scope, then reconciles quote and activity relationships. A report counts unique bids by permit and scope rather than raw intake rows; another report retains every imported source row for traceability. New feeds upsert by reviewed source key and route missing or conflicting keys to an exception queue instead of silently creating Opportunities.

• Every changed Salesforce row has an approved before-and-after mapping.
• Multiple addresses or contacts on one permit remain accessible without inflating the bid count.
• Separate permit numbers and genuine trade scopes remain separate.
• Pilot recovery and failed-batch logs remain available to the admin.