When an employee leaves, stop new company-funded purchases, remove store permissions and active sessions, and handle existing orders separately. Turning off a work email address is not a complete company-store offboarding process. A person may already be signed in, have a separate store password, or hold an unused invitation.
The practical goal is simple: the right people can shop, the right people can spend company money, and someone remains responsible for orders already underway. Those are three different decisions. Treating them as one “delete account” button can leave either an access gap or an avoidable service problem.
This guide is for the HR, IT and program owners defining those decisions together. Brand Sauce publishes it from a company-store planning perspective. The controls below are requirements to verify with your provider, not claims that every Brand Sauce store or every other platform includes a particular integration.
Separate four permissions before choosing a login method
A store can have public product pages while keeping employee allowances private. It can also require a login without correctly limiting who may use a departmental budget. Start with what each person is allowed to do, then decide how they prove who they are.
| Permission | Decision to document | Offboarding question |
|---|---|---|
| Browse merchandise | Public audience or approved employees only? | Should a former employee still see the assortment? |
| Buy with personal funds | Employees only, or approved alumni and guests too? | Is continued self-pay shopping intentional? |
| Spend company funds | Which program, allowance and eligibility period apply? | When does permission to place a new funded order end? |
| Administer the store | Who can issue credit, approve orders, export data or change products? | Who removes these powers and takes over pending work? |
Write an explicit answer for contractors, interns, franchise operators and seasonal staff. Do not infer gift eligibility from a familiar email domain. Conversely, a recipient without a company mailbox may be legitimately eligible. Exceptions need an owner, an end date and a supported way to order.
For technical implementation, OWASP distinguishes authentication from authorization and recommends default-deny access with permissions checked on every request. Applied to a store, a successful login should not automatically authorize every budget or every order record. See the OWASP authorization guidance.
Compare login models by how access ends
Ask vendors to demonstrate removal as carefully as enrollment. The easiest invitation experience is not necessarily the easiest process to maintain through transfers, departures and rehires.
| Access model | Useful fit | What to verify |
|---|---|---|
| Individual store accounts | A defined recipient list without a shared corporate identity system | Who disables accounts, what happens to existing sessions, and whether password recovery can restore access |
| Company single sign-on | Employees already managed through a corporate identity provider | How removal reaches the store, whether local logins remain, and how long existing sessions survive |
| Recipient-specific invitations | A limited gift campaign or approved external audience | Recipient binding, redemption limits, cancellation and behavior after an invitation is forwarded |
| A shared store password | A limited browsing gate with no individual identity established by that password | What separate control actually protects personal records and company-funded purchases |
A shared password alone cannot tell you which individual is shopping. Changing it may inconvenience everyone while leaving other access paths untouched. If it exists, describe its purpose accurately rather than presenting it as individual employee lifecycle management.
Single sign-on, or SSO, also needs a specific exit design. Microsoft documents that an application can issue its own session cookie, which Microsoft Entra ID cannot directly revoke. The application's configuration and deprovisioning behavior matter. “We disabled their company account” therefore does not prove the store's existing session has ended. See Microsoft's access-revocation guidance.
Request a written answer to two questions: what starts removal, and what is the longest expected delay before removal takes effect? Include the fallback if an automated update fails. Do not accept “real time” without an explanation of the actual behavior being promised.
Give each lifecycle change an owner
Build the merchandise program into the existing employee-change workflow instead of asking a store administrator to notice departures informally. The following is a suggested operating arrangement, not a universal organizational requirement.
- HR or the sponsoring team supplies the approved eligibility change and effective time.
- IT or the identity owner handles corporate authentication changes and confirms the integration's behavior.
- The store administrator or provider removes store-specific access, reviews local accounts and checks outstanding work.
- The program budget owner decides how remaining promotional allowances and pending funded orders are handled under the program's terms.
- Customer support keeps an appropriate route open for an existing shipment or order issue.
Use an internal recipient identifier where possible so a name change, new email address or department transfer does not accidentally create another welcome allowance. Confirm how the platform links identities before importing updates. Avoid sending an entire HR record merely to communicate “this recipient is no longer eligible.”
Transfers deserve their own workflow. Someone moving from sales to engineering may keep shopping access but lose authority over a sales budget. Update approval responsibilities and department allocation together. Our guide to department-level company-store budgets covers the financial ownership side.
Use a two-track employee exit checklist
The first track closes access; the second resolves merchandise commitments. Neither should depend on an administrator remembering the other later.
Track one: stop new actions that are no longer authorized
- Confirm the recipient, effective time and approved scope of removal.
- Disable the relevant store account or eligibility and remove any administrator role.
- Revoke active store sessions using the provider's supported controls. Address separate local sign-in and recovery routes as well as SSO.
- Cancel unredeemed invitations or campaign permissions where the program policy requires it.
- Check scheduled future grants so a later campaign does not automatically restore an allowance.
- Record completion and any failed step, with a named person responsible for resolving it.
OWASP's session guidance calls for server-side session invalidation; clearing a browser cookie alone is not the same control. Ask the provider how its supported disable function affects an already-open session. The relevant technical reference is the OWASP session-management guide.
Track two: resolve orders, credits and support
- Find orders awaiting approval, accepted orders, production jobs and shipped parcels.
- Have the authorized program owner decide what should proceed, using the agreed order and cancellation terms.
- Ask the provider which changes are still possible; do not assume decorated goods can be canceled because account access ended.
- Reassign outstanding approvals if the departing person was a manager or administrator.
- Document the disposition of program-funded promotional allowances. Keep purchased gift cards, personal payments and refunds separate for review under their applicable terms.
- Provide a verified support route for any order that remains open, without restoring unnecessary shopping or administrative access.
For example, imagine a departing employee has a sweatshirt already in production and an unused future welcome-event allowance. In this hypothetical workflow, the sponsor may let the approved sweatshirt ship while ending eligibility for new purchases. That is a program decision, not evidence that a particular provider supports automatic handling.
Run six acceptance tests before launch
Use authorized test accounts and non-production orders, not a real departing employee's account. Agree on the expected result first, observe what happens, and record the time and configuration. These are buyer acceptance scenarios, not a substitute for a security assessment.
| Test | Evidence to request |
|---|---|
| Disable a shopper while their store tab is open | The next protected action is denied within the agreed removal window |
| Try each configured sign-in route after removal | A separate local login or recovery path does not undo the intended restriction |
| Remove an administrator who has a pending approval | Administration is blocked and the approval has a new owner |
| Change a shopper's department | The old allocation is unavailable and the new allocation matches the approved policy |
| Replay an unused invitation after eligibility ends | The invitation follows the documented cancellation or exception rule |
| Temporarily interrupt the eligibility update | A visible failure reaches a responsible owner and a manual removal procedure is available |
Also test an allowed action after removal: support should still be able to locate the approved shipment when appropriate. A process that blocks everything indiscriminately may pass an access test while failing the recipient experience.
For a rehire, decide whether prior order history should remain linked and whether a new gift is actually authorized. Do not silently reset all spending permissions simply because an old account becomes active again. Include this scenario in the broader company-store launch checklist.
Disable access without keeping personal data forever
Access removal and data deletion are different operations. An account can stop accepting new orders while an authorized team retains records needed to resolve an existing purchase. Conversely, keeping an invoice does not mean keeping an unrestricted employee profile or every old export.
The FTC advises businesses to collect only information they need, limit access and retain personal information only for a legitimate business need. Use its business data-protection guide as a foundation for the retention discussion, then have the appropriate owners set your actual schedule.
For this program, make a small data register: information type, purpose, authorized users, storage location and deletion trigger. Include recipient lists, delivery addresses, support attachments and administrator exports. Record exceptions for unresolved disputes or other applicable obligations rather than promising immediate deletion of every transaction.
An offboarding ticket should show who requested the change, who completed it, the effective time and the verification result. It does not need to reproduce the person's home address. During a provider change, include unresolved removals in the store migration handoff so a fresh import does not re-enable the wrong people.
Does on-demand make offboarding easier?
It can reduce the need to assign pre-purchased sizes to people who may no longer join or remain with the company. It does not replace access controls, prevent duplicate eligibility, or guarantee that an accepted custom order can be stopped.
Bulk remains sensible when a stable group needs the same goods at a fixed event, or when the chosen decoration and quantity justify a planned run. The administrator still needs a current distribution list and a plan for unissued items. A hybrid program might hold event stock while using an ongoing store for individual requests.
Choose production around demand, deadlines and the product. Choose access controls around identity, spending and responsibility. A warehouse and an on-demand decorator both need to know whether an order is authorized; neither can infer that from how the goods are made.
Frequently asked questions
Is SSO required for a small employee store?
Not necessarily. Individual accounts with a reliable, owned removal process may fit a small program. Compare the ongoing administrative work and required removal speed, not just whether SSO appears in a feature list.
Should former employees lose access to order tracking?
Decide separately from new shopping eligibility. An existing order may still need support. Use a provider-supported, appropriately verified way to handle that order without restoring company-funded purchasing.
Who should decide what happens to unused balances?
The authorized program owner, with finance or other relevant review. First identify what the balance represents. A discretionary company allowance is not automatically equivalent to personally purchased value, and the store administrator should not improvise one rule for both.
What should we ask Brand Sauce or another provider to show us?
Ask for the complete journey: enroll a test recipient, issue the intended permission, place a test order, remove eligibility and verify both the open session and the outstanding order. Request the actual controls, supported integration, timing and ownership in writing. A clear offboarding demonstration is more useful than a security adjective on a sales slide.
Primary-source guidance checked September 25, 2026. Workflow tables and examples are editorial recommendations, not measured customer outcomes or a claim of platform certification.
