Migrate from monday service to Salesforce Service Cloud

monday Items on support boards map to Salesforce Case. We extract the board ID, Item ID, Item name, Item body (description), status column value, priority or label column values, assignee (agent), created date, and last updated date from the monday API. Status column values map to Case Status picklist values that we configure in Salesforce as part of the Case Record Type; priority maps to Case Priority. The Item's parent board context is preserved as a custom field monday_board_id__c for audit and reconciliation. We flag any Item that references a sub-board or linked board as a lookup complexity requiring manual parent resolution before migration.

monday customer records live either as Items on a dedicated Customer Board or as contacts managed through monday.com's Contacts integration. Both map to Salesforce Account (company-level record) and Contact (person-level record) with a required Account-Contact relationship. We use the customer Item's company name or the contact's organization field as the Account Name, and the contact's name, email, and phone as Contact fields. If monday stores multiple contacts per company on a single Item, we split them into separate Contact records linked to the same Account. Duplicate Account creation is prevented by using domain or company name as a dedupe key.

monday Updates attached to Items store agent and customer replies in reverse-chronological order within the board UI. We extract all Updates with author, timestamp, and text content and map them to Salesforce CaseComment records (internal or public, depending on the Update's visibility setting in monday). If the monday board uses an email integration to populate Updates, those entries migrate as EmailMessage records linked to the Case. Rich media embedded in Updates (images, links) are extracted as text references; inline images require post-migration re-attachment. Thread ordering is preserved by sorting on the monday creation timestamp before insert.

Some monday service configurations store conversation threads as Sub-items on the ticket Item rather than Updates. Sub-items with a body and author map to Salesforce Task records (with TaskSubtype = Call or Task depending on subtype) linked to the parent Case via WhatId. Sub-items used for internal notes map to internal CaseComment records. We enumerate the sub-item structure during discovery and configure the mapping accordingly per board.

monday service stores SLA targets as custom date columns (First Response Due, Resolution Due) or as date formulas referenced by automation rules. These map to Salesforce Entitlement records with associated SlaProcess objects defining the milestone type (FirstResponse, NextResponse, Resolution) and target time in hours or business hours. We extract the SLA column values as entitlement start and target dates, and configure Business Hours in Salesforce to match the monday workspace SLA calendar. Automation rules that auto-update SLA columns cannot migrate — we document each rule for manual rebuild in Salesforce Flow or Omni-Channel.

monday.com Users (agents and team members) map to Salesforce User records by email address match. We extract display name, email, active/inactive status, and role assignment. Owners on monday Items resolve to Salesforce OwnerId on Case via the User mapping. Any monday user without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before Case migration begins.

monday boards map to Salesforce Queues for routing and Case Origin for channel identification. Each monday support board becomes a Queue with the board's group structure optionally mapped to Case Origin values (Email, Chat, Phone, Web). We configure the Queue during migration scoping and advise on whether the board grouping (e.g. product team, region) maps better to Queue or to a custom Picklist field on Case.

monday Groups (row groupings within a Board) contain Items and preserve a grouping hierarchy. If the monday Groups represent distinct case categories or channels, they map to a custom picklist field on Case (e.g. case_category__c). If they represent priority tiers, they merge with the Case Priority mapping. We resolve this per board during discovery based on how the customer uses Groups.

monday column types (text, numbers, dates, status, dropdown, link, file, formula, location, week, time tracking, vote, progress) translate to Salesforce field equivalents. Status columns map to picklists; date columns map to Date or DateTime; numbers map to Number; text maps to Long Text Area or Text. Formula columns, vote columns, and progress columns are calculated in monday and have no direct Salesforce equivalent — we preserve their last computed values as read-only custom fields on Case and note the formula for manual translation to a Salesforce formula field. Column-level visibility and required settings are translated to Field-Level Security profiles in Salesforce.

Files attached to monday Items (uploaded via the file column type) are extracted from the monday account export or via the monday API. We map them to Salesforce ContentDocument and ContentVersion records linked to the Case via ContentDocumentLink. Large file attachments (>5 MB per file) add significant processing time; we optionally defer file re-attachment to post-migration and migrate only the file metadata (name, size, URL, attached date) as a custom field for manual re-link. Files stored externally (Google Drive, Dropbox) require separate re-authentication and re-link post-migration.

monday Tags applied to Items are extracted as label values. We map them to a Salesforce multi-select picklist field on Case (e.g. monday_tags__c) or to Salesforce Topics with TopicAssignment records, depending on whether the customer plans to use Topics for broader categorization. The customer chooses the tag strategy during scoping.

monday.com does not expose automation rules through its public API. We enumerate every active automation during discovery — trigger type, conditions, actions, and board scope — and deliver a written automation rebuild playbook describing each rule and its recommended Salesforce Flow equivalent or Omni-Channel routing rule. The customer's admin rebuilds these post-migration; FlitStack AI does not configure Flow inside the migration scope.