Merge a meeting's outcomes into a project

A meeting produces three things: work, a record of what was decided, and whatever was built in the room. Merging is the step that moves the first two into the project, so the conversation stops being a transcript and becomes the project’s state.

This page follows the Summitline kickoff into Summitline Launch.

Merge it

1. Open the meeting and review its drafts. Accept the ones that are real work, reject the rest.

2. In the meeting’s panel, open Merge to Project. Before the merge it stages what you accepted: the counts, each draft with an Execute or Backlog toggle, and the merge action itself.

3. Merge N Tasks to Project.

What lands where

What the meeting had	Where it goes
Accepted task drafts	Tasks in the project, each with a short key in the project’s sequence
Decisions, requirements, scope, risks, open questions	Project Data, tagged with the meeting they came from
Dependencies between drafts	Kept, so a task that waits on another still does
Artifacts (diagrams, decks, captured pages)	Stay on the meeting, and are reachable from it forever

Artifacts are the one thing that does not move. A deck belongs to the conversation that produced it, and the meeting stays linked from every task and from the project’s Meetings tab, so nothing is stranded.

Check that it landed

The merge panel reports what it did; the project is where you confirm it. Open the project and check three places, in this order:

1. Tasks. The new work, numbered in the project’s sequence. This is the merge from the other side.

   

   Each task carries its priority and whether it shipped ready or to the backlog, and each links back to the meeting it came from.

2. Project Data. The decisions, requirements, and scope items the meeting recorded, each tagged with that meeting. A conversation that produced work without recording any explicit decisions leaves this tab where it was, which is not a failed merge: nothing was dismissed, there was simply nothing of that kind to promote.

3. Overview. The counters are the same numbers as the two tabs above, and each is a link into the tab behind it.

Merging twice

A merge is applied once. Re-opening the panel afterwards reports what the meeting produced rather than offering to do it again: how many drafts became tasks, how many were rejected, and View Project Tasks to open the work where it now lives.

Dismissing an item during the merge drops it from that promotion. It is not deleted from the meeting, so the conversation still records it.

Nothing merges without a project

A meeting has to belong to a project before it can be merged, because the merge needs somewhere to put the work. Set the project when you start the meeting, or start it from the project’s + New Meeting so it is scoped from the beginning.

Next steps

• Review the tasks a meeting proposes: the accept-and-ship step before this one.
• Set the project’s intent: what the merged decisions become.
• Read the Flow board: the merged work as a tracked initiative.