Salesforce duplicate rules that preserve staffing inquiries

A returning candidate applying for another role is valuable activity. A second person record created by a retry is usually a data-quality problem. A useful duplicate policy preserves the first and prevents or resolves the second.

Start by separating identity from intent. The person, application, client inquiry and integration message are different things. A matching email address may suggest an existing person; it does not establish that a new application or inquiry should be discarded.

Salesforce supplies matching rules to identify potential duplicates and duplicate rules to decide what happens when a match is found. Neither determines your staffing firm's identity policy or resolves every conflict automatically. Salesforce matching rules

Begin with an intake map

For every route into Salesforce, record the object created, running user, active matching and duplicate rules, error destination, and person responsible for rejected records. Include candidate forms, client inquiry forms, recruiter entry, ATS syncs and imports. Two forms on the same website may use entirely different integration paths.

Use this decision matrix as a starting point, then prove each row in a sandbox:

The Web-to-Lead exception matters

For native Web-to-Lead, Allow + Alert can block a matching submission because the automated process cannot acknowledge the warning. Salesforce documents Allow + Report without Alert, scoped to the default Web-to-Lead creator, as one alternative. Do not assume that the word “Allow” means a duplicate website submission will be saved. Salesforce's Web-to-Lead duplicate guidance

That alternative needs careful scoping. A broadly applicable blocking rule can still affect the same intake. A user-based condition also affects other work performed as that user. Inventory those paths before using the default creator as the dividing line. A submitted, user-editable “source” field should not become a trusted bypass switch.

Allow + Report deliberately accepts duplicate records for later handling. The Report option does not create your firm's staffed exception queue, assign an investigator, capture an override justification or preserve an application relationship. Those are additional process and configuration decisions.

API behavior requires an explicit contract

Salesforce REST API provides a Duplicate Rule Header whose options include acknowledging an enabled alert, returning match details and applying the current user's sharing. Its defaults and availability are documented. Use the options deliberately, rather than adding a blanket “allow duplicates” setting. Do not assume an alert-handling option overrides a blocking policy. REST API Duplicate Rule Header

Keep match details on the trusted server side. A public candidate form should never reveal that an email belongs to a confidential candidate record, which recruiter owns it, or what assignments that person has held. A neutral receipt or review message is safer than exposing an internal duplicate-search response.

A worked staffing example

Illustrative scenario: Jordan already has a candidate record and applies for a warehouse role through a new campaign. The ATS also retries an earlier profile update after a timeout.

These events need different outcomes:

1. Jordan's new application is retained with its role, campaign, submission time and contact preferences. After an identity check, it can be linked to the existing candidate.
2. The ATS retry refers to the same source candidate and update. Processing it again should not create another person or repeat a downstream notification.
3. A second applicant using a shared household email is not automatically merged into Jordan's record. The match is reviewed against other appropriate identifiers.

Native duplicate rules can flag likely person matches. Creating an application, resolving identity, making retries idempotent and recording a review decision require the relevant ATS capability, integration logic or additional Salesforce configuration. They are not delivered by a duplicate rule checkbox.

Design matching and resolution together

Prefer a stable ATS identifier for integration identity when the ATS provides one. Keep that identifier distinct from email and telephone fields that people can change or share. Define normalization deliberately: telephone country codes, whitespace and case handling can improve consistency, but aggressive cleanup can erase meaningful distinctions.

A useful review record contains the incoming source identifier, possible matches, reason for uncertainty, owner, decision and links to preserved business activity. Restrict sensitive comparison fields to the reviewers who need them.

Before merging, confirm the surviving record, external identifiers, applications, placements, activities, files and attribution. A merge decision also needs an integration plan: will the ATS still send updates to the retired identifier? Do not test bulk merges directly against production records without a recovery strategy.

Test outcomes rather than the warning message

Build a small, synthetic test set covering:

• An exact person match submitting a genuinely new inquiry
• A near name match with different contact information
• Shared email or telephone details belonging to different people
• A candidate whose matching record the running user cannot see
• A lead matching a contact, including the conversion path
• A retry after the destination saved successfully but the response was lost
• An import containing accepted, duplicate and invalid rows

For each test, verify the submission, person record, owner, application or inquiry, duplicate evidence and integration response. A browser thank-you page alone does not prove a Salesforce record exists. Salesforce documents that duplicate rules can reject imported data; inspect result files instead of treating an upload completion message as success. Salesforce import duplicate guidance

After release, review rejected intake, unresolved duplicate work and repeat-inquiry preservation. Set response expectations from actual volume and risk. The outcome to protect is simple: every legitimate inquiry has a traceable destination, and identity uncertainty has an owner.

Review your intake boundary

Talk through your duplicate-handling workflow with Gosai Digital. Bring the intake channels, current rule configuration and a few anonymized failure examples. We can help identify where a native rule is sufficient and where the surrounding workflow needs attention. Do not send candidate personal data through the initial contact form.