Fulcrum is a project and permitting management platform built by Odin Research for BFAM Builders. It manages the full lifecycle of QSR exterior remodel projects — from initial permitting through construction completion — and is deployed at:

What Fulcrum replaces

Project types

Fulcrum is a monorepo where each component is named after a Rebel Alliance ship. Each ship has a single responsibility.

Roles & identities

Every signed-in identity is either internal (a BFAM team member, one of the four roles below) or Client (an external contact tied to a client_organization via client_project_access grants — not a role on the users table at all). GET /users/me returns a discriminated shape (kind: "internal" or "client") that every Razor page branches on to decide what to render.

Ticket statuses

Each track's tickets carry one of these, plus an independent Flag — Critical (red), At Risk (amber), or Resolved (green), rendered as a bold outline (the ticket's fill color is its track, not its flag). Resolved auto-clears 14 days after it's set:

Track rollup (dashboards)

A track's progress bar is done tickets / total; its color, in priority order: a Critical flag or any Int Blocked ticket → red ("Critical" — one coarse "needs attention" color on the dashboards; the board and project page show the actual flag/status); else an At Risk flag or any Ext Blocked ticket → amber ("At risk"); else all done → green; else any started → blue; else gray (not started). A Resolved flag never affects this.

Construction is the exception. Its progress comes from the project's schedule Gantt (Construction Updates page), not its tickets: when a project has a schedule with tasks, the bar is complete leaf tasks / total, and the color is green when every task is complete, blue when any task is complete or in progress, red when any task is Blocked. A Critical or At Risk flag on a Construction ticket still outranks the Gantt. The same conclusion is written to the track's own status badge on the project page after every schedule change (logged to the Activity Log as the person who changed the task) — forward only, so a schedule with nothing started yet leaves a manually set status alone. A project with no schedule falls back to the ticket rollup above.

Visibility settings

The gear icon in the header (dashboard, board, project page) opens "What you see" — per track, pick hidden, track only (just its status), or track and tickets (tickets also appear as dashboard sub-rows and board cards). One shared setting (GET/PUT /users/me/track-visibility) — a change on one page applies everywhere on the next load. No row yet for a track = the role default: Permitting sees permit tracks' tickets, Site Supervisor sees Pre-Con/Construction's, Admin/PM see everything; anyone can opt into anything.

BFAM team

Checkers corporate

Kevin Sorensen (sorensenk@checkers.com) and Russell Bernstine (bernstiner@checkers.com) previously had internal viewer accounts against the old /checkers portal. That portal and those accounts are retired — the migration deactivates both rather than auto-converting them, since a real Client identity needs an organization and explicit per-project grants first. A "Checkers Corporate" client_organizations row now exists (Admin → Clients) with per-project grants; add each contact as a client_users row under it once their Azure AD B2B guest invite has been accepted (see "Adding a client contact" below) — Russell hadn't been added there as of this writing.

New project workflow

Adding a client contact

Automated workflows (Phantom)

The main view at / shows all active projects at a glance.

A second, permitting-focused view at /permit-dashboard, reachable from the portfolio dashboard. Where the main dashboard (section 6) rolls every track up into one progress bar, this page breaks a project's Building and Mural tracks out into their own columns, plus the formal permit-workflow state for each — not just task-completion percentage.

The gear icon in the header opens the same What you see settings as the main dashboard, board and project page (Visibility settings): a track you set to hidden drops its column here — Building removes the Building permit column, Mural removes both Mural columns, Construction removes Construction. One setting per user, in effect on every page.

/upcoming (BFAM team only; "Upcoming" in the header) is a timeline of every project with a construction start date, one row each, with the order-by date for each long-lead item counted back from that start in business days (Monday–Friday, skipping company holidays — vendor lead time, not the crew calendar the schedule Gantt uses).

