Projects become hard to reconstruct when approvals, scope changes and decisions are all stored as the same kind of note.
They are related, but they do different jobs. A scope change records what moved beyond the original agreement. An approval records what the client accepted. A decision log records the choice and the reasoning that shaped the work.
Keep three questions separate
- What changed? Use the change record.
- What was accepted? Use the approval record.
- What was decided and why? Use the decision record.
Separating those questions makes each record easier to scan and prevents one giant project log from becoming a dumping ground.
Connect records only when the relationship matters
A client request that changes scope can point to the approval that authorised it. The approval can point to the exact version or scope it covered. A project decision can point to the work, change or approval that followed.
The connection is useful because it preserves context without duplicating the same information in several places.
A worked example: one request, three records
Imagine a fictional website project. The agreed scope covers five pages. The client asks for two additional landing pages and chooses a shorter layout so the launch can stay on schedule.
| Record | What to capture | Connection |
|---|---|---|
| Change CH-014 | Two additional landing pages; proposed fee and delivery impact; Pending approval. | Project and approval AP-008. |
| Approval AP-008 | Who approved the revised scope, when, which version and where the confirmation is stored. | Change CH-014 and the approved scope version. |
| Decision DE-006 | Use the shorter layout to preserve the launch date; record the reason and alternatives considered. | Project, change CH-014 and the resulting design task. |
Keep the change pending until the proposed scope, fee and timing have been explicitly accepted. Then create the delivery tasks. A task called “Build landing pages” is easier to understand when it points back to CH-014 and AP-008.
Start with links before adding more databases
Three sections in one project page can work for a small project. Give each record a short identifier and link to the relevant page or confirmation. If records need separate owners, statuses or filtered queues, move them into databases and use relations to connect them.
For the implementation, see how to connect two databases in Notion. For the individual records, use the guides to what to record in a client project change, documenting client approval and keeping a client decision log.
Do not turn every message into a record
Normal discussion can stay in normal communication. Create a structured record when the information changes scope, closes uncertainty, commits money or time, or becomes something the project may need to prove later.
Let actions come after the record
Once the change, approval or decision is clear, create the task or next action that follows. The task tells the team what to do. The record explains why that work exists and what authorised it.
Keep the cockpit smaller than the engine
The underlying project history can contain many connected records. The working view should still show only what needs attention: open changes, pending approvals, unresolved decisions and the next actions they create.
The rule worth keeping
Do not combine different records merely because they happened in the same conversation.
Keep each record responsible for one question, connect it to the records that give it context, and let the project history become clearer without making the daily cockpit heavier.