Monday.com and CodeWords: when a board becomes a database

Monday boards have a way of graduating. Something starts as a way to track a handful of tasks, people add columns because the information has nowhere better to live, and within a year it holds the client list, the delivery status, and the invoicing state, with four people depending on it daily.

At that point the board is a database, and it has none of the things a database has: no constraints, no referential integrity, no types beyond what the column enforces, and nothing stopping somebody typing into a field another team reads. The useful automation around Monday is largely about compensating for that.

What we'll cover

• The board that became a system of record
• What the Monday API reaches
• Column types, which decide what is possible
• Connecting it to CodeWords
• Eight automations worth building
• Knowing when the board should stop being the answer
• Building it so it survives
• Limits worth knowing about
• What to build first
• Frequently asked questions

The board that became a system of record

Four symptoms, and most boards of a certain age have all of them.

Columns nobody can explain. Added for a reason that made sense at the time, still populated out of habit, read by nobody.

Status values that overlap. "In progress", "Working on it", and "Started" all present, meaning the same thing to different people, which makes every filter and every report approximate.

Data that contradicts another system. The board says the invoice went out; the accounting system disagrees. Both are confidently displayed to different people.

Manual copying in and out. Somebody updating the board from the CRM every Monday, and somebody else updating the CRM from the board every Friday.

Monday's own automations handle things inside a board well — status changes, notifications, item creation. What they cannot do is reconcile against the outside world, which is where the problems above actually live.

What the Monday API reaches

Monday's API is GraphQL, which is worth knowing because it changes how you think about fetching: you ask for exactly the fields you want in one request rather than making several.

Boards can be listed and read with their columns, groups, and structure.

Items and subitems can be created, read, updated, moved between groups, and deleted, with column values.

Column values are the awkward part and the next section covers them.

Updates — the conversation thread on an item — can be read and written, which is where automated context belongs.

Users and teams can be read, for anything about assignment.

Webhooks fire on item and column changes, which is what lets automation react.

Workspaces organise boards, and an automation spanning several needs to handle that explicitly.

Column types, which decide what is possible

This is where Monday automation is genuinely fiddly, and knowing it in advance saves a frustrating afternoon.

Every column type has its own value format. A status column, a date column, a person column, and a connect-boards column each expect a different structure when written, and several are more complex than they look.

Reading and writing are not symmetrical. The shape you read back is not always the shape you write, which catches people who assume they can round-trip a value.

Status columns use indexes as well as labels. Writing a label that does not exist behaves differently from writing one that does, and this is a common source of silent failure.

Connect-boards columns hold references. Writing one means holding the item ID from the other board, which means finding or creating that item first.

Formula columns are computed and not writable, which surprises automations attempting to set them.

The practical advice: read an existing item's column values first and match that shape. Guessing the format is where most of the time goes.

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, naming the board, the columns, and the systems involved.
3. Authorize the connection with an API token scoped appropriately.
4. Describe the exceptions: an item that already exists, a status value that is not in the column's options, a connected item that has been deleted.
5. Test against a duplicate of the board before pointing anything at the real one.

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.

Eight automations worth building

Reconciliation against the real system of record. Compare the board against your CRM, your accounting system, or your database, and report the differences. This is the highest-value automation here because it makes visible how far the board has drifted, which is usually further than anyone expects.

Intake from elsewhere. Create items from form submissions, emails, or CRM events, with columns populated properly, so nobody retypes.

Status hygiene reporting. Items whose status has not changed in a long time, items in a status that no longer exists in the workflow, and items with mandatory columns empty.

Cross-board consistency. Where two boards hold related information, report where they disagree rather than silently propagating one over the other.

Scheduled digests. What changed this week, what is overdue, what is sitting unassigned, delivered to a channel rather than waiting for someone to open the board.

Archival. Move completed items to an archive board on a schedule, which keeps the working board fast and its views legible.

Document and asset generation. Produce a brief, proposal, or report from an item's fields and attach the result back to the item.

Column usage reporting. Which columns are actually populated and which are empty on most items. This is the report that gets boards tidied, because it makes the accumulated cruft visible.

Knowing when the board should stop being the answer

Worth saying, because automation can prolong a bad arrangement well past the point it should have ended.

When two systems both claim to own the same data, one of them is wrong and automation syncing them is treating a symptom. Decide which owns it.

