# syncing Published articles for syncing. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Database & Asset Syncing Between Environments in Craft CMS DevFeed: [Database & Asset Syncing Between Environments in Craft CMS]() Original publisher: [Read original article]() Author: andrew@nystudio107.com (Andrew Welch) Published: 2016-12-06T08:41:00Z Content type: tutorial Language: en Sources: [nystudio107 | Articles on modern web development.]() Topics: [Content Management System](), [Databases](), [Git](), [Development](), [MySQL]() Tags: [assets](), [cms](), [database](), [development](), [environment](), [environments](), [git](), [help](), [here-s](), [important](), [insights](), [it-s](), [maintenance](), [pain](), [syncing](), [workflow]() ### AI overview This tutorial presents a practical workflow for syncing Craft CMS databases and assets across local development, staging, and production environments. It recommends using Git for one-way code flow and limiting the approach to small- and mid-size projects where more elaborate replication or migration techniques may be excessive. ### Source excerpt Syncing the database & assets between environments is an important workflow, but it's a pain. Here's some help ## Syncing from Postgres to Salesforce - Data Mappings DevFeed: [Syncing from Postgres to Salesforce - Data Mappings]() Original publisher: [Read original article]() Author: Map Published: 2016-11-23T20:55:56Z Content type: tutorial Language: en Sources: [Craig Kerstiens]() Topics: [Software as a service](), [Database](), [data](), [Ruby](), [Code](), [Software]() Tags: [code](), [crm](), [data](), [postgres](), [ruby](), [salesforce](), [syncing]() ### AI overview A tutorial on syncing data from a Postgres system of record into Salesforce for SaaS and B2B applications. It explains Salesforce data models, mapping internal users and customer information, and building the integration with example code. ### Source excerpt For the second time now I've had to implement a system that syncs from my system of record into Salesforce.com, the first at Heroku and now at Citus Data. The case here is pretty simple, I have a software-as-a-service, B2B product. It's a homegrown application in these cases in Ruby, but could be Python, .Net, any language of your choosing. The problem is I don't want to have to be rebuilding my own CRM, reporting, etc. on top of all of my internal database. And as soon as you're at some reasonable size (sales guy of 1 or more) you need to be able to provide insights on what's in that system of record database to others. While my tooling isn't a full fledged product by any means, here's a bit of how I've developed this process a few times over and some of the annoying bits of code to help get you started. In this post I'll walk through some of the basic datatypes, then we'll follow-up with the overall architecture and tweaks you need to make to Salesforce, and finally we'll provide some example code to help you create this setup yourself. Leads, Contacts, Accounts oh my Despite being some of the largest as-a-service vendors in the world, Salesforce is still primarily setup for traditional high touch sales. What this means is some of the data you'll commonly have, or in this case not have, can make it difficult to figure out what maps from your internal system to Salesforce. Within Salesforce there's really 4 key data models you're going to care about. Lead vs. Contact In every as a service product you'll have some user that creates and account which usually has an email address tied to it. This seems simple enough to load up to Salesforce as there is a clear email field. Within Salesforce there are two key data types which have a default field for this lead and contact, in Salesforce terms a lead is someone considering doing business with you, a contact someone who more so is doing business with you. If you have a freemium or timed trial model you might think to sta ## Offline Syncing - Kevin Galligan DevFeed: [Offline Syncing - Kevin Galligan]() Original publisher: [Read original article]() Published: 2012-10-08T03:12:00Z Content type: tutorial Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [data](), [App](), [Database](), [Data Management]() Tags: [android](), [apps](), [code](), [connectivity](), [data](), [data-management](), [database](), [errors](), [offline](), [server](), [syncing](), [thoughts]() ### AI overview This developer article explains why offline operation with data syncing is difficult, especially for read/write applications. It introduces state-based and command-based syncing, then outlines the implementation tradeoffs of state-based syncing, including error handling, duplicate writes, and entity-level updates. ### Source excerpt I will prep this post by saying the obvious to anybody who's had to do it. Offline operation with data syncing is difficult. By order of difficulty, apps and data generally go like this: - Offline only. No server communication. - Read-only. Just pull data. - Write-only (or read/write. similar). Pushing data requires dealing with errors and connectivity problems. - Read/write, with offline operation. This scale is not representative.