Prevent duplicate employee gifts by recording one approved entitlement per person and occasion, then making every import, retry and manual request check that same record. Deduplicating email addresses in a spreadsheet is useful housekeeping, but it does not stop a second gift when a person changes email, an integration retries, or a manager submits the same request through another channel.
The business rule should survive the delivery mechanism. Whether HR uploads a file or an automated connection sends updates, the system should recognize an already-authorized welcome gift without treating every new message as a new spending instruction.
This guide is for HR, IT and company-store owners deciding whether a gifting workflow is ready for automation. Brand Sauce publishes it and provides company-store services. The design below is an editorial framework to discuss with your provider, not a claim that Brand Sauce includes a particular HR integration, API or duplicate-prevention feature. Technical sources were checked October 1, 2026.
First define what counts as a duplicate
“One gift per employee” is usually too broad. An employee may legitimately receive a welcome gift, an anniversary gift and a conference item. The same person might also need an approved replacement for a damaged shipment. Blocking everything after the first order would prevent valid purchases.
Define the entitlement as a specific benefit for a specific occasion. For example: one welcome selection for a particular employment start, or one recognition allowance for a named campaign. Keep the benefit separate from the order that eventually fulfills it.
| Record | What it answers | Why it matters |
|---|---|---|
| Recipient identity | Which person is this within this organization? | A new email must not automatically create a new person |
| Entitlement | What approved benefit does this person have for this occasion? | Two requests can refer to the same benefit |
| Order or fulfillment record | What goods were actually requested or released? | A replacement is not automatically a new entitlement |
| Incoming event or import row | What update reached the system? | Repeated messages must not multiply the benefit |
Write the rehire rule explicitly. Does a second employment start qualify for another welcome gift? If yes, it needs a distinct, approved occasion. A department transfer or corrected start date should not silently become a second occasion. HR owns this policy; an integration should implement it, not invent it.
Use stable identity, not an email-only match
Ask the HR data owner for an approved, stable internal identifier and its scope. Store a mapping between that identity and the provider's recipient record. Names and email addresses remain useful contact information, but should not be the only evidence used to decide whether a benefit already exists.
A standards example helps explain the distinction. The SCIM core schema, RFC 7643, distinguishes the service provider's resource ID from an optional client-supplied externalId. That external identifier is scoped to the provisioning domain; the specification does not require the server to enforce its uniqueness. A field labeled “external ID” therefore is not, by itself, proof of duplicate prevention.
For a company store, ask who creates the mapping, who checks collisions and how it survives an HR-system migration. Include the organization in the identity scope: employee number 1042 in one client organization must not match number 1042 in another. Do not resolve ambiguous matches automatically just because two people share a name.
Keep the exported fields narrow. The grant decision may require an identifier, approved occasion, eligibility status and program allocation—not the full HR profile. Our employee gifting data-handoff guide covers that boundary in more detail.
Protect both message delivery and the business decision
There are two different duplicate problems. First, the same technical message can arrive again. Second, different messages can ask for the same business benefit. Handling only one leaves a gap.
Shopify's webhook documentation explains that deliveries can repeat after a timeout or retry. It distinguishes the webhook delivery identifier used for deduplication from an event identifier that correlates deliveries originating from the same merchant action. Those are Shopify-specific semantics, not universal header names for other platforms.
Even perfect delivery deduplication would not catch an HR import and a manager's manual request if each has a different message ID. Both should resolve to the same entitlement rule. A practical design uses a unique combination of organization, internal recipient identity, program and occasion in its own controlled records.
For IT, the important question is whether that uniqueness is enforced atomically. If two workers both check “no grant exists” and then each creates one, a check-before-create routine has not solved the problem. Ask for a database uniqueness constraint, transactional reservation or another supported mechanism that prevents two simultaneous approvals of the same entitlement.
Use opaque operation identifiers when making external API calls; do not put employee names or email addresses into request keys. Keep the identity-to-operation mapping in access-controlled internal records. A technical message ID tells you what arrived; an entitlement key tells you what the business has already authorized.
Treat a timeout as unknown, not as failure
Consider a hypothetical welcome-gift workflow. The store accepts a grant request, but the response never reaches the integration. If the integration sends a completely new request, it may create a second grant. If it never retries, the employee might remain stuck when the original request actually failed.
The integration needs an explicit “outcome unknown” path. Where the provider supports idempotency, retry the same logical operation using the same supported request key and unchanged parameters. Idempotency means repeated attempts are handled without repeating the intended effect.
Stripe's API documentation is a useful concrete example: it describes returning a saved result for a repeated key and checking that parameters match. It also says keys can be removed after they are at least 24 hours old, with reuse after removal treated as a new request. That is Stripe's behavior, not a promised retention window for a merchandise platform.
The implication for a gifting program is to keep durable entitlement history rather than relying solely on a provider's temporary retry protection. Ask your actual provider about supported operations, key scope, retention and lookup. If it cannot safely retry or locate an uncertain request, route that request to reconciliation before issuing another grant. Silence is not evidence that nothing happened.
Give every issuing path the same ledger
A useful minimum record includes the internal entitlement ID, recipient reference, program and occasion, approved value or item limit, decision status, provider reference, last action and responsible owner. Separate benefit status from message-delivery status. “Invitation sent” does not mean “gift ordered,” and neither proves a parcel was delivered.
Record an intended action durably before trying to deliver it to another system, and track its result. Engineering teams may implement that with a transactional outbox or an equivalent supported pattern. The key outcome is recoverability: after a process restarts, a worker can find unfinished work without inventing a second benefit.
- HR imports: update known recipients and show proposed new entitlements before release.
- Automated events: verify the sender through the provider's supported mechanism, then apply the same eligibility and uniqueness rules.
- Manual requests: search the existing entitlement before creating anything; record the requester and reason.
- Support replacements: link to the original order and approved recovery decision instead of resetting welcome eligibility.
Do not make an administrator's manual button a bypass around the control. If an authorized exception is necessary, preserve the original record and add a separately approved adjustment with a reason. The department-budget guide explains the accompanying funding responsibilities.
A worked import example: 108 rows, not 108 gifts
This is an invented reconciliation example, not a measured customer result. Imagine an approved campaign file contains 108 rows. Six repeat another row for the same recipient and occasion. Two are email updates for recipients already present among the remaining rows. After those eight repeats are resolved, the file represents 100 distinct entitlements under the campaign rule.
Suppose 12 of those 100 entitlements already exist in the program ledger. The run proposes 88 new grants, retains the existing 12 and reports the eight redundant rows. It does not erase the existing grants to make the file totals look tidy.
| Reconciliation line | Illustrative count |
|---|---|
| Input rows | 108 |
| Redundant rows resolved | 8 |
| Distinct recipient–occasion entitlements | 100 |
| Already represented in ledger | 12 |
| New grants proposed | 88 |
That arithmetic assumes the identity matches are resolved and everyone is eligible. If a row has conflicting identifiers or uncertain eligibility, show it in a separate review bucket and adjust the release count. Do not label an unresolved row a duplicate just to balance the report.
After processing, reconcile the 88 proposed grants against confirmed provider records and unresolved outcomes. Re-running the same file should propose zero additional grants once those original operations are resolved. It should still display any unfinished work.
Require these seven demonstrations before automation
Use authorized test recipients and a non-production environment where available. Agree on the expected results before the demo, and retain the configuration and evidence—not real employee addresses in screenshots.
| Scenario | Expected result |
|---|---|
| Upload the same file twice | No additional benefit; the second run identifies existing entitlements |
| Change a recipient's email and import again | The contact field changes without another grant |
| Submit the same occasion simultaneously through two paths | One entitlement wins; the other request links to it |
| Lose the response after provider acceptance | Retry or reconciliation finds the original operation |
| Replay an old request after the retry-key retention window | Durable benefit history still prevents an unauthorized new grant |
| Submit a rehire or new anniversary occasion | The written eligibility policy allows or holds it intentionally |
| Restart processing after recording work but before sending it | Unfinished work resumes without a lost or doubled benefit |
Also ask who receives unresolved exceptions and who can authorize recovery. A dashboard showing a queue is not enough if nobody owns it. These tests belong in the wider company-store launch checklist, before a production HR connection is enabled.
When is a controlled manual process enough?
A small, occasional campaign may not justify a custom integration. One approved recipient–occasion register, one issuing owner, a preview of new grants and a reconciliation after each batch can be a sensible starting point. Avoid concurrent editing and parallel issuing from separate copies; a spreadsheet is not an atomic multi-user transaction system.
Automate when repeat volume or multiple issuing channels make that ownership model difficult to maintain—and only when the provider can demonstrate reliable recovery. API availability alone is not the decision. Implementation, monitoring and support costs require a quote if they are not published for your proposed configuration.
Production method is a separate choice. On-demand can avoid buying inventory before recipients select, but it does not prevent duplicate entitlements or duplicate decorated orders. Bulk can fit a fixed event with an approved distribution list. A hybrid program can combine event stock and an ongoing store, provided both channels record which benefit has been fulfilled.
Frequently asked questions
Does single sign-on prevent duplicate gifts?
No. Identifying a signed-in person is different from deciding whether that person has already received a particular benefit. Ask how the store connects identity to the entitlement ledger.
Can we match only on email for a one-time campaign?
It can be a practical review field, but document its limitations. Email changes, aliases and duplicate submissions need a resolution process. For recurring programs, an approved stable identifier makes the policy easier to maintain.
Should a canceled order restore the gift automatically?
Only under a defined rule. Confirm cancellation with the provider, determine whether any value or production commitment remains, and record the approved entitlement adjustment. Do not treat a timeout as a cancellation.
What should we ask Brand Sauce or another provider?
Bring your identity source, gift occasions, issuing channels and exception rules. Ask the provider to demonstrate a repeated import, simultaneous requests and an uncertain outcome using the actual proposed configuration. For a managed company-store discussion, make duplicate prevention and reconciliation explicit requirements—not assumptions hidden behind the word “integration.”
