monday.com Work Management Core Certification cheat sheet

Board hierarchy: workspace > folder > board; a board is a collection of items (rows) with columns (fields). Subitems live one level below an item and have their own column set.

Column types and their data: Status (label set + optional color), Dropdown (multi-select labels), Text, Numbers, Date (supports date + optional time), People (single or multiple), Timeline (start + end date), Files, Connect Boards (one- or two-way link to another board), Mirror (read-only pull of a connected board's column), Formula (calculated from other columns).

Item views: Main table, Kanban (grouped by status/dropdown/person), Calendar (requires a date column), Timeline/Gantt (requires timeline or date columns), Chart, Map, Workload, Form, Files, and App views. Switching views does not move data.

Groups are horizontal item buckets inside a board; group-level actions (archive, duplicate, color, collapse) apply to all items in the group. Group names are labels, not column values, so automations cannot reference a group as a status label.

Permissions model: account roles (admin, member, viewer, guest) plus board-level permissions (edit, view-only, or private). Private boards are visible only to board subscribers; guests see only boards they are invited to.

Deletion is two-stage: items go to the board's Trash and are recoverable; boards go to the workspace/account Trash. Permanent deletion (and Trash purge) is irreversible.

Connect Boards vs Mirror: Connect Boards creates the actual link (stored on the source board); Mirror displays a column value from the connected item and updates automatically when the source value changes.

Template library and board duplication: duplicating a board copies structure, items, and automations but not integration connections; automations that reference external apps must be reconnected after duplication.

Item ID is a unique numeric identifier per board used in URLs and API calls; the item name is user-editable and not a reliable key.

Dashboard widget types: Chart (bar, stacked, pie, line, battery, number), Calendar, Timeline, Table, List (text), Numbers/Battery, Gantt, Workload, Files, and App widgets. Each widget is bound to one or more source boards.

A widget's result depends on its aggregation setting: count of items, count of items per group, count by status label, sum/average/min/max of a Numbers column, or percent of total.

Chart widget filters can be set per widget, so two widgets on the same dashboard can show different slices of the same board without changing the board itself.

Dashboard-level filters (date range, person, status) apply across widgets that support filtering; widget-level filters stack on top of dashboard filters.

Dashboards are not live formulas on the board - they read board data at render time; a change on the source board appears after the dashboard refreshes.

Multi-board widgets merge data only when the selected boards share the column being charted (same column title/type); mismatched columns produce empty or partial results.

Workload widget uses People column assignments and, for subitems, the subitem People column; capacity is configured per person inside the widget.

Sharing: dashboards can be shared with board subscribers, the whole account, or a public link (view-only). Public links expose the widget data to anyone holding the URL.

Exporting: dashboards can be exported to PDF/image; board views can be exported to Excel/CSV. Exported snapshots do not update automatically.

Integration model: an integration is a recipe of trigger + action connecting monday.com to an external app; it runs under the account of the user who created it and stops if that user is deactivated or loses access to the board.

Native integrations cover Gmail/Outlook (email to item, item to email), Slack/Teams (notifications, create item from message), Google Calendar/Outlook Calendar (sync date columns), Zoom, Dropbox/Google Drive/OneDrive, GitHub, Jira, Salesforce, HubSpot, and webhooks.

Webhook integration: monday.com sends an HTTP POST with a JSON payload to a URL on a chosen event (item created, status changed, column changed). The receiving endpoint must accept POST and return 2xx.

Inbound vs outbound: 'when something happens in monday.com, do X in the other app' is outbound; 'when something happens in the other app, create/update an item in monday.com' is inbound.

Integration recipes have a limited or unlimited run quota depending on plan tier and action type; actions that fail (auth expired, target deleted) show in the integration's activity log.

Integration ownership and board access: the recipe executes with the permissions of the connecting user, so it cannot write to boards that user cannot edit.

Custom integrations via the monday.com API or apps framework (monday apps) allow custom triggers/actions; these require an app with scopes and are installed per account.

Integration Center lists installed recipes per board; disabling an integration stops future runs but does not undo past actions.

Automation anatomy: trigger ('When ...') + condition (optional, 'and only if ...') + action ('then ...'). One recipe = one trigger, up to a small number of actions depending on recipe.

Trigger types include status changes to a specific label, date arrives, item created, column changes, person assigned, subitem created, and recurring ('every time period').

Condition vs trigger: putting a status check in the trigger fires only on that transition; putting it in the condition evaluates the state at run time and can also catch other edits.

Recipes run as the account, not as the item's owner; 'change status' actions and 'notify' actions target the People column or a fixed user depending on the recipe wording.

Custom automation builder allows multiple conditions (and/or) and multi-step actions; it is the only place to combine conditions that the prebuilt recipes do not offer.

Loop risk: an automation that changes a status which itself triggers another automation on the same board can cascade; monday.com limits recursive runs, so design triggers to be mutually exclusive.

Date-based automations run on the date column value in the account's time zone; 'date arrives' fires once per item per date unless the date is changed.

Automation activity log per board shows run history and errors; failed runs (e.g., missing column value, archived item) do not retry automatically.

Automations count against the account's monthly action quota on plans that meter actions; the quota is shared across all boards in the account.

AI capabilities in monday.com are delivered as AI blocks/agents attached to boards or as AI-assisted actions inside automations; they require the feature to be enabled on the account and may be plan-gated.

AI agent pattern: define the trigger (item created, status change), give the agent a prompt plus board context, and choose an output target such as a status, text column, or subitem.

AI output is generated text or classification, not deterministic - the same input can yield different wording; validate critical fields with a human review step before downstream automations act on them.

Common AI use cases: summarize an item's updates into a text column, classify incoming requests into a status label, draft a reply, extract fields from an email or form submission, and generate subitems from a description.

AI workflows are automations whose action is an AI step; they consume the same automation quota plus any AI-specific usage limits, so high-frequency triggers can exhaust limits quickly.

Prompt design rule: include the allowed output values explicitly (e.g., 'answer only High, Medium, or Low') and map the result to a status label with a fixed mapping to avoid invalid labels.

Data handling: prompts and item content are sent to the AI provider when the agent runs; do not route confidential columns into AI steps unless the account's data policy permits it.

Human-in-the-loop: add a 'needs review' status and a notify action after the AI step so a person confirms before the item moves to a final state.

AI steps cannot read columns the running user cannot access, and they do not browse the web unless the specific feature supports it.