The When I Work login page authenticates an employee or manager against a tenant-scoped account and then hands off a session token that controls every scheduling action afterward. It is not a generic username-and-password gate. The page must resolve which organization you belong to, confirm your identity, and decide which permissions travel with you into the shift schedule. Understanding that three-part sequence explains most login failures, lockouts, and "wrong account" confusion users report.
When I Work is a workforce scheduling platform used by hourly teams in retail, food service, healthcare support, and similar operations. Employees typically log in through a web portal or the mobile app using work email, sometimes a phone number, or single sign-on if the employer configured it. The mechanics below apply to that credential flow generally. Specific menu labels, plan tiers, and prices change, so treat interface details as directional rather than fixed.
Mechanism: How the credential handoff actually works
The login page is a thin client. When you submit credentials, the browser or app sends them over TLS to an authentication service. That service does not compare your password directly against a stored copy. It runs your input through a key derivation function and compares the derived value against a stored hash. Modern systems use slow, memory-hard hashing deliberately. A slow hash turns a stolen database into a costly brute-force problem rather than an instant dump of plaintext passwords.
Fernet encryption and similar token schemes appear in When I Work's public API documentation, which tells you something structural. After authentication, the platform issues a session token that encodes identity and tenant scope. That token is presented with each subsequent request instead of your password. This is why your password never needs to travel again after login, and why revoking a session can log you out without changing your password. Plain language: the login page issues a temporary badge, and the badge, not your password, opens later doors.
Tenant routing is the underappreciated step. A single email address can, in principle, be associated with more than one employer account. The login flow must disambiguate. When it cannot, you see symptoms like a schedule that looks empty, a "no account found" message on a correct password, or a prompt to join an organization. The credential succeeded but the tenant resolution failed. Those are different failures with different fixes.
Session lifetime matters too. Tokens expire, and refresh behavior differs between the web app and mobile app. A web session may lapse after a period of inactivity while the mobile app holds a longer-lived credential. That asymmetry explains why the same person is logged out on a laptop but still authenticated on a phone.
Quantified context: what the numbers behind a login tell you
Every login is a small transaction with measurable costs and tolerances. Password hashing deliberately consumes time and memory, often tens to hundreds of milliseconds per attempt depending on the algorithm and server load. That cost is invisible at one login and punishing at scale, which is exactly the point.
Rate limiting is the second number that matters. Authentication endpoints throttle repeated attempts, often after a handful of failures within a short window. The threshold is a design choice, not a universal constant, so avoid assuming a specific count. What you can rely on: failures accumulate against a window, and the window resets with time or a successful reset. Account lockout, where it exists, is a separate control from rate limiting and may trigger at a different count.
Token lifetimes are the third. Short-lived access tokens paired with longer refresh tokens are common. The practical consequence is that a stolen access token has a bounded useful life, while a stolen refresh token is more dangerous. This is why logging out everywhere matters after a suspected compromise.
Error-message design is the fourth. Many systems return a deliberately vague "invalid credentials" message rather than revealing whether the email exists. This frustrates users but protects against account enumeration. If a login page tells you "that email is not registered," it has traded a small security property for convenience. Neither choice is wrong, but they produce very different troubleshooting experiences.
Timeline: the life of a single login attempt
| Stage | What happens | Typical observable | Where it can fail |
|---|---|---|---|
| 1. Submission | Credentials sent over TLS | Spinner or button disable | Network drop, expired TLS trust, browser extension interference |
| 2. Rate check | Endpoint checks failure window | Usually invisible | Throttle or lockout if prior failures accumulated |
| 3. Hash comparison | Input hashed, compared to stored value | Generic or specific error | Wrong password, stale hash after migration |
| 4. Tenant resolution | Account mapped to organization(s) | Prompt to choose or "not found" | Email belongs to no active org, invitation expired |
| 5. Token issuance | Session and refresh tokens minted | Redirect to schedule | Token service outage, clock skew |
| 6. Session use | Token presented with each request | Schedule loads | Revoked session, expired token, device change |
| 7. Refresh or expiry | Token renewed or lapsed | Occasional re-login | Long inactivity, password change elsewhere |
The timeline is useful because it separates "my password is wrong" from "my account exists but belongs nowhere." Most support requests conflate stages 3 and 4. A correct password with an unresolved tenant produces a failure that looks identical to a bad password on a poorly designed page. Ask which stage failed before resetting anything.
Edge cases: where the tidy model breaks
Single sign-on changes the flow substantially. When an employer enables SSO, the When I Work login page may redirect you to an identity provider instead of collecting a password itself. Your credential then lives with that provider, and the scheduling platform only receives an assertion. This is more secure and considerably harder to self-diagnose. If SSO is enforced, a password reset on the scheduling platform will not help, because the platform does not hold your password.
Invitation expiry is a common edge case. New employees often receive an invite link that expires after a set period. Clicking a stale link can create an account-looking dead end. The fix is a re-invite from a manager or administrator, not a password reset. This distinction trips up onboarding at exactly the moment a new hire is least familiar with the system.
Shared devices create a different failure. Employees logging in on a workplace tablet or kiosk can inherit a previous user's session if logout is skipped. The next person sees someone else's schedule or gets access errors. Always confirm the visible name before clocking in on a shared device, and log out explicitly.
Email aliasing and phone-number logins add ambiguity. Some accounts use a phone number, and changing that number without updating the account can strand a user. Corporate email aliases can also resolve differently than the primary address. If you recently changed jobs internally or switched devices, suspect the identifier before suspecting the password.
Timezone and clock skew are rarer but real. Token validation depends on clocks agreeing. A device with a badly set clock can fail token checks in ways that look like random logouts. Automatic time synchronization fixes this.
Misconceptions: what the login page is not doing
A persistent misconception is that the login page stores your password. It does not, in any well-built system. It stores a hash. Resetting your password does not "retrieve" anything; it overwrites the stored hash with a new one derived from your new input. No support agent can read your old password, and any claim otherwise is a phishing signal.
Another misconception is that being logged in means being authorized. Authentication proves who you are. Authorization decides what you can see. A logged-in employee with a limited role will still be blocked from manager functions. If you can log in but cannot open a schedule, the problem is permissions or tenant scope, not credentials.
A third is that clearing your browser cache is a universal fix. It helps with stale cookies and cached redirects, and it hurts nothing, but it does not address lockouts, expired invitations, or SSO configuration. Reach for it after you have identified the failing stage.
The counterintuitive detail worth flagging: a longer, uncommon passphrase is generally stronger than a short, complex password with forced symbols. Length buys more resistance against guessing than symbol substitution does. Systems that cap password length or strip spaces are weakening users, not protecting them.
Red flags and warning signs
Watch for these during and after login. Several are security issues rather than convenience issues.
A login page on a domain that is not the expected employer or vendor domain, especially one reached through an emailed link. A prompt to re-enter your password immediately after logging in, outside the normal flow. Any request for a one-time code that you did not initiate, which can indicate an attacker mid-attempt. Messages that pressure urgency, such as a schedule deletion threat requiring immediate login. Certificate warnings or "not secure" indicators on a page asking for credentials. A schedule, location, or manager name that does not match your actual workplace.
Each of these is a reason to stop, not a reason to troubleshoot faster. When in doubt, navigate to the login page directly rather than through a link.
Practical actions: a staged troubleshooting sequence
Work the stages in order instead of resetting passwords repeatedly, which can deepen a lockout or waste a reset token.
Step one: confirm the identifier. Verify the exact email or phone number on file, including any alias. Ask your manager which one the account uses. This resolves a surprising share of "wrong password" reports before any reset.
Step two: check the failure message type. A generic invalid-credentials message points to stage 3. A "no account" or "join organization" message points to stage 4. Write down which one you see.
Step three: try the password reset once, and use a fresh link within its validity window. If SSO is enabled, the reset may be irrelevant, so confirm with your administrator first.
Step four: test a different surface. If the web portal fails but the mobile app works, the problem is likely session or cookie-related on the browser. If both fail identically, suspect credentials or tenant scope.
Step five: escalate with specifics. Give your administrator the exact message, the surface (web or app), the approximate time, and whether SSO is in play. Specifics cut resolution time sharply compared with "I can't log in."
Step six: after any suspected compromise, change the password from a trusted device, log out of all sessions where the option exists, and report it. Do not reuse the compromised password anywhere else.
For shared or kiosk devices, add a habit: check the displayed user name before every action and log out when finished. For administrators, set invitation expiry thoughtfully, keep SSO configuration documented, and ensure at least one recovery path exists that does not depend on a single identity provider.
Limitations and what this explanation cannot tell you
Interface specifics, plan features, prices, and support policies for When I Work change over time. This article explains the stable mechanics of credential flow, token issuance, and tenant routing rather than the current state of any menu or plan. It also cannot diagnose your specific account, because the cause depends on data only your administrator can see, such as account status, invitation state, and SSO configuration. Where a threshold or failure count is described, treat it as a design pattern rather than a guaranteed number for this platform. When troubleshooting stalls, the authoritative source is your organization's administrator and the vendor's official support documentation, not a general explainer.
This article is general educational information about how login systems work, not a security audit, legal opinion, or account-specific diagnosis. It does not promise any outcome from the steps described. For suspected account compromise, contact your organization's administrator or IT security team, and for immediate danger or a security emergency, contact local emergency services.