Turn meeting notes into tasks: owners, dates and review

Turn agreed work into tasks, not every sentence

A meeting summary and a task list solve different problems. The summary explains the discussion. A task needs a clear action, an owner and enough context to finish it. Start with the second problem if decisions keep disappearing after calls.

A useful first workflow takes approved notes, suggests tasks, lets the meeting owner check them, then creates the agreed items in a project tool. Keep the source sentence with each suggestion. That gives the reviewer a quick way to catch a guessed deadline or a promise nobody made.

1. CollectRead notes from one agreed folder or meeting app.
2. ExtractSuggest the action, owner, date and supporting sentence.
3. ReviewResolve missing details and approve a fixed version.
4. CreateWrite each approved action once and save its task ID.
5. CheckCompare approved actions with created tasks and investigate gaps.

Use an existing meeting tool's approved action list when it already does the extraction well. You may only need the handoff to the project tool. Another AI call adds cost and another possible source of mistakes.

A practical Zapier and Asana setup

Prepare a test project, an authorized notes source and a small owner directory before connecting steps. The directory maps a known person to their actual Asana user ID. A display name alone is a poor key when two people share it. Only process notes you are allowed to share with the selected tools.

1. Trigger from finalized notes or a clearly marked ready record. Keep the meeting ID and source version. Do not process every autosave.
2. If extraction is needed, add AI by Zapier with named output fields for action text, owner reference, date text and source excerpt. Its current editor supports output fields and a list of results. Leave action tools out of this extraction step. Check the current AI output settings.
3. Save suggestions to a review record. Check required values and the owner directory before task creation. Unknown people, ambiguous dates and incomplete notes stay in review.
4. Have the meeting owner approve the exact list. If using Zapier Human in the Loop, put it before Looping. Stop on decline or timeout and continue only on an approved result. Reviewers need the right account and Zap access; Pro permits requests to yourself. Check reviewer and plan requirements.
5. Use Create Loop From Line Items for the approved rows. Map each row's fields from the loop output, not the combined test preview. See the loop setup.
6. Use Asana Create Task in the fixed test project. Map the reviewed title, resolved assignee, date and source reference. Save the returned task ID against the review item. Check Asana actions and prerequisites.

This is a build plan, not an importable Zap. The review record, owner lookup and duplicate protection need to be configured in your chosen store. Test app fields with your account before using live meeting notes.

Example 1: One clear action becomes one task

Input: The notes for meeting MTG-204 say: “Mira will send the revised onboarding checklist by October 2, 2026.” The meeting owner confirms Mira's directory entry and the project.

{"meeting_id":"MTG-204","source_version":1,"item_key":"MTG-204:A1","title":"Send revised onboarding checklist","owner_ref":"mira","due_date":"2026-10-02","review_state":"pending"}

Set it up: Show that sentence beside the proposed task. Resolve mira through the approved directory, then let the reviewer mark this version ready. The writer stores the returned Asana task ID beside MTG-204:A1. Keep the project selection fixed by the workflow, not taken from arbitrary meeting text.

Expected result: One task, one assignee, a date of October 2 and a reference back to the source. Do not mark it complete just because the task was created. Creating the work and finishing it are different events.

Failure check: Remove Mira from the test directory. The item should remain unassigned in review rather than landing with the workflow owner by default. Restore the mapping and retry the same item.

Example 2: A missing owner or date stays visible

Input: “Someone should check the old customer list next week.” There is an action idea, but no agreed person or clear day.

{"title":"Check the old customer list","owner_ref":null,"due_date":null,"source_excerpt":"Someone should check the old customer list next week.","review_state":"needs_details"}

Set it up: Preserve the original wording. Ask the meeting owner to confirm whether this is agreed work, choose an authorized person and decide whether a deadline is needed. Your policy can allow tasks without a date, but that must be a deliberate choice. Do not invent Friday just to fill a field.

Expected result: No assigned task until the owner is resolved. If the team decides the idea is only a suggestion, record that decision and skip task creation.

Failure check: Try two people with the same first name. Require the directory ID or verified work address to distinguish them. A successful name match is not enough to establish which person accepted the work.

Example 3: Keep a date-only deadline on the same day

Input: An approved action is due on 2026-10-02. The team means that calendar day, with no agreed time.

