CRM Solution

How a CRM Project Actually Runs

The first pass is process capture, not software. Someone walks a real deal from first contact to paid invoice and names every point where a record gets created, a field gets filled, or a message gets sent by hand. That walk produces the object model: what counts as a contact, what counts as a company, what counts as a deal, and whether you need anything beyond those three. Most of the disagreements that would otherwise surface in week six surface here instead, while they are still cheap.

Configuration happens in a sandbox or a trial tenant, never in the system your team is using that day. A migration dry run against the real export follows, because a sample never shows what the full file contains: dates in three formats, an amount column stored as text, owners who left two years ago, a country field with forty spellings of the same country. The dry run gets repeated until it is boring, and only then does the live load happen, against a short window when nobody is editing the source.

Integration is built after the CRM's own configuration is settled. Every connector is written against specific field names, picklist values, and required-field rules, so building it while those are still moving means building it twice. The same applies to reports and dashboards: they are the last thing, not the first, because each one encodes the field list as it stood the day it was built.

• A full export of the current system or spreadsheets, taken at a known point in time, including the ID column if the export offers one
• Administrator access to the CRM and to each system it will connect to, granted before configuration starts rather than requested one task at a time
• One person who can settle process questions and required fields without convening a meeting
• The user list with roles, and which of those users need a full license as opposed to read-only access
• A named freeze window for the final load, and agreement on who tells the team the old system is closed

What the API Actually Allows

All of these platforms expose an HTTPS REST API on port 443, authenticated with OAuth 2.0. The integration is registered as an app, an administrator consents once, and the connection then runs on a refresh token rather than on anyone's password. That token is revocable in ways that have nothing to do with your code: an administrator removing the connected app, a change to the requested scopes, or a security policy that expires authorizations. The failure shows up as HTTP 401 on every call, and it shows up in your integration's logs, not as a warning inside the CRM.

Rate limits are metered differently from platform to platform, and the difference decides your sync design. Some allocate a rolling 24 hour request quota per organization that scales with the number of licenses. Some enforce a short burst limit measured in seconds alongside a separate daily cap. Some meter credits by edition. A nightly full sync and a per-record real time sync fail against different ones of those, so the limit you are under is worth reading before the pattern is chosen. When you exceed a limit the response is HTTP 429 with a Retry-After header, and an integration that ignores that header turns a temporary throttle into a stalled queue.

Webhooks and scheduled polling solve different halves of the problem. A webhook fires on change and keeps the two systems close to current, but delivery is at best at-least-once: if your endpoint is down or slow, the platform retries a fixed number of times and then drops the event permanently. Bulk imports and mass edits frequently do not fire webhooks at all. Anything that has to be complete rather than merely fresh needs a reconciliation pass on a schedule, querying records modified since the last successful run and repairing what the event stream missed.

Every Synced Record Needs an ID on Both Sides

Matching records by email address or company name works until it does not. Two people share a mailbox, someone changes jobs and keeps the deal, and the same company exists as Acme Inc in one system and Acme, Inc. in the other. Name and email matching produces both duplicates and wrong merges, and the wrong merge is the more expensive of the two because nothing about it looks broken afterward.

Every synced object needs a stored external ID on each side: the CRM record holds the other system's key in a dedicated field, and the other system holds the CRM record ID. Writes then become upserts keyed on that field instead of inserts. Without it, a re-run after any interruption creates a second copy of everything it already wrote, and there is no reliable way to tell the copies apart once they exist.

Deletes and merges do not propagate the way people expect. Merging two companies in the CRM leaves the losing record's ID pointing at nothing on the other side, and a hard delete removes the row the integration was matching on, so the next run recreates it. Decide whether either action is permitted at all in the connected systems, and where merges are permitted, keep the merged-from ID as an alias so older references still resolve.

• Picklist values mapped explicitly in both directions, since an unmapped value is either rejected outright or written as blank without complaint
• Dates and times stored in UTC, with a check on whether each API returns the calling user's timezone or the organization's
• Currency carried as amount plus currency code, and a decision on whether the rate is captured at close or read live
• Validation rules on the receiving side checked against what the integration can actually supply, because a rule added six months later breaks a sync that worked yesterday
• An owner mapping for records whose source system has no equivalent user

Pipeline History Is Not Stored Unless Something Stores It

A CRM shows you the current state of a deal. Nearly every question asked three months later is a history question instead: how long deals sat in each stage, which stage they most often died in, how many times a close date moved before it held, whether the cycle is getting longer. None of that can be derived from a record that only knows where it is now.

Stage transitions and field changes are captured only when history tracking is enabled for those specific fields, and platforms cap both how many fields per object can be tracked and how long the entries are retained. Turning it on is a configuration decision that has to be made at go-live, because history is the one thing that cannot be backfilled after the fact.

Created date and modified date are not a substitute. Modified date tells you when the record last changed, not what changed or how many times it changed, and any integration writing to a record updates it, so a single synced field can make every record in the system look recently active.

Ownership, Access, and What Happens When Someone Leaves

Record ownership is not a label on a page. On most platforms it drives visibility: who can open the record, whose forecast it counts toward, who receives the notification when it changes, and which sharing rule applies. Under a role hierarchy or a private sharing model, reassigning an owner changes who can see the record at all, which is why bulk owner changes are worth doing deliberately rather than as cleanup.

Integrations should authenticate as a dedicated account created for that purpose, never under a person's login. When a sync runs on an employee's credentials, deactivating that employee stops it, and every record the integration ever touched shows that employee as the last person who changed it. A dedicated account keeps the audit trail honest about which edits were automated and which were typed. It needs a license and a permission set of its own, which is a line item people usually discover at go-live.

When someone leaves, deactivate the user rather than deleting it, so historical records keep a valid owner reference and the activity history stays attached to the deals it belongs to. Reassignment should follow a rule written down in advance, because the alternative is a set of judgment calls made in a hurry on someone's last day.

• Reassign open deals by rule, whether that is territory, account, or the owner of the next stage, rather than case by case
• Leave closed records with their original owner so last quarter's reporting does not change retroactively
• Move scheduled reports, dashboards, and automations that reference the person before the account is deactivated
• Check what depended on their mailbox or calendar connection, since that link dies with the account and any logging built on it stops without an error
• Revoke API tokens and connected apps that individual authorized personally