Inside this article

Sums, averages, and more
Cells versus rows and columns
Key differences
Transitioning from cell level formulas
Goodbye absolute references

Beyond lists, the next level of Excel skills is using it to perform calculations. Much like the layout, there's a lot that will look and feel familiar, but there are some key conceptual differences that set Coda apart and unlock its possibilities. 

Sums averages and more

In Excel, you can apply all sorts of summary formulas like:

  • SUM ()
  • COUNT()
  • MAX()
  • MIN()

In Coda, we build this in at the bottom of each of your table columns so you can quickly summarize what you need:

You can also customize how and if you want to see this information via the column options menu under Summarize:

Cells versus rows and columns

In Excel, each cell is an independent piece. It's not inherently connected to any other part of your spreadsheet so you make formula calls based on cell locations:

In Coda, the units of measure are rows and columns. Each row acts as a unified element with the items you're tracking and all of the related data about it. In the example below, the item "Research locations" is actually a row with a set of attributes including the due date and status. 

This also means that each column acts as a unit - for example, all the due dates, all the status, all due date minus 7:

Key differences

Build relationships once

In Excel, you need to drag to apply formulas:

In Coda, columns are formatted with intention. You build the formulaic relationships only once. If a column is formulaic, the formula automatically applies to new or updated data:

No need to use $ to create stability

In Excel, you use the $ to create absolute references so that as your data changes, you still maintain the connections you built:

In Coda, you don't need $ because Coda works with the names of the objects themselves. Everything is automatically an absolute reference:

Data with context

In Excel, you need to build connections manually to receive the context of a given cell, but in Coda, the context is automatically part of the reference because columns act as attributes of your row items:

Transitioning from cell level formulas

Situation 1 - "I need a standalone summary formula"

  • You can always type = in the canvas of your Coda doc to summarize table data
  • Remember that at the bottom of every column, you'll have access to a Summarize by menu to Count, Count Unique, Sum, Average, Min, Max, or Mode

Situation 2 - "I don't have the content I need in the table"

  • Create columns for the missing information
  • Hide any columns you like to create a clean look

Situation 3 - "I need to use the same formula frequently"

Goodbye absolute references

Mature Excel docs are, in many ways, unstable. We need to anchor our data via absolute references using "$" otherwise certain changes will make our entire Excel system break down. Coda docs are about growing and flexing with your data, and Coda handles this is by giving everything a name - rows, columns, and more. Because we name everything, everything inherantly becomes an absolute reference. 

For example, if we're tracking  inventory items and their accompanying sale price, I would need to use the absolute references for my monthly discount to create my pricing structure:

In Coda, you work not with the locations that are locked into place, but rather the actual objects:

In the example above, we've added the discount in a dropdown menu and then built our formula around the objects - in this case, the Base Price column and the variable in the multi-select control. As you work on building formulas in Coda, start typing the name of the objects you want to work with, and you'll notice that Coda auto-populates:

Another alternative to your $ usage is naming any of your go-to formulas to make them easier to reference across your Coda doc:

Did this answer your question?