When the board has more than a few thousand items, it is slow to work with and the views stop being useful, and automation cannot fix the interface.

When people are filtering rather than reading, the board has become a query interface for a dataset, which is a thing databases do better.

When correctness matters and there are no constraints, the absence of validation becomes a real risk. A board where somebody can type anything into the invoice status column is a board that will eventually contain something wrong at a moment it matters.

Automation is genuinely useful in all four situations as a bridge while you decide what to do. It is a poor permanent answer, and it is worth saying so rather than quietly building something that makes the wrong arrangement survivable for another two years.

Building it so it survives

Make it safe to run twice. Webhooks retry. Check for an existing item before creating, matching on a stable identifier stored in a column rather than on the item name.

Reference columns by ID, not by title. Titles get renamed, and an automation matching on title breaks silently the first time somebody tidies the board.

Read an item first to learn the value shapes, rather than guessing the format for each column type.

Report the outcome. A daily line with items created, updated, and skipped makes silence meaningful.

Never bulk-delete without a record. Log what was removed, and prefer moving to an archive board.

Limits worth knowing about

The API is rate limited by complexity, not simply by request count, so a GraphQL query asking for a great deal in one request can be rejected for being too expensive. Ask for fewer fields rather than making more requests.

Item limits per board affect performance well before they affect function, and a board with tens of thousands of items is unpleasant regardless of what the limit says.

Column value formats are the main source of errors, and the error messages are not always specific about which column was wrong.

Deleted items go to a recycle bin with a retention period, which is helpful and not a substitute for logging.

Subitems have their own board behind the scenes, which surprises automations treating them as ordinary fields of the parent.

What to build first

Reconciliation against whichever system genuinely owns the data the board duplicates. Read-only, report the differences, change nothing. It usually reveals that the board and the source disagree on more rows than anybody believed, and that finding is what informs every decision that follows.

Two habits make the difference. Report the differences rather than resolving them, at least initially, because the differences tell you where the process is broken. And have it report even when the two agree, because a silent reconciliation cannot be distinguished from a broken one.

Frequently asked questions

Should I use Monday's own automations?

Yes, for anything inside a board — status changes, notifications, item creation, due date reminders. They are native and there is nothing to maintain. Reach outside when the logic involves another system, which is where the interesting problems are.

Why does writing a column value keep failing?

Almost certainly the value format, which differs per column type and is not always what you would guess. Read an existing item's values for that column and match the shape you get back, rather than constructing it from the documentation alone.

Can an automation create items with connected boards?

Yes, and you must resolve the connected item first, since the column holds a reference rather than a name. Find or create the item on the other board, then write its ID. Writing a name and hoping it resolves is a common cause of silently empty connections.

How do I keep a board in step with our CRM?

Decide which one owns each field first, then sync in that direction only, and report rather than resolve anything that disagrees. Bidirectional sync between two systems that both allow editing is how you get a field that flips back and forth and a team that trusts neither.

Is there a limit on board size?

There are limits, and performance degrades well before you reach them. A board of several thousand items is slow to filter and unpleasant to work in, which is usually the signal to archive completed items rather than to negotiate a higher limit.

Why is my query rejected as too complex?

Monday rate limits by query complexity rather than by request count, so asking for many nested fields at once can exceed the budget even in a single request. Request fewer fields, or split the query, rather than assuming it is a volume problem.

When should we move off the board entirely?

When two systems both claim to own the same data, when correctness matters and nothing validates entry, or when people are filtering rather than reading. Automation is a reasonable bridge while you decide, and a poor permanent answer to any of the three.

How do I migrate a board that has outgrown itself?

Start with the reconciliation report, since it tells you which columns are actually maintained and which are abandoned. Migrate the maintained ones, archive the rest, and resist recreating every column in the new system out of habit.

How do I reduce column sprawl?

Report which columns are actually populated across items and share it. A column empty on ninety percent of rows is either unused or being used inconsistently, and both are worth knowing. Making it visible does more than any policy about adding columns.

Can automation enforce data quality on a board?

It can report on it, which is the realistic goal. Monday has no constraints, so enforcement means an automation correcting or blocking after the fact, which people find intrusive. A weekly report of items with missing or invalid fields gets the same outcome without fighting anyone.

Related reading

• Jira and CodeWords
• Airtable and CodeWords
• CodeWords integrations and templates