Lead times are set under Admin → Material lead times (the same values that seed a schedule template's material-order milestones).

Where the start date comes from

If the project has a schedule in Fulcrum, its construction start date. Otherwise the start week from the Smartsheet Reimage Schedule, which is loaded with scripts/migrate/49_import_reimage_schedule.py (export the sheet to Excel, run the script — dry run first, then --apply) and re-run whenever the sheet changes. A row tagged "(sheet week)" is using the sheet's Monday rather than a Fulcrum schedule date. Projects on the sheet whose store number isn't in Fulcrum, or whose project is archived, are listed by the script and don't appear on the page.

Marks

Each item has a checkbox and a diamond on the timeline — tick either when the order is placed (it fills in, with who and when in the tooltip). Hover an item for n/a to mark it not needed on that project (no mural, no graphics); it drops off the timeline and out of the overdue/open counts, and shows undo to bring it back. Rere projects only need the Materials order; the other two are marked n/a on every Rere by scripts/migrate/51_mark_rere_nonmaterial_not_required.py (re-run it after adding a Rere).

Read-only access for a graphics installer

A Client organization with Can view Upcoming ticked (Admin → Client organizations) can open the page too, read-only: only their granted projects, only the Graphics application date ("Apply by"), no checkboxes or n/a. Their Dashboard link goes to the Client construction home and a project name opens its Construction Updates page (photos + Gantt). The can_view_upcoming flag is on client_organizations; the API refuses every order write for a Client identity regardless.

Permit status on each row

Under the start line, Building and (when the project has the track) Electrical show the permit's formal status — ProjectTrack.current_status, the same value the permit dashboard shows — green when Approved, yellow otherwise (red if Rejected/Expired). If any shown permit isn't approved, the block gets a yellow border when the construction start is within 30 days and a red border within 14 days; the "Permits open" tile counts those projects. Complete and unscheduled projects never get a border. Not shown on a Client's read-only view.

Sheet-metal BOMs

A project row shows its tracker building type (Short Wings, 2017 Proto, Beaman Round (Mod), …) and, when a BOM workbook exists for that type, a BOM ↗ link that downloads it; Master BOM ↗ in the toolbar is the cross-project workbook with the monthly roll-up. The files live in uploads/bom/ on the server, one per building type, named by key — short_wing.xlsx, proto_2017.xlsx, beaman_round_mod.xlsx, champion_fl_proto.xlsx, short_awning.xlsx, beaman_round.xlsx, low_cost_short_wing.xlsx, champion_mod.xlsx (also .pdf) — plus master.xlsx. Drop a file in and the link appears; a type with no file shows no link. The design-type-to-key map is ghost/bom_storage.py. Internal only: a Client's read-only view never links a BOM.

Views

Timeline (default) is the row-per-project Gantt. Calendar lays the same dates on a month grid — one chip per order-by date (hollow = open, filled = ordered, red = overdue) and an amber chip for each construction start; chips toggle the order the same way the timeline's diamonds do, a start chip opens the project. Map plots every scheduled or in-progress site with coordinates on an OpenStreetMap base (Leaflet, served from /static/assets/vendor/leaflet/): red = in progress or starting within 2 weeks, yellow = within a month, green = more than a month out; a dot's popup has the start, permit lines, order dates and a link to the project. Tiles load from tile.openstreetmap.org, which the nginx Content-Security-Policy's img-src must allow (infra/nginx/fulcrum.conf) — without it the dots still render over a blank background and the page says so. The choice is remembered per browser.

Filters

All is scheduled + in progress — the working set. Scheduled = start date in the future; In progress = started and not complete; Complete = the project, its Construction track, or its whole schedule is complete; Not on the schedule = no start date anywhere; Everything = all of the above. Plus a state filter, search, and "Hide fully ordered". The red line is today; an open item whose order-by date has passed is outlined red and counted in the Orders overdue tile.

Project detail page

Archiving vs deleting

Projects are never hard-deleted. Archive hides them from the dashboard but preserves all data. Toggle "Show archived" to restore. Use the Unarchive button on an archived project to make it active again.

Tracks and their tickets

A track's ticket list is data (ticket_templates, editable in Admin → Templates), not a fixed set — adding, renaming, or reordering a track's tickets never needs a code change. As of 2026-10-08:

Every track has a templates/*.json file (edit in Admin → Templates): the three permit tracks ship with real default checklists for Due Diligence/Contractor Reg/Submittal; Pre-Con, Construction and Financial ship with every ticket's list empty, so a new ticket there starts blank until the template is filled in. The old standalone Plans track is retired; its job is the Building Permit's Plans ticket.

Removing a track

Remove on a track's header (project page, internal only) calls DELETE /project-tracks/{id}: the track and everything under it — tickets and their checklists, track notes, activity-log notes, permit number/dates, jurisdiction COI links — are deleted, with an Activity Log entry recording who did it. Not reversible; the track can be re-added from "+ Add track" but comes back fresh. This is different from hiding a track in "What you see", which is per-viewer and changes nothing on the project. The three always-on tracks (Pre-Con, Construction, Financial) are only attached at project creation, so removing one stays removed.

Ad-hoc tickets

"+ Add ticket" at the bottom of any track's ticket list (project page) adds a one-off ticket to that project's track only — it has its own name and does not change the track's template or appear on any other project. Ad-hoc tickets behave exactly like standard ones otherwise (status, flag, owner, due date, notes/checklist, board card, dashboard sub-row) and sort after the standard set. They're the only tickets that can be renamed or deleted — both from the drawer's header. A standard ticket is named by its template and goes away with its track.

The 4 design options (tried in order, stopping at the first approved) live as checklist lines inside the Mural track's Submittal ticket, pre-filled on a new track: Mural both sides → Mural one side → Chevron painted → Parallelogram painted. Check one off once it's approved; if the AHJ rejects an option instead, use the ticket's rich-text editor to strike it through and add a note, then move to the next line.

The board at /board.html shows one card per ticket across every project you've chosen to see tickets for ("What you see", gear icon), in five columns: To Do, In Progress, Int Blocked, Ext Blocked, Done. Each card fills with its track's pastel color; a flag (Critical/At Risk/Resolved) adds a bold outline on top.

• Filter by person, project type (Rere/Remodel), project (type to search), or ticket (a dynamic list of every ticket name currently visible to you)
• "Flagged only" toggle — a flagged ticket always shows its outline, in whichever column its status puts it
• Click a card to open the ticket drawer right there on the board (with an "Open project →" link), or drag it to a different column to change its status
• Overdue tickets show their due date in red

The quoting tool at /quote.html replaces the manual process of reformatting IAM quotes into BFAM format.

Creating a quote

Saved quotes appear in the Quotes panel on the /updates Construction Updates page for the project. Click any saved quote to reopen and edit it.

Fulcrum has no separate client login. External contacts (a franchisee's ops team, a corporate contact like Checkers) are invited as Azure AD B2B guests into the same tenant BFAM already uses — they sign in with their own company email, same Microsoft sign-in flow as everyone else. A guest is only ever a Client identity: it belongs to a client_organizations row, and can only see the specific projects that organization has been granted via client_project_access — no organization-wide or portfolio-wide view.

What a Client sees

What a Client never sees

• Tickets, the ticket drawer, or /board.html — ghost/routers/tickets.py is internal-only end to end
• The project detail page — landing on /project.html?id=X redirects straight to that project's Photos + Gantt instead
• Activity Log, AHJ & Contacts, Documents, Daily logs, Quotes, Contractors — all construction-personnel-only now, on any page
• Portal credentials, any other organization's data, or any edit/create control

Admin page at /admin — accessible to Admin role only.

Users section

Last seen is stamped on every authenticated request, at most once per five minutes (sentinel/last_seen.py), for internal users and client users alike — "Never" means the account has not signed in since the column was added on 2026-10-27. It answers "has this person been in Fulcrum lately?", not what they looked at.

• Lists all users with name, email, role, and status
• Change role via dropdown — saves immediately
• Deactivate blocks login without deleting data
• Delete permanently removes the user and their allowlist entry
• Add user form creates DB record and adds to allowlist
• You cannot deactivate or delete yourself

Sites section

Click any field to edit inline — address, jurisdiction, portal URL, portal username. Changes save on Enter or blur.

Templates section

View the JSON task templates that define permitting checklists. Read-only in the UI. To modify templates, edit the JSON files in templates/ on the server.

Adding portal passwords to Key Vault

Infrastructure

Deploy an update

Useful commands on the VM

Environment variables

All config lives in ~/fulcrum/.env on the Azure VM. Never commit this file. Key variables:

Repository

github.com/tedbp19/fulcrum — private. Main branch is production.

Local development

API reference (Swagger / ReDoc)

With APP_ENV=development, Ghost serves an interactive OpenAPI reference at /api/docs (Swagger UI) and /api/redoc (ReDoc), plus the raw schema at /openapi.json. All three are disabled in production (docs_url/redoc_url/openapi_url are None unless _IS_DEV) — an unauthenticated scanner found the schema wide open at one point and used it to enumerate every real endpoint. Run Ghost locally to browse the API; it isn't reachable on the production URL.

Database migrations

Adding a permit template

Drop a new JSON file in templates/ following the existing format — its checklist object is keyed by the track's own ticket keys (due_diligence/contractor_reg/submittal/plans; see Admin → Track Templates for a track's exact ticket list) and becomes the default checklist seeded into new tickets of that kind. Easiest done through Admin → Templates' editor rather than hand-editing the file. Existing tracks aren't affected automatically; use the ticket drawer's "Load checklist from template" link, or POST /project-tracks/{id}/seed-tickets, on a track whose ticket notes are still blank.

Adding or renaming a track's tickets

Admin → Track Templates — each card lists that track's tickets under "Tickets"; rename one inline, delete one (refused while any track_tickets row still references it), or add one (seeds a blank todo ticket onto every project that already has this track, not just future ones). The card's color swatch sets the pastel fill every ticket of this track gets on the board and project page.

GitHub repository structure