Use a shared gift code when a controlled group can legitimately draw from the same pool. Use individual, recipient-bound access when each employee must retain a separate gift entitlement. A unique link is not automatically recipient-bound: if anyone holding it can claim the gift, forwarding the invitation transfers practical access. Choose the authorization rule first, then choose how to deliver it.
This distinction matters most when a program moves beyond a small, supervised handout. A code that works perfectly at a staffed appreciation table may be the wrong mechanism for a distributed anniversary program. Conversely, requiring every event visitor to create an account can add work without protecting a meaningful individual benefit.
Brand Sauce publishes this guide and provides company-store services. These are procurement and implementation recommendations, not claims that every Brand Sauce store includes the controls described. Ask your provider to demonstrate the proposed configuration. Official technical sources were checked October 2, 2026.
Compare four access models, not just codes versus links
A code is something a person enters; a link is something a person opens. Either can lead to a weak or strong authorization process. Separate the visible invitation from the rules enforced behind it.
| Model | What authorizes the gift? | Useful fit | Main tradeoff |
|---|---|---|---|
| Shared campaign code | The same code works for a group, subject to configured rules | Supervised events or a deliberately shared allocation | Distribution alone does not prove individual eligibility |
| Unique bearer code or link | Possession of one redeemable credential | Private invitations where transfer risk is acceptable | A forwarded or exposed credential may be usable by someone else |
| Recipient-bound claim | A credential plus a verified match to an eligible recipient | One gift per employee or a sensitive recognition tier | Identity mismatches need a support route |
| Authenticated store entitlement | A signed-in account with an approved benefit | Ongoing programs with repeat visits | Account provisioning and recovery become part of gifting operations |
A unique invitation can also send someone into an authenticated store. That is a combination of models, not a fifth magic security category. In the demonstration, ask what happens after the invitation is copied into a browser signed in as somebody else.
Write the employee promise before configuring checkout
Use a short rule such as: “Each eligible employee can select one item from the anniversary collection, with standard delivery funded by the company.” This is more precise than “Give everyone a gift code.” It defines the person, occasion, quantity, assortment and delivery promise that the system must preserve.
Then specify exceptions. Can a manager select on someone’s behalf? May two employees ship to the same household? Can an employee decline now and choose later? Is an unused portion lost, retained or irrelevant because the offer is one item rather than a monetary allowance? The invitation should describe the actual policy, not leave recipients to discover it through checkout errors.
Do not confuse a discount with a complete gift benefit. A discount may reduce merchandise price while leaving delivery or other charges payable. Test the funded item with the intended destination and shipping method. If an employee can add extras, make the personal amount due explicit before confirmation. These checks protect the experience described in our guide to letting employees choose their gifts.
A campaign cap, customer limit and item limit solve different problems
A total-use cap limits how often a campaign credential can be used. A per-customer limit restricts repeated use by the customer identity recognized by the platform. A quantity rule limits what one accepted order contains. None should be treated as a substitute for the others.
For a concrete platform example, Shopify’s discount FAQ describes both total-use and one-use-per-customer limits. It also explains that product-specific discounts can apply across multiple quantities, depending on configuration. This illustrates why “one use” and “one gift” need separate acceptance tests; it is not a claim about another platform’s behavior.
Consider an illustrative, not measured, scenario: a program has 120 eligible employees and a shared code capped at 120 accepted uses. If eight uses go to ineligible people, only 112 uses remain for the intended group. The cap contains the count but does not preserve each employee’s allocation. Increasing it to 128 restores capacity without correcting the eligibility problem.
Ask the provider what establishes the customer identity used for its limits. An entered email address, a verified inbox and an authenticated employee account are different controls. Do not accept “one per person” as a complete answer without a demonstration of the identity check.
When a shared code is a reasonable choice
A shared code can be appropriate where access is already controlled elsewhere and the program owner accepts pooled allocation. For example, a staffed event can confirm attendance before helping a person place an order. A team lead might manage a bounded departmental allocation rather than promise a private, individual benefit.
The shared code should still have a defined collection, an intentional quantity rule, a closing time and a named owner who can pause it. Limit distribution to the intended channel. A sign in a public lobby and a message inside an authenticated employee portal create different exposure, even if they display identical characters.
Do not make the code permanent simply because recipients remember it. Separate campaigns when their rules differ, and retire access when the relevant allocation ends. However, changing the code is not a reliable way to preserve prior redemption history: Shopify documents that a newly created replacement discount has its own per-customer usage allowance. Verify how your provider handles replacement credentials before issuing them.
For a fixed-date gathering, bulk purchasing with a supervised handout may be simpler than online redemption. A hybrid can provide stocked items at the event and individual choice afterward for absent employees. On-demand production can suit dispersed, ongoing selection, but it does not by itself establish who may claim a gift or guarantee a delivery deadline.
When individual access earns its extra complexity
Prefer recipient-bound access when every eligible person must have a protected allocation, benefits differ by occasion, or the program needs recipient-level exception handling. A shared pool can be exhausted by other people; an individually recorded benefit can remain available to its owner, subject to the program rules.
Make the identity requirement proportionate. For an ongoing employee store, an existing approved sign-in process may be convenient. For deskless employees without routine work-email access, a privately distributed claim route plus a supported verification step may be more practical. Do not announce a process that assumes everyone can receive the same kind of invitation.
Ask whether the invitation exposes a balance, address or recognition category before verification. Prefer a neutral landing page until the recipient has established access. A support representative should be able to investigate using a non-secret reference, not require the employee to paste a live claim link into a broadly visible help channel.
Two employees sharing an address should not automatically be treated as one person. Nor should a manager be allowed to claim every direct report’s gift merely because they know the team’s email addresses. Put delegated selection behind an explicit program rule and record who acted for whom.
Review the life of a link, not just its first click
For links that themselves authorize access, ask the technology owner about unpredictable tokens, protected storage, expiry, revocation and controls against automated guessing. OWASP’s password-reset guidance recommends these kinds of protections for security-sensitive URL tokens. Applying that principle to gift-access credentials is our engineering recommendation, not a statement that password-reset rules certify a gifting product.
Distinguish the invitation’s technical lifetime from the employee’s gift eligibility. If a short-lived access link expires, the recipient may still deserve a fresh link to the same unclaimed benefit. Support should replace access without silently creating another gift.
Also test the actual corporate mail path. Microsoft documents Safe Links scanning and rewriting of inbound email URLs and checks at click time. That does not prove any particular store will fail. It is a reason to include your organization’s mail protection in the pilot and avoid treating a page view as evidence of deliberate gift acceptance.
Our recommended sequence is: open the invitation, establish access, show the available benefit, and request an explicit selection or confirmation. Define which event consumes the entitlement. A landing-page visit, a saved cart, an accepted order and a shipped parcel are not interchangeable milestones.
Run this eight-case acceptance test before invitations go out
Use fictional test recipients and non-production allocations. Have HR define the expected business outcome and the provider show the result. Record failures as launch blockers or consciously accepted limitations—not as promises to explain later.
| Test | Required question |
|---|---|
| Forward the invitation | Can another person claim it, and is that consistent with the chosen model? |
| Add two eligible items | Does one gift mean one item, one order or a capped value? |
| Open on two devices | Can concurrent checkouts create more than one approved claim? |
| Use the corporate email route | Does link protection preserve a usable invitation without consuming the benefit? |
| Change the entered email | Is the eligibility check actually enforced? |
| Abandon or fail checkout | Can support distinguish a temporary hold from a completed order? |
| Replace an invitation | Does old access stop working while the same benefit remains correctly recorded? |
| Reach the deadline | Is the closing time clear, and can approved exceptions be handled privately? |
The unfinished-checkout case deserves particular attention. Shopify’s FAQ describes circumstances where an incomplete checkout can retain a discount-use hold. Other systems can have different states. Teach support to inspect the order and claim records before issuing a replacement; “already used” is an error message to investigate, not proof of misconduct.
Make recovery and reporting match the access model
For a shared-code exposure, determine whether to pause the campaign, review unfulfilled orders and issue a new controlled route. For an exposed individual credential, revoke that credential and investigate the associated benefit. Do not reset the whole campaign when one employee needs help unless the platform leaves no narrower option.
Report eligible recipients, successfully notified recipients, confirmed selections and completed fulfillment separately. A shared code’s usage count cannot by itself tell you which eligible employee still needs an invitation. An individual link click is not a confirmed selection. Follow-up should be based on the relevant unclaimed benefit, as explained in our unredeemed employee gifts playbook.
Finally, invitation controls do not fix duplicate benefits created upstream. Keep one approved person-and-occasion record even when access is reissued. Our guide to preventing duplicate gifts during HR imports addresses that separate integration problem.
Frequently asked questions
Is an individual link always safer than a shared code?
No. A transferable link can be used by whoever receives it. The meaningful comparison is between pooled access, unique bearer access and verified recipient-bound access. Inspect the rule, not the invitation format.
Should every employee have to create an account?
Not necessarily. Existing sign-in may fit an ongoing store, while a bounded one-time program may justify a simpler verified claim route. Include employees without regular work-email access and provide assistance that preserves their choice.
Can we use one code but still restrict it to employees?
Potentially, if the store enforces a separate eligibility check. Sending the code only to employees is not the same as enforcing that check at redemption. Ask the provider to demonstrate an ineligible attempt.
What should a provider proposal specify?
Request the access model, identity check, quantity and spend rules, expiry behavior, recovery owner, reporting fields and results of the eight tests above. Ask for pricing and any integration work to be quoted for that exact scope. The best option is the one that preserves your employee promise with an operating burden your team can actually support.
