Miro and CodeWords: getting decisions off the board

A Miro board after a good workshop holds real decisions, and within a fortnight it holds them where nobody will look. The value was in the conversation, the artefact is a grid of coloured notes, and whoever volunteered to write up the actions has not.

Automation helps with that, and it helps less than people expect with the board itself — because most of what a board means is spatial, and spatial meaning is exactly what an API cannot read.

What we'll cover

• What the API cannot see
• What the Miro API reaches
• Structuring boards so they can be read
• Connecting it to CodeWords
• Seven automations worth building
• The follow-up problem
• Getting the board out as a record
• Building it so it survives
• Limits worth knowing about
• What to build first
• Frequently asked questions

What the API cannot see

The API returns items with coordinates. What it cannot return is what the arrangement meant.

Proximity is meaning. Notes clustered together belong together, and nothing in the data says so. You can infer clusters from coordinates, and the inference is approximate in a way that matters when it is wrong.

Position on an axis is a judgement. Two-by-two grids encode effort and impact in x and y, and only the frame's labels say which is which.

Colour convention is local. Yellow means an idea on one board and a blocker on another, and the convention lives in the facilitator's head.

Size and emphasis carry weight that no field records.

Lines and arrows carry relationships, and they are readable through connectors, which makes them the most reliably interpretable structure on a board.

The conclusion is not that automation is pointless. It is that automation should read what is explicit — text, tags, frames, connectors — and leave the interpretation of arrangement to whoever was in the room.

What the Miro API reaches

Boards can be listed, created, and copied, which is how templated boards get created per project or per session.

Items — sticky notes, shapes, text, cards, images, and documents — can be created, read, updated, and deleted, each with position and style.

Frames group items spatially, and reading items by frame is the most reliable way to get the board's own sections.

Tags can be applied to items and queried, and they are the single most useful thing for making a board machine-readable.

Connectors express relationships between items explicitly.

Comments can be read and created.

Board members can be listed and managed.

Webhooks notify on board events on plans that include them, which suits reacting to a board being updated rather than polling it.

Structuring boards so they can be read

Small facilitation habits make the difference between a board an automation can use and one it cannot.

Name frames meaningfully. A frame called "Actions" is a contract with anything reading the board. "Frame 12" is not.

Tag what matters. A tag on the notes that became decisions is worth more than any amount of clever clustering, and applying it takes seconds at the end of the session.

Put one thought per note. Notes containing three things cannot be split reliably afterwards.

Write the owner on the action. A name on the note is the difference between an action item and an aspiration, and no automation can supply it.

Use connectors for dependencies rather than drawing loose lines, since connectors are data and lines are pixels.

Agreeing these before the workshop costs nothing. Retrofitting them afterwards means someone re-reading a board they have stopped caring about.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which board or frame, and what should come out of it.
3. Authorize the connection with a Miro token scoped to the relevant team.
4. Describe the exceptions: a note with no owner, an empty frame, an item that is not a sticky note.
5. Run it against a finished board you already know well, and compare what it produced with what you remember deciding.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Seven automations worth building

Actions frame into the tracker. Read the frame named for actions, create issues or tasks, and link each back to the board. The highest-value automation here by a distance.

A written record of the session. Board contents by frame, as a readable document, so the decisions exist in text for people who were not there and for the version of you in six months.

Board creation from a template. A new project produces a board from the right template, pre-populated with what is already known, shared with the right people. Removes setup friction that otherwise leads to workshops happening on a blank board with no structure.

Pre-populating from other systems. Sticky notes from tickets, survey responses, or research notes, arranged into a frame before the session so people react to real material rather than generating it from memory.

Closing the loop back. When an item created from the board is completed, mark it on the board. A board where done things look done stays worth opening.

Stale board reporting. Boards untouched beyond a threshold, with their owners, so the workspace does not silently become thousands of abandoned canvases.

Digest of active boards. What changed this week across boards a team cares about, which Miro's own notifications do not aggregate.

The follow-up problem

This is the whole point, so it is worth being specific.

Extract only what is explicitly marked. Notes in the actions frame, or notes carrying the action tag. Everything else is idea material and pulling it into a tracker creates noise that discredits the automation.