Set it up: Map it to the destination's date-only field. Asana distinguishes due_on, a calendar date, from due_at, a UTC date and time. It says not to use both together. See Asana task date fields.

{"title":"Check the revised checklist","due_on":"2026-10-02"}

This object illustrates the intended field mapping. It is not a complete API request. If your connector exposes one Due Date input, test its handling of a date-only string in the actual account.

Expected result: The task remains due October 2 when viewed by the relevant team members. If the source says “Friday at 3 p.m.,” capture the intended time zone and use a timed deadline instead.

Failure check: Inspect the task from two relevant time zones. Do not turn a date into midnight UTC unless the business rule really means that instant. Keep source text when “next Friday” needs clarification.

Example 4: The same notes arrive twice

Input: The same meeting export is delivered twice. Both deliveries contain the approved action MTG-204:A1.

Set it up: Assign a stable item key in the review system and reuse it on retries. Store its source meeting, approved version and destination task ID. If the meeting tool supplies stable action IDs, retain them. If it does not, give each reviewed item an ID once; do not ask AI to invent a new ID on every run.

Expected result: The second delivery finds the completed write and keeps the existing task. Two separate actions with the same title must still be allowed. Deduplicating on title alone would lose legitimate work.

Failure check: Deliver the same event twice at nearly the same time. A search followed by create can race. Use a unique key and an atomic claim in the record store, or serialize the writer and test its queue limits. A plain spreadsheet lookup does not guarantee that only one run will create a task.

If task creation times out, first check whether Asana received it. Recover the known task ID or send the uncertain item to review before issuing another create. The duplicate-record guide explains this failure in more detail.

Example 5: The notes change after approval

Input: Version 1 assigns the checklist to Mira. Version 2 says that Leo will take it instead. The first version already created a task.

Set it up: Mark version 2 as requiring review. Show the old and new owner side by side, with the source sentences. Keep the original task ID. A reviewer chooses whether to update that task, leave it unchanged or cancel the proposal. Do not delete completed work as part of a blanket resync.

Expected result: One reviewed update to the existing task after the changed assignment is confirmed. An approval for version 1 does not authorize version 2.

Failure check: Approve version 1 while version 2 is arriving. Before writing, compare the approved source version with the current one. A mismatch must return to review. Use a conditional write or serialized review queue so an edit cannot slip between the version check and the update.

Make it clear which system owns later changes. Once the team starts editing the Asana task, replaying old meeting notes should not silently restore the original due date.

Example 6: Four actions are approved, but only three are created

Input: A reviewed list contains four independent actions. Three writes succeed and one fails because its project access changed.

Set it up: Track the write result per item. Calculate completion from confirmed task IDs, not from the last loop number. Zapier loop iterations run in parallel; the numbered last iteration can finish before another one. Check the loop behavior and limits.

Expected result: The review record says three of four created, with A3 still open. After the authorized owner resolves the access issue, retry A3 only. No new copies of A1, A2 or A4 should appear.

Failure check: Run the retry twice. The item key must still protect the destination. Send a completion summary only after a separate reconciliation step confirms every approved item has a known result.

Measure missed work and review effort

Before the pilot, count how many actions from a small sample of meetings never reached the task list. After the pilot, measure how many suggestions needed a factual correction, how long review took and how many approved items failed to create. Keep those measures separate from task completion.

For a made-up batch of 20 suggestions, suppose a reviewer accepts 14, edits four and rejects two. That is 18 approved items to reconcile with destination tasks. It is not 20 successful automations, and it says nothing about whether the team finished those 18 tasks.

Give the owner a short handover: the source folder or app, allowed meeting types, owner directory, review location, task project, duplicate key, failed-item queue and restart instructions. Include who checks the queue when the usual owner is away.

Keep a small repeatable test set: clear action, missing owner, missing date, no action, duplicate delivery, changed notes and one failed write. Check the source and destination together. A green automation run is useful, but the actual task list is the result people rely on.

If your main problem is incoming requests rather than meetings, start with client onboarding or support ticket routing. If you are deciding how much AI to use, compare a fixed workflow, an AI step and an agent.

Sources

Vendor documentation checked September 26, 2026. The examples above are original designs using made-up data. They have not been run in connected accounts.

• Zapier: AI output fields
• Zapier: review steps and limitations
• Zapier: line-item loop setup
• Zapier: parallel loops and limits
• Zapier: Asana integration
• Asana: task field reference