monday.com Item to Dataverse Two-Way Sync

Overview

A loop-safe two-way sync between a monday.com board and a Dataverse mirror table, built as two cloud flows in one solution (CF-652). New/changed monday items are upserted into Dataverse; app-side Dataverse changes are written back to the monday item. A stored ID map (flowlibs_mondayitemid) plus a source flag prevent infinite echo loops.

Why it matters: monday.com is the team's workspace; Dataverse powers Power Platform apps and reporting. A loop-safe bridge gives each system an authoritative, continuously reconciled copy without duplicate data entry.

Build note: The monday.com connector in this org (shared_mondaycom) is MCP-invoke only: it has a single operation InvokeMondayMCP and exposes the monday.com GraphQL API through a JSON-RPC gateway. It has no trigger, no GetItem, and no ChangeColumnValue action. So monday->Dataverse is a scheduled poll, and Dataverse->monday uses the Dataverse webhook trigger with a GraphQL change_multiple_column_values mutation for the write-back.

Use Case

A team manages work on a monday.com board but also wants those items available and updatable from Power Platform apps and Power BI, with status kept consistent in both directions. Edits made in either system flow to the other, with last-writer-wins conflict handling and no sync loops.

Flow Architecture

Environment Variables

Connectors & Connections

Connector	API name	Actions used
monday.com	shared_mondaycom	InvokeMondayMCP
Microsoft Dataverse	shared_commondataserviceforapps	SubscribeWebhookTrigger ListRecords CreateRecord UpdateRecord
Microsoft Teams	shared_teams	PostMessageToConversation

Note — All connections are referenced as solution connection references; the flow is portable between environments as long as a connection is mapped at import time.

Customization Guide

Almost every realistic variant of this flow can be implemented by changing environment variable values. A few cases require small edits inside the flow definition — those are called out explicitly below.

Conflict policy

Current behavior is last-writer-wins. To implement field ownership, compare flowlibs_lastsynced against the trigger's modifiedon before writing.

More columns

Extend the GraphQL query (Flow A) and the change_multiple_column_values payload (Flow B), add matching columns to the mirror table, and update flowlibs_MondayColumnMap.

Mirror updates/comments

Add a monday create_update mutation in Flow B to mirror Dataverse notes as monday item updates.

Backfill

Run Flow A once on demand to seed existing board items before enabling Flow B.

Trigger scope

Narrow Flow B's filteringattributes to only the columns an app should push back, to reduce trigger noise.

Key Expressions

The flow is intentionally light on Power Fx / WDL gymnastics — the heaviest expressions are the branch-name concatenation and the approval outcome check. They are listed below in the order they appear in the flow.

@and(not(equals(triggerOutputs()?['body/flowlibs_source'],'monday')), not(equals(coalesce(triggerOutputs()?['body/flowlibs_mondayitemid'],''),'')))

@json(coalesce(body('Query_Board')?['result']?['content']?[0]?['text'],'{}'))?['data']?['boards']?[0]?['items_page']?['items']

@first(items('Apply_to_each')?['status'])?['text']

change_multiple_column_values(item_id, board_id, column_values: "{\"status\": {\"label\": \"…\"}}")

@{coalesce(outputs('Init_Session')?['headers']?['Mcp-Session-Id'],'')}

Customize & download