Require an owner and drop what has none, reporting the drop. An action with no owner is not an action, and creating an unassigned ticket just moves the problem.

Link back to the board item, so whoever picks the task up can see the surrounding context.

Run it while people still care — the same day, not the following week.

Report what was created to the participants, since the moment of "we agreed these six things and here they are" is what makes the next workshop better attended.

Do not create anything from an ideation frame. Divergent material is meant to be discarded, and an automation that converts it into work is actively harmful.

Getting the board out as a record

A board is a poor archive, and anything decided on one deserves to exist somewhere else.

Export to an image or a document for the visual record, which preserves the arrangement the API cannot interpret and is what people actually recognise months later.

Write the text record separately. Frame by frame, item by item, as prose or a list. This is the version that is searchable, and search is how anybody finds a decision later.

Keep both. The image shows what the board looked like; the text lets somebody find it at all.

Put it where the project lives — the project document, the wiki, the ticket — rather than leaving it in the board's own workspace, which is where things go to be forgotten.

Timestamp it. A board changes after the session, and a record captured at the end of the workshop reflects what was decided rather than what somebody adjusted afterwards.

Building it so it survives

Read by frame or tag, never by coordinates, since somebody will move things.

Make it idempotent. Record the item identifier on whatever you create, and check before creating again — boards get re-processed, often because the first run was slightly wrong.

Handle paginated item listings. A workshop board can hold hundreds of items and the first page is not all of them.

Expect mixed item types in a frame, including images and text boxes that are not sticky notes.

Report the outcome. Items read, tasks created, items skipped and why. The skip list is what tells the facilitator their tagging was incomplete.

Limits worth knowing about

Rate limits apply and are based on request credits, with bulk item creation cheaper than one call per item.

Webhooks depend on your plan, so polling may be the only option on some tiers.

Item content is lightly structured. A sticky note's text is a string, and any structure inside it is a convention you imposed.

There is no history through the API. You can read a board as it is, not as it was, which limits anything trying to report on change.

Not every item type is fully supported for creation and update, so check the ones you depend on rather than assuming parity.

What to build first

The actions frame into your tracker: read the frame named for actions, create a task per note that carries an owner, link each back to the board item, and report what was created plus what was skipped for having no owner.

Two habits make the difference. Run it the same day, while the workshop still matters. And show the skipped list to the facilitator, because "four notes had no owner" is the most useful feedback a workshop can get and the fastest way to make the next board readable.

Frequently asked questions

Can an automation work out which notes are important?

It can read what you marked — tags, a named frame, connectors — and it cannot reliably read what the arrangement meant. Clustering by position approximates it and is wrong often enough to matter. Marking takes seconds during the session and removes the guesswork entirely.

Should everything on the board become a task?

No, and this is the commonest mistake. Ideation notes are meant to be discarded. Create tasks only from an explicitly marked actions frame or tag, or the tracker fills with noise and people stop trusting anything that came from a board.

How do I stop duplicate tasks when it runs twice?

Store the Miro item identifier on the task you create and check for it before creating another. Boards get reprocessed routinely, usually because the first attempt happened before somebody finished tidying up.

Can it create a board for each new project?

Yes — copy a template board, share it with the right people, and pre-populate frames with what is already known. It removes the setup friction that otherwise leads to sessions running on an unstructured blank canvas.

Do webhooks work on every plan?

No, webhook availability depends on the plan. Where they are not available, poll on a schedule, which is entirely adequate given that boards are edited in bursts around sessions rather than continuously.

Can I get board history?

Not through the API. You can read the current state, so anything reporting on change has to snapshot periodically and compare, which is worth knowing before designing around it.

What makes a board automatable?

Named frames, tags on the things that matter, one thought per note, an owner written on every action, and connectors for dependencies. All are facilitation habits rather than technical work, and all are far easier to do during the session than after it.

What is the best way to archive a workshop?

Both an image export and a text record, stored where the project lives rather than in the board workspace. The image preserves arrangement the API cannot read; the text is what makes the decision findable six months later.

Should the record be captured at the end of the session?

Yes, and timestamped. Boards get edited afterwards, sometimes substantially, and a record captured later reflects what somebody tidied rather than what the group agreed.

Related reading

• Figma and CodeWords
• Notion and CodeWords
• CodeWords integrations and templates