monday.com FAQ

Use the native "When date arrives" automation trigger rather than trying to compare dates inside an action. Pick the date column you want to watch, then chain whatever follow-up action you need: change a status, notify a person, move the item, or create a subitem. The trigger fires once per item per day, so it is reliable for renewal reminders, follow-up cadences, and stage transitions tied to a deadline. If you need a more complex condition (for example, only fire when a status is also a certain value), add the condition step inside the same automation rather than splitting it into two recipes.

There is no single "copy column to column" automation in the basic recipe library. The two reliable patterns are: (1) use the Workflow Builder and add a "Set column value" action that references the source column as the value (this works for text, number, and most simple column types); or (2) use a Formula column that reads from the source column conditionally on the checkbox state, and treat the formula as your read-only "copied" value. Pattern 1 stores a real value in the destination column. Pattern 2 keeps it as a derived field and avoids storing duplicate data. Pick based on whether downstream automations need to read the destination column as a real value.

The classic recipe builder is linear: trigger plus action. To run a conditional check before the action, use the Workflow Builder rather than the recipe builder. The Workflow Builder supports If/Then branching as a node, so you can express "when status changes to complete, if completion date is empty then set it to today, else do nothing, and either way move the item to the completed group" as a single workflow. If you build it as two separate recipes you risk race conditions and double-firing. Single workflow is the right pattern.

The Dependent On column does not currently expose a "clear" action in the standard automation library. Three workarounds: (1) use the API or a Make.com scenario to write a null value to the Dependent On column on a trigger; (2) restructure to use a Connect Boards column instead, which does support automation actions for setting and clearing; or (3) handle the dependency at the project structure level by deleting or archiving the unused task rather than clearing its dependency link. Option 2 is usually the cleanest if you can refactor.

Dynamic mapping in the legacy automation builder let you reference fields generically across different boards. In the Workflow Builder, the equivalent is explicit field mapping per node: each action node specifies which source field maps to which destination field, with the mapping configured inside the node rather than inferred at runtime. The benefit is fewer silent failures; the cost is that workflows take slightly longer to build and you cannot reuse one workflow across structurally different boards without rebuilding the mapping. If you have a heavy library of dynamic-mapping automations to migrate, plan it as a project rather than a side task.

Use a Connect Boards column on the task board pointing to the client board. Each task item can then be linked to one (or many) client items. Add Mirror columns on the task board for any client fields you want to see at task level (for example, account manager, region, contract status). Avoid the temptation to duplicate client data into the task board. Connect plus mirror is the right pattern. If you need to roll task progress back up to the client board, use a Mirror column on the client board reading from the task board, and use a Status or Numbers Mirror with summary settings to get aggregates. Designing this once, properly, saves hours of cleanup later.

Two patterns work depending on the level of detail you need. (1) One item per event with subitems for each phase: clean for reporting and easy to roll up dates and statuses. Best when phases are predictable and similar across events. (2) One item per phase, grouped by event: better when phases have very different teams, locations, or workflows and you need to filter or assign at phase level. Either way, use a Connect Boards column to link the event board to the master project board, and Mirror columns for the fields the master board needs to surface. For a chronological view, use a Timeline column on each phase and view it as a Gantt or Calendar.

Subitem updates have their own notification rules separate from parent item updates. The simplest approach is to set up a subitem-level automation: "When an update is created in a subitem, notify [person]." This uses the subitem automations menu rather than the main board automations menu, which is where most people get stuck. If you want anyone assigned to the subitem to be notified automatically, check that the subitem People column maps to the relevant role; assigned people are notified by default for some events but not for updates, which is why the explicit automation is usually needed.

No, not automatically as a continuous two-way sync in the way most teams expect. Connecting CRM contacts to Campaigns contacts links them at a point in time; subsequent edits made on one side do not automatically propagate to the other unless you build automations to push the updates explicitly. This is a known limitation rather than a configuration error. The practical pattern: treat the CRM as the source of truth for contact data, run automations that push changes to the Campaigns side on contact update events, and avoid editing contact data directly inside Campaigns. If you need true bidirectional sync, you will need a Make.com scenario or similar middleware sitting between the two.