BreezyCorp Handbook

Appearance

The magic link expired before the client opened it ​

A client tells you "the link doesn't work" or "it says the link has expired". Magic links carry a 48-hour TTL by design — they're meant to be short-lived because they grant access to the portal without a password. This is almost always one of three things; work them top to bottom.

NOTE

The 48-hour TTL applies to every magic link the platform sends — cycle requests, approval requests, action-required asks, and the bookkeeping client portal. Reminders mint fresh tokens; manual resends mint fresh tokens. There's no setting to extend the TTL on a per-client basis.

1. More than 48 hours have passed ​

The default lifetime for every cycle-request, approval-request, and client-action magic link is 48 hours. After that, the link refuses to authenticate the user — they get an expired link page rather than the portal.

Check: open the Outbox, find the original email row, and read the Created column. If it's more than 48 hours ago, the link is dead.

Fix: mint a fresh link. Which action you take depends on what they were trying to do:

  • They were going to submit intake — open the cycle, click Request info from client, write a short note ("Re-sending the link, the previous one expired."), and send. This generates a fresh 48-hour link addressed to the same submitter contacts. See Request info from client.
  • They were going to approve — open the cycle's Approval tab and click Request approval (or Resend) to mint a new link to the active approver. See Request client approval.
  • The cycle hasn't moved out of REQUESTED yet — start the cycle again from the cycle page (re-trigger). The platform doesn't create a duplicate cycle; it just resends the invitation with a fresh token.

TIP

All four of the day-2 / day-5 / day-7 reminders also mint fresh tokens automatically. If the client just needs to wait until the next reminder fires, Timing reference tells you exactly when.

2. A reminder went out after the link the client kept ​

The client is clicking an old email, but a reminder has since fired and minted a fresh token. The old token is invalidated the moment the reminder mints a new one — there's only ever one valid token per recipient per cycle. So even if the old link is technically less than 48 hours old, it's been superseded.

Check: open the Outbox, filter by the client, and look at all rows for this cycle. If you see the original cycle-request plus a reminder (day-2 / day-5 / day-7) created after the email the client says they kept, the client is clicking the wrong message.

Fix: ask the client to scroll to the most recent email from us — subject lines look like Reminder: Payroll submission due for {month} — and click the link in that one. If they've deleted it, send a fresh one via Request info from client.

3. The cycle moved past intake ​

Once the cycle moves out of INTAKE_IN_PROGRESS — typically after the client clicks Submit or after staff transitions it manually — the intake portal refuses further submissions on the same link. The link technically authenticates the user but the portal shows "This cycle has already been submitted" rather than the upload form.

Check: open the cycle. The status banner reads SUBMITTED, ACTION_REQUIRED, READY_FOR_EXPORT, or later. The submissions tab shows at least one submission row.

Fix: confirm the cycle's actual state. There are two scenarios:

  • The submission is correct and complete — the client doesn't need to do anything. Reassure them; you're already processing.
  • The submission needs more from them — open the cycle, click Request info from client, and list what you need. This sends a fresh email with a working link and the cycle moves into ACTION_REQUIRED (so the portal accepts new uploads against the open ask). See Request info from client.

Still not finding it? ​

If the link is less than 48 hours old, no reminder has fired since, and the cycle is still in REQUESTED or INTAKE_IN_PROGRESS — the link should work. A few things to check before escalating:

  • Have the client try in a private/incognito window. Some browsers cache an old auth state from a previous portal visit, which can show as "link doesn't work" even when the token itself is valid.
  • Confirm the client is clicking the link directly in their email rather than copy-pasting. Some email clients truncate long links when you copy them, dropping the trailing portion of the token.
  • Check the recipient's mail provider isn't a forwarder — some corporate mail systems rewrite outbound links for safe-link scanning, which can break the token. If the email was forwarded, the link is single-recipient by design and won't work in a forwarded copy.

If none of those apply, mint a fresh link via Request info from client and ask the client to click the new one immediately — within minutes, while you're still on the call with them.

For the deeper was the email even sent question, see Verify an email was sent.

Internal use only — BreezyCorp