Seasonal temps should not share one vendor-portal password
October arrives, the staffing agency sends twelve names, and someone tapes the vendor-portal password to the monitor again. It feels faster than accounts. It is the wrong first move.
The wrong first move when seasonal temps need a vendor portal is one shared password. It blocks who-did-what, survives January, and turns every supplier update into an unowned event. Create time-boxed personal accounts from the roster before day one, limit roles, expire them automatically, and reserve shared emergency access for a break-glass path you actually audit.
The reflex
Peak is two weeks out. The agency list lands in someone's inbox on Thursday afternoon. Temps start Monday. The vendor portal—where ASNs get confirmed, appointment slots get booked, or invoice PDFs get uploaded—still needs a login.
The reflex is reasonable in the moment: reuse receiving@company and the password on the sticky note. Everyone can "get in." Training can wait. IT is slammed. Monday's truck will not wait for a ticket in the identity queue.
That reflex is the wrong first move. It feels like speed. It purchases a month of fog.
Why it backfires
On Wednesday a supplier ASN is confirmed wrong and a trailer sits. The portal shows receiving@company clicked confirm at 6:41 a.m. Six people were on shift. Nobody can say who misread the quantity. Coaching becomes a group lecture. The supplier hears silence dressed as process.
In January the sticky note is still there. Two temps who left in December still know the password. A third forwarded it to a personal phone "just in case." Offboarding never included the portal because the portal was never individual. We have written about access that outlives the person; shared secrets make that problem permanent by design.
Password resets become theater. Someone uses the shared inbox to reset the shared password, posts the new one in a chat channel, and now the channel history is an archive of credentials. Spam filters and MFA prompts fight the shared mailbox. People disable MFA because "the temp floor can't deal with it," which is how you end up with a high-privilege portal protected like a newsletter list.
Decision guide
Wrong first move vs working order
| Consideration | Shared portal password | Time-boxed personal accounts |
|---|---|---|
| Monday morning | Everyone gets in fast. | Accounts already exist from Thursday's roster. |
| When something breaks | Audit shows a mailbox. | Audit shows a person and a time. |
| January | Password still known to leavers. | Accounts already expired. |
| MFA | Often disabled for the floor. | Tied to individual identity. |
A shared portal password is not onboarding. It is a decision to stop knowing who acted.
The order that works
Roster before day one. When the agency list arrives, create accounts the same day—not Monday at 5:50 a.m. Name them after people. Set end dates when you create them. If your portal cannot expire accounts, put calendar tickets the week before the end date and treat missed expirations as incidents.
Roles that match the season. Temps confirm ASNs and upload documents. They do not change bank details, approve new vendors or download the full supplier list. If the shared account had those powers "because someone needed it once," trim them before you retire the account. A wrong confirmation is recoverable; a wrong bank change is a different class of day—see vendor bank-change callbacks.
Sign-in that survives gloves and shared desks. If the portal only accepts long emailed passwords on a shared PC, people will share. Prefer SSO from the same identity you already use for warehouse apps, or short-lived codes, or badge-backed access. The packing-bench lesson applies: shared Packing 1 logins fail for the same human reasons.
Break-glass, not day-to-day. Keep one emergency shared path if you must, in a sealed procedure, with logging and a page-out when used. Day-to-day work should not know that password.
Prep while October is still calm
Ask the portal owner three questions this week: Can we batch-create users from a CSV? Can accounts expire? What does the audit log show—person or role mailbox? If the answers are no, no, and mailbox, your peak plan still has a sticky note in it, whether you admit that or not.
Tell the staffing agency you need legal names and start/end dates earlier. Build that into the contract language for next year if this year is already late. Process debt likes to hide in "we'll fix identity after the season."
Sequence of work
October prep for portal access
- Week -3
Confirm portal can batch-create and expire accounts.
- Week -2
Agency roster with start/end dates arrives.
- Week -1
Accounts created, roles limited, shared password moved to break-glass.
- Week 1
Temps sign in as themselves; audit log reviewed.
- Week after peak
Expirations fire; break-glass checked unused.
What the floor hears
Temps are not trying to break your security model. They are trying to unload a truck before the appointment window closes. If personal sign-in takes a minute and shared sign-in takes two seconds, shared wins. Design for the two-second path with names attached.
Explain the audit log in plain language on day one: we use names so we can fix mistakes and train people, not to catch anyone out. Floors that hear only "compliance" will work around you. Floors that hear "so we can call the right person when a trailer is wrong" will badge in.
When a temp's account fails on Monday morning, the backup should be a lead who can reset that person's access in under a minute—not a return to the sticky note. Measure mean time to unlock in the first week of peak. If it is long, you will recreate the shared password under a new name called "the lead's login."
If your portal vendor charges per seat, personal accounts can look expensive next to one shared login. Price the alternative honestly: one mis-confirmed ASN, one leaked password reset in chat, one January forensic hunt with no names. Seat cost is visible; fog is not. Most finance partners will fund expiring seasonal seats once you show the audit gap with a real example from last peak—even a mild one.
Pair this work with your packing-bench identity cleanup if you run both. Seasonal people often touch receiving portals and warehouse apps in the same week. Two shared passwords is not twice as convenient; it is twice the January cleanup. One identity program covering both surfaces is the actual shortcut.
Put the sticky-note retirement on the peak readiness checklist next to corrugate and carrier pickups. If it is not on the checklist, it will lose to whatever is.
A Monday that went right
Contrast last year's sticky note with a prepared week. The roster arrives Thursday. IT or ops loads twelve accounts with end dates in January. Receiving leads get a one-page card: how to reset a temp's MFA, who to call if the portal is down, what temps may never click.
Monday at 5:55 a.m., a temp's code fails. The lead resets it in the identity tool in under a minute. The truck is not late. The audit log shows the lead's name on the reset and the temp's name on the ASN confirmations that follow. When a quantity dispute appears at 10:00, you know who to walk to the dock with—not who to lecture as a crowd.
That is what "faster" actually looks like once the first week is over. The shared password only wins the first five minutes of day one. Personal accounts win every hour after.
A shared portal password is not onboarding. It is a decision to stop knowing who acted.
Put this into practice
Find the sticky note. List everyone who knows the current shared password. Schedule the batch create for the next roster. Set expirations. Rotate the shared password into break-glass only. Then ship one truck week on personal accounts and read the audit log on Friday—you should see names, not a mailbox.
We build business process automation that includes the dull access paths vendors and temps actually use. If peak still starts with a shared password, talk to us.
Related work: Sutton|Place.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.