Legislative Report Router — Tutorials
These are for the coordinator — the person who receives the bill report
and gets it in front of the divisions. If you're a division reviewer who got tagged in
Teams, you want the two-minute reviewer guide instead.
Tutorial 1 — A practice run that can't touch anything
Do this first. It exercises reading, parsing and preview without any setup and without
the ability to post anywhere, so you can get familiar before anything is at stake.
Step 1 — Make yourself a practice report
Compose a new email in Outlook — don't send it — and paste this into the
body, each item on its own line:
HF935
MVD
MVD
medical personnel authorized to withdraw a specimen of blood
Successor to HSB171, as amended.
Step 2 — Read it
Open Report Router from the ribbon. On the Overview tab, click
Read this report.
First run only: a standard Microsoft sign-in appears. Sign in as the
mailbox you're in. Every permission is delegated — the add-in can only ever reach
what you can already reach yourself.
Step 3 — Check the parse
You should see, on the Review tab: one bill — HF935,
division MVD, with an editable brief — flagged unmatched.
Both of those are correct, and each is worth understanding:
- Unmatched is right, because you haven't connected a routing list yet. There's
nowhere to send it, and the add-in says so rather than guessing.
- HSB171 did not become a second bill. It's mentioned in the last line as history,
not filed as its own item. Parsing is line-aware for exactly this reason — a
successor-bill reference is the single most common way a naive parser invents a bill
that doesn't exist.
Step 4 — Look at what would go out
Open the Preview tab.
This renders the Teams post that would be sent — the bill number, the brief, the
deadline, the tag mention. Nothing has been sent.
Publish is blocked on purpose until two separate things are true:
a routing list is connected in Setup, and you tick an explicit confirmation box.
Neither alone is enough. Nothing can post or email until both are.
Tutorial 2 — A real report day, start to finish
This assumes Setup is done — the six-step wizard under ⚙️ Setup (one-time, guided),
ending with 6 · Prove it all works and its Run all checks button. If the pane
doesn't say routing is connected, finish that first; the admin guide has the list schemas.
Step 1 — Read the day's report
Open the report email, then Read this report on Overview.
You should see the Review tab fill with one entry per bill, each with
a division and a plain-language brief.
Step 2 — Fix what it got wrong
This is the step that matters, and it's the one people skip. Everything on the Review
tab is editable — the brief, the division, the severity. The parser is deterministic
and rule-based, not an AI guessing at intent, which means it's predictable but also means
it only knows what the report literally said.
Anything flagged unmatched needs a division. Select the bills and use
Assign to set one in bulk.
Leave a bill unmatched and it doesn't get routed. That's deliberate —
silently guessing a division would put a bill in front of the wrong people and, worse,
not in front of the right ones. But it does mean an unmatched bill is your job to
resolve before you publish.
Step 3 — Pulling in bills from the feed
Optional: on New bills, click Check for new bills, tick the
ones you want, and click Add selected bills to today's report →.
Step 4 — Preview, properly
Open Preview and read at least a couple of the posts as though you
were the person receiving them.
Check the deadline in particular. Comments are due 48 business hours out,
snapped to 5:00 PM — weekends and your agency's holidays skipped, and the snap never
shortens the window. It appears right in the subject line so a reviewer sees it without
opening anything.
Step 5 — Publish
Open Publish, tick the confirmation box, and click Publish.
What happens: one Teams post per bill, in the right channel, tagging
the right division. An audit row is written for each, and tracker rows are created so
divisions can mark themselves done.
If any post failed — a channel permission, a transient Teams error — use
Retry failed only. It won't re-post the ones that already went.
Step 6 — The daily report email
The consolidated report is drafted and left in your Drafts. You read it and press
Send. As with everything else here, the add-in writes; you send.
Tutorial 3 — Getting the costs back out
Divisions reply in the Teams threads with cost estimates and severity. The whole point of
this tutorial is that you never retype any of it.
Step 1 — Harvest
Open 📜 Publish history and click Harvest from Teams replies.
This reads replies to the add-in's own bill posts, in channels you already belong to,
and pulls out the money and severity. It reads Word and Excel attachments too, because
divisions routinely put the numbers in a spreadsheet rather than in the message.
A figure from an attached costing sheet outranks one mentioned in
passing in prose. If someone writes "we thought it might be $10k" and attaches a workbook
saying $42,000, the workbook wins — that's the considered number.
Step 2 — Check before you accept
Review what it found, tick the ones that are right, and click
Apply checked to tracker.
Nothing is recorded until you tick it. Harvesting is a proposal, not a decision — a
sentence like "this won't cost anything like the $2 million in the other bill" contains a
number that means the opposite of what a machine would take it for.
"TBD" is preserved as "estimate pending", never as zero. A division
that hasn't costed something yet must not silently read as a free change.
Step 3 — The running total
Under 💰 Fiscal impact, click Load fiscal rollup for running
totals per fiscal year, then Export CSV if you want it in a budget workbook.
This is the number that supports a budget request: what this session's bills would cost,
by fiscal year, attributed to the divisions that said so, with the audit trail behind it.
What this add-in will never do on its own
It does not post, email, or record anything without an explicit click from
you — publishing needs a confirmation checkbox, the daily report is left as a draft, and
harvested costs need ticking. There is no publisher server: it is static files running in
your Outlook, talking to Microsoft Graph as you. Parsing is deterministic client-side
logic — no AI, no external service, no telemetry — and every record it writes goes into
your organisation's own SharePoint lists.