# Review what a meeting changes in your table before the change lands

> For anyone who lets meetings fill a table and does not want it changed unsupervised: how the TrackHeros review queue works after a Google Meet or Microsoft Teams call, what accepting, correcting and rejecting do, when confident values may apply on their own, the four kinds of change that always wait for a person, and why a rejected value stays rejected.

Canonical: https://trackheros.com/blog/review-before-a-value-changes/  
Author: Sami Kanafani  
Updated: 2026-11-04

**In short:** By default TrackHeros puts every new or changed tracker value from a Google Meet or Microsoft Teams meeting in a review queue, grouped by meeting, to accept, correct, reject or accept all. A tracker can instead apply confident values on its own, but removals, conflicts with a kept first value, changes to hand-edited cells and possible duplicates always wait. A rejected value does not come back from the same meeting.

| Fact | Detail |
| --- | --- |
| Default | Every new or changed value waits for review |
| Review actions | Accept, edit then accept, reject, or accept all from one meeting |
| Optional | Confident values apply on their own; anything applied can be undone |
| Always waits | Removals, first-value conflicts, changes to hand-edited cells, possible duplicates |
| Rejected values | Do not come back when the same meeting is read again |

A table filled by an AI is only useful if you can trust what is in it, and the simplest way to keep that trust is to see each change before it lands. This guide is for freelancers, consultants and anyone else who lets their Google Meet and Microsoft Teams meetings fill a [TrackHeros tracker](/features/trackers/) and wants a say over every value. It covers the review queue, what each action does, when to let confident values apply on their own, and the changes that always wait for a person whatever you choose.

## Why review a value before it changes?

Because a wrong value in a table looks exactly as authoritative as a right one. Nobody reading the table later can tell that a deadline was misheard or a salary belonged to another candidate, so the place to catch it is before it becomes the current value.

TrackHeros is an AI meeting notetaker that connects every Google and Microsoft calendar you hold, recognises close to 100 spoken languages on its own, writes the notes in nine of them, and keeps every client's notes in a sealed workspace of its own. Its trackers are tables that fill themselves after each meeting's notes are ready, and every value is cited: the model has to point to the transcript lines it came from, a value with no line behind it is dropped, and the quote shown is rebuilt from the stored transcript rather than written by the model. Citation makes a value checkable. Review is where you check it.

## What waits in the review queue?

Every new and changed value from a meeting, grouped by that meeting. Each change shows the column and the value it would set, with the words it came from and a link to that moment in the transcript, plus a short reason when it is waiting for something more than routine review.

In the default mode new rows wait too, marked as new until you accept them. The tracker's creator gets an in-app alert when changes are waiting, the tracker's page has a review tab, and the table can be filtered to rows waiting for review. Each meeting's page has a **What changed** panel listing what that meeting gave each tracker, so you can review from either side. Why a particular value is waiting is answered in [why is a tracker value waiting for review?](/answers/why-is-a-tracker-value-waiting-for-review/)

## What can you do with each change?

Accept it, correct it and accept the correction, or reject it. When a meeting's changes all look right, accept them in one go.

| Action            | What happens                                                        |
| ----------------- | ------------------------------------------------------------------- |
| Accept            | The value goes into the table, with its quote in the cell's history |
| Edit, then accept | Your corrected value goes in, recorded as a person's correction     |
| Reject            | The value stays out and does not return when the meeting is re-read |
| Accept all        | Every routine change from that one meeting goes in at once          |

A possible duplicate row asks a different question: is "the auth endpoint" the same as the existing "Login API", or a new row? You answer **same as** or **new row**. A value that contradicts a column set to keep its first value asks you to choose between the first value and the new one. Both are decisions rather than a yes, so accepting all from a meeting leaves them for you to make one at a time.

## When can a tracker apply values on its own?

When you switch it on. A tracker can apply confident values automatically instead of queueing them, and anything it applies can be undone from the cell's history.

It suits tables where a wrong value is cheap and the columns are well described: a standup log, say, after a few weeks of reviews that needed no corrections. Leave it off for interview scorecards, trackers that hold money, and anything a client will see, at least until the column descriptions have proved themselves. A value the tracker is not confident about still waits, and so do the four kinds of change below. [Designing the columns of a meeting tracker](/blog/design-the-columns-of-a-meeting-tracker/) covers the descriptions that make confident values more common.

## What always waits for a person?

Four kinds of change, even on a tracker that applies confident values on its own. Each is a change that is easy to get wrong and expensive to miss.

1. **Removing an item from a list.** A blocker, a concern or a pain point is removed when someone says it is resolved. "IT are looking at the staging access" can sound resolved when it is not, and a blocker that silently disappears is worse than one that lingers.
2. **A value that contradicts a "keep the first value" column.** A column such as the date a change was first requested exists to hold the first answer. A later, different value is shown as a conflict, and only you decide whether it replaces the first.
3. **A change to a cell somebody edited by hand.** A hand-edited cell is protected. If a meeting later says something different, the change waits rather than overwriting what a person typed.
4. **A possible duplicate row.** When a new row looks like an existing one, it is flagged as a possible match. Rows are never merged automatically, because a wrong merge mixes two histories and nobody notices; answering same as keeps the new row's history under the existing row.

## Do rejected values come back?

No. A rejected value does not come back when the same meeting is read again, and neither does a change you undid. The decision is kept for that value from that meeting, so it survives the meeting being re-read.

That matters because meetings do get read more than once: a re-read you start yourself, or reading recent past meetings when a tracker is created. Without sticky rejections you would reject the same wrong reading every time. A later meeting is different: if someone says the value again next week, that is new evidence, and it is proposed again with its own quote. The exception is a new row you rejected by its name: that tells TrackHeros the thing is not a row, so later meetings that name it do not propose it again. [Undo a tracker change](/answers/undo-a-tracker-change/) covers taking back a change that was already applied.

## What happens to a value from an older meeting?

It goes into the history, not the table. An older meeting never overwrites a newer value: if last week's call is read after this week's, its value is labelled as older and the table keeps the newer one.

Accepting such a value from the queue records it in the history and leaves the current value alone. If you want the older value back in the table, restore it from the cell's history, which records that a person chose it. Each step stays visible, as described in [a history of every change, with the quote](/blog/a-history-of-every-change-with-the-quote/).

## How do you keep the review queue short?

Write precise column descriptions, preview before saving, and keep some columns for yourself. A precisely described column gives you fewer values to reject.

- **Describe each column with what belongs in it and what does not.** "The date the item is due, when a date is stated. Not estimates given as durations" gives fewer wrong dates than "Deadline".
- **Preview the definition on one recent meeting** before saving it, to see what it would record.
- **Mark columns you own as fill by hand only**, so meetings never write them.
- **Review straight after the meeting**, while you remember what was said. A meeting held in French or in Arabic reaches the queue after its audio pass, from the same transcript as its notes; the spoken languages TrackHeros recognises are on [languages](/languages/).

## Frequently asked

**Who is told when changes are waiting?**

The person who created the tracker gets an in-app alert when changes are waiting for review. The tracker's page also has a review tab and a filter for rows waiting for review.

**Can people I share a tracker with review it?**

Yes. People a tracker is shared with can review changes and edit cells. Changing the columns or the scope, archiving or deleting the tracker, and starting a re-read stay with its creator or an admin.

**If I reject a value, will a later meeting propose it again?**

A rejected value does not come back when the same meeting is read again. A later meeting that says it again is new evidence, and it is proposed again with its own quote, so you can decide afresh. Rejecting the name of a new row is different: later meetings do not propose that row again.

---

TrackHeros is in early access: https://trackheros.com/#early-access