Tag San Francisco and Toronto Hub Rows Separately

Some Ashby boards print two hubs on one title line. Firecrawl's early November 2026 list showed multiple engineering seats as San Francisco HQ and Toronto Hub with Hybrid work mode, while other seats were San Francisco OnSite only. If your CRM stores only "Firecrawl / SF," you will pitch the wrong people and burn the wrong network. This playbook is the five-step checklist for dual-hub rows.

Worked example: Firecrawl Ashby board, accessed November 2026.

Step one: copy the location string exactly

If Ashby prints "San Francisco HQ; Toronto Hub," paste that full string. Do not normalize to San Francisco. Do not invent "remote Canada" unless the board says so.

Step two: split coverage by hub capability

Ask whether your desk can work Toronto hybrid, San Francisco on-site, or both. If only SF on-site, hide Toronto-tagged hybrid engineering and keep SF on-site Success Engineer or Sales Engineer rows. If you place Canada hybrid, keep the dual-hub engineering lines and drop SF-only on-site GTM you cannot fill.

Step three: keep work mode glued to the hubs

Hybrid on a dual-hub line is not the same as US Remote. OnSite San Francisco is not permission to source Toronto. Store mode next to the hub string as one audited field.

Step four: watch internal recruiting seats per hub

In-House Technical Recruiter in San Francisco is a process signal for that hub. It does not freeze Toronto engineering automatically. Log it, then ask about overflow by function and location.

Step five: re-check before second touch

Dual-hub companies edit boards unevenly. A Toronto hybrid seat can close while an SF on-site BDR opens. Re-open Ashby the morning of follow-up. Update the tagged string. Do not reuse last week's hub assumptions.

One employer with two hubs is two research problems that share a brand name.

We noticed in the Firecrawl walkthrough that several product and infrastructure titles shared the SF/Toronto hybrid pattern while implementation and some GTM titles stayed SF on-site. Saying "they're hiring engineers in San Francisco" was incomplete enough to look sloppy to anyone who opened Ashby.

Constraints

This checklist does not create agency authority. A tagged title is still not a job order. It fails when the board prints only "United States" with no city. Prefer the employer ATS URL over aggregator cards that strip the second hub.

Partner handoff language

Lead with tagged strings and access date. Say coverage this week is SF on-site GTM, with Toronto hybrid engineering parked, or the reverse. Partners can disagree with coverage. They should not reverse-engineer which hub you meant.

End every dual-hub research block with a one-line coverage decision before the email draft. Ambiguous coverage is how Toronto resumes get sent at SF on-site Success Engineer roles. Write the decision first.

Training a junior researcher

Require two dual-hub tagged strings before any congratulations email on funding. If they only produce "Firecrawl raised seventy-five million in San Francisco," they are not done. This rule prevents the single-HQ smear that wastes senior time on cleanup.

CRM hygiene

Use a hubs field that accepts multiple values, not a single city picklist that forces San Francisco. When the board prints both hubs, both values must survive import. Report dashboards that count open roles by city must not drop Toronto because the picklist was US-only.

When a hiring manager says "we hire in SF and Toronto," still refuse to store a blank mode. Ask which titles are hybrid versus on-site this month. Store the answer as new tagged strings. Everywhere is a brand claim. Tagged titles are research.

Do not let funding headlines rewrite your hub list. Until Ashby shows the title and hubs, keep later seats out of the active shortlist.

Refusal lines that keep hubs honest

To a candidate: "This Firecrawl engineering seat lists San Francisco HQ and Toronto Hub with Hybrid. If you need pure Toronto local with no SF expectation, I need that constraint in writing before I submit." To a partner: "Coverage this week is SF on-site GTM only; Toronto hybrid engineering is parked." To yourself: if you cannot name both hubs on a dual-hub line, you have not finished research.

Print the five steps for the research folder. Every new dual-hub board gets the same page. Speed comes from repetition. SF plus Toronto is only today's example. The next board may print London and Bangalore. The tagging rule stays.

End every dual-hub research block with a typed coverage decision before any email leaves drafts. Ambiguous coverage is how Toronto resumes hit SF on-site roles while everyone cites the raise. Write which hubs you will work and which you will ignore. Dual-hub lines that you cannot staff should sit in the ignore column for shortlist purposes even when they stay in the watch column for market context.

If compensation appears on one SF on-site posting, do not paste it onto a Toronto hybrid twin. Bands travel with the exact titled row or they do not travel.