Understanding transactions and merging.

Every Submit in Symphony becomes a transaction — a bundled record of what changed, when, who did it, and why. Transactions are the foundation of Symphony's history and merging model. Here's how they work.

What a transaction is

A transaction captures a coherent set of changes made by one person, submitted as a single unit. When you edit five cells across two rows and click Submit, all five cell changes are grouped into one transaction. They travel together, they're timestamped together, and they carry the same reason.

Each transaction records:

• What changed — the exact cells, rows, or columns that were modified, with old and new values.
• When it happened — the moment of the Submit, precise to the second.
• Who did it — the identity of the contributor who made the change.
• Why they did it — the reason text they attached at Submit time.

These four dimensions — what, when, who, why — turn a spreadsheet from a snapshot into a story. Six weeks after a deal moves from committed to best-case, you can still see who moved it, when, and what their reasoning was.

The transaction chain

Transactions form a chain, ordered chronologically. Every worksheet has a chain. Every row has a chain within that worksheet. Every cell has a chain within that row.

You can walk the chain at any level:

• Click Changes on a cell to see just that cell's chain.
• Click Changes on a row to see every transaction that touched any cell in that row.
• Click Changes with no selection to see every transaction on the whole worksheet.

The chain is immutable. You can't rewrite history. If you want to undo a change, you Submit a new transaction that reverses it — and the reversal itself becomes part of the chain, with its own reason.

How merging works

Because Symphony lets multiple people work privately at the same time, there needs to be a rule for what happens when two people change different things — or, occasionally, the same thing.

The rule is straightforward: changes to different cells are merged automatically. If you update column D and a teammate updates column F, both changes flow through when either of you Submits. Nothing to resolve.

When two people change the same cell before either Refreshes, that's a conflict. Symphony detects it at Refresh time and surfaces the conflict to you: "You changed this cell to $50,000. Your teammate changed it to $65,000 at 3:47pm. Which value should win?" You choose. Your choice becomes a new transaction with a reason attached.

In practice, conflicts are rare — because most teams naturally divide ownership so different people work on different rows or worksheets. But when conflicts do happen, they're visible and traceable rather than silent overwrites.

Reasons matter

Every transaction can carry a reason. Symphony strongly encourages you to add one at Submit time. It's a short sentence — no formal structure, no required fields — but it changes everything about how the chain reads six weeks later.

Without reasons, the chain tells you what changed and who and when. With reasons, it also tells you why. That last dimension is what turns a diff into a story.

Some teams make reasons mandatory. Some make them optional. Either way, treating reasons as first-class is what separates Symphony from any version-history system.

Diffs between two moments

Because every transaction is timestamped, you can compare any two points in time — this week vs. last week, this quarter's opening vs. this quarter's close, the last board meeting vs. today. Symphony shows you exactly which values moved, by how much, and — critically — the transaction chain that got you from one state to the other.

This is a common pattern for weekly forecast reviews, quarterly business reviews, and month-end reconciliation. The diff isn't just a set of changed numbers; it's a set of changed numbers with reasoning attached.

What this enables

The transaction model is why Symphony can offer things that a file-based system can't:

• A full audit trail without asking anyone to fill in a change log.
• Confidence that no changes are silently overwritten.
• The ability to reconstruct any past state of any cell.
• Meaningful history — states worth reviewing, not every keystroke.

Understand transactions and you understand the mechanism behind everything else Symphony does.