GatherowDecide what one output row means
Start with the question the table needs to answer. Do you need one row per customer, one row per order, or one row per customer-and-region combination? That choice determines the matching and calculation rules.
For a customer overview, a customer sheet can supply names and regions while an orders report supplies amounts. Pick the source that should define the starting records, or choose a grouped summary when your result is one row per matching combination.
A customer with three orders should not accidentally become three copies of every unrelated balance or total.
Choose explicit matching fields
Connect and check each source, then add the fields you need to a table. Match records using an identifier that refers to the same thing in each source—such as customer_id.
When IDs repeat across companies, match on both company_id and customer_id. Gatherow supports up to four matching fields. Every field in the combination must agree.
Names and row positions usually make weak identity rules. Check repeated IDs and unmatched records before treating a relationship as established. In a regular record join, duplicate normalized matching IDs are rejected rather than silently overwritten.
Make cleanup deliberate
Suppose the customer sheet uses 0042 while the orders report uses cust_0042. Apply an explicit rule to remove the exact cust_ prefix from the report’s matching field.
Use trimming or case changes only when those differences are irrelevant to identity. Preserve leading zeros when they are meaningful. A conversion from text to number can change the identity you intended to keep.
Review the matching preview after choosing a rule. These rules affect the result inside Gatherow; they do not modify your original spreadsheet or reporting service.
Summarize repeated records before combining
An orders report often contains several records for a customer. Use Combine & summarize when the output needs totals, averages, minimums, maximums, counts, distinct counts or unique-value lists.
Gatherow groups each source independently before combining the grouped results. This prevents repeated orders in one source from multiplying amounts in another.
Choose whether to return one row per matching combination or keep each starting-source record with group calculations attached. In the latter layout, a group total can appear on several rows as repeated context—it should not be summed again as if each occurrence were new revenue.
Put conditions at the right stage
A source filter selects which records enter the calculation. For example, Status = Completed can exclude cancelled orders before summing revenue.
A result filter applies after the calculation. A condition such as Total > 1000 selects customers by their completed-order total. The two stages answer different questions.
Choose the fields and ordering that make the table useful to its next consumer. If a field contains a delimited list that should become separate records, review the supported split-rows option and check its effect on the table’s row meaning.
Check a result before sharing it
Inspect several recognizable records, including an unmatched record and one with repeated input rows. Check that the total agrees with the intended source records and conditions.
Save the table when the result is correct. Supported saved result cells offer Explain a value to inspect captured source evidence and calculations. Then publish the intended API fields through the separate review flow.
If you use optional AI drafting, establish and save new matching rules manually first. AI can draft supported configurations using existing matching relationships; its output still needs your review and explicit application.