## TL;DR
A duplicate rule blocking Case insert means the new Case matched an existing record under the rule's matching criteria and the rule is set to block. Do not fight it per record: decide whether the match is a true duplicate (dedupe at the source) or a false positive (tune the matching rule), and give integrations a sanctioned bypass for the cases that must insert regardless. Blocking rules are data quality doing its job loudly.

## The query

```text
salesforce duplicate rule blocked case insert
```

## Use this when

- Case inserts fail on duplicate rules
- Integrations cannot create Cases reliably
- You are tuning duplicate matching rules
- Auditing duplicate-rule blocks

## Not for

- Overall deduplication strategy
- Account or contact merge rules
- Lead duplicate handling
- Duplicate job scheduling

## Steps

### 1. Read the block as a match report, not just an error

The block response names the rule and the matched records. Read both: the rule tells you which criteria fired, the matched records tell you whether the match is correct. Most fixes start here.

Expected output: rule and matched records identified per block.

### 2. Decide true duplicate versus false positive

If the matched record really is the same case, fix the source: dedupe before insert, or update the existing Case instead. If the match is wrong (overly fuzzy criteria), the fix belongs in the matching rule, not in bypasses.

Expected output: each block classified as true or false positive.

### 3. Tune the matching rule for false positives

Loosen fuzzy thresholds or add discriminating fields (exact email plus subject, not just subject) so legitimate distinct Cases stop matching. Test the tuned rule against historical blocks before deploying.

Expected output: matching rule with acceptable false-positive rate.

### 4. Give integrations a sanctioned bypass path

For Cases that must insert even on match (high-volume intake, real-time channels), use the platform's duplicate-bypass mechanism on the integration user. Bypasses are audited and deliberate, unlike per-record workarounds.

Expected output: integration inserts succeeding via sanctioned bypass.

### 5. Monitor block rate as a data-quality metric

Track blocks per rule over time. A rising block rate means either duplicate intake is growing (fix the source) or the rule is over-firing (tune it). The metric tells you which.

Expected output: per-rule block-rate monitoring.

## Template: the checklist

```text
Duplicate rule blocks:
[ ] Block read as a match report (rule plus records)
[ ] Blocks classified true duplicate vs false positive
[ ] Matching rule tuned for false positives
[ ] Sanctioned bypass for must-insert integrations
[ ] Block rate monitored per rule
```

## Variant phrasings

### duplicate rule preventing case creation

Steps 1 and 2. Read the match, classify it.

### case insert blocked as duplicate

Steps 2 and 4. True dupes get sourced; must-inserts get bypass.

### salesforce matching rule too aggressive

Step 3. Tune the criteria.

## Why it happens

Duplicate rules evaluate at insert time against the whole Case table, and intake channels (web forms, email, integrations) happily submit the same issue repeatedly: retries, double-submits, customers opening multiple channels. The rule is the only thing standing between messy intake and a messy database. When it blocks, it is usually right about the data and wrong about the workflow.

## Edge cases

- Bypass scope creep: bypasses granted for one integration get reused for others. Review bypass grants periodically.
- Alert versus block: consider downgrading to alert for rules with high false-positive rates; humans resolve, inserts proceed.
- Cross-object matching: Case-to-Case versus Case-to-other-object rules behave differently. Know which fired.
- Bulk API inserts: blocks inside bulk jobs need per-record handling; one block must not fail the batch.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mEUhldRuubW3ylTvZkRPHg