← All articles

Operations guides

Before spreadsheet data reaches a CRM, define what each value means

Preserve identifiers, currencies, and dates when reusing spreadsheet data. Build a mapping worksheet before planning a CRM or API connection.

A paper-cut hand aligns an identity tag above a grid with coin and calendar tags, coloured values and one empty cell.

A client ID appears as 00123. A fee appears as $1,234.50. An appointment date appears as 03/04/2026.

All three cells look usable. Yet each leaves a question for the next system: do the leading zeroes identify the client, which currency does the dollar symbol represent, and does the date mean March 4 or April 3?

Before planning a CRM connection, define what these values mean. A transfer can preserve the visible text and still leave the destination with the wrong interpretation.

The examples here are hypothetical. Their actual API output would depend on the cells’ underlying types, formatting, spreadsheet settings and request options.

Separate a value from its appearance

Google’s Sheets API documents several choices for reading values. FORMATTED_VALUE returns calculated values with formatting based on the spreadsheet’s locale. UNFORMATTED_VALUE returns calculated values without formatting. FORMULA returns formulas. These choices serve different purposes. Google’s ValueRenderOption reference.

Writing has a separate choice. RAW stores values without parsing them, while USER_ENTERED interprets values as entry in the Sheets interface would, potentially converting strings into numbers or dates. Google’s ValueInputOption reference.

These settings matter, but choosing one does not define your business data for you. A number intended for calculation and an identifier composed of digits need different treatment even when they look similar.

Nor can a later transfer recover meaning already lost upstream. If the authoritative identifier contains leading zeroes, establish that value from a reliable source before relying on it to match records.

Write a reuse agreement for important fields

A practical mapping worksheet should connect the source value to a business meaning, a type and an update rule. This is editorial guidance rather than a Google requirement.

  • Source field: Client ID; Intended meaning and type: Exact identifier, stored as text; Missing-value rule: Hold for review if absent; Destination and update owner: Verified client identifier field; operations owner
  • Source field: Fee; Intended meaning and type: Numeric amount plus explicit currency; Missing-value rule: Do not interpret blank as zero; Destination and update owner: Verified amount and currency fields; billing owner
  • Source field: Appointment date; Intended meaning and type: Date-only value with confirmed interpretation; Missing-value rule: Ask for clarification if ambiguous; Destination and update owner: Verified date field; scheduling owner

Fill in the actual destination fields after checking the destination’s schema. A proposed field name is not evidence that a CRM supports it, accepts that type or permits the intended update.

The owner column also matters. If the sheet and the destination disagree, someone needs authority to decide which value should prevail. Otherwise, connecting the systems can move the disagreement around without resolving it.

Work through three ordinary-looking cells

For client ID 00123, ask whether the zeroes are part of the identifier. If they are, preserve the identifier as text throughout the mapping. Check the destination record match as well as the displayed value. Do not invent missing zeroes from a guessed length rule unless the authoritative identifier specification establishes that rule.

For $1,234.50, establish the currency explicitly. In this hypothetical workflow, the agreed representation could be numeric amount 1234.50 and currency USD, once the source confirms US dollars. Keep the amount usable for calculation while making the currency unambiguous. The symbol alone is insufficient to make that business decision.

For 03/04/2026, consult the source context or ask the responsible person. If the confirmed date is 3 April, record an unambiguous representation such as 2026-04-03 in your mapping specification. That is a proposed representation; the destination’s required format still needs verification.

These checks have a common purpose: make interpretation explicit before an update reaches a client record or a generated document.

Dates need context beyond formatting

Google documents Sheets date and time values as decimal serial values. The serial value does not contain a time-zone offset; interpreting time values requires attention to the spreadsheet’s timeZone setting. Google’s date and number formats guide.

Distinguish a date-only fact from an event at a particular time. A service date may need to remain the same calendar date. An appointment at a specified local time requires additional time-zone context. Decide what the field represents before choosing a conversion rule.

This is also why a readable date in the source is only the start of a review. The destination must retain the intended calendar meaning, not merely produce another plausible date string.

Review the destination before expanding the transfer

Choose a small set of representative records. Include an identifier with leading zeroes, an amount with an explicit currency, an ambiguous date that has been resolved, and a missing value.

For each record, compare the source with the destination. Did the correct client receive the update? Did the identifier remain exact? Are amount and currency still paired? Did the date keep its intended meaning? Did the missing value follow the agreed rule?

If the workflow includes writing information back, review that return journey too. A successful transfer message confirms less than a comparison of identity, value and meaning.

A real CRM or API workflow also requires verified access, destination fields and update behavior. Start by documenting the meaning of a few important fields. With that agreement in place, a connection has a clear job—and your team has a concrete way to assess its output.

How this connects to Inloom

Inloom’s shared-fields approach gives reusable information a reviewed definition while preserving each document’s wording and purpose. That is the same discipline behind the worksheet above: decide what a value means before mapping it to another destination. The website describes reusing appropriate information through configured connections; it does not establish that every spreadsheet or CRM action is available for every setup.

Book a demo to discuss your source fields, intended outputs and connection requirements.