If we zoom out, a process is just an ordered series of changes made to a data set. When process mapping in preparation for a new Coda doc, it’s vital to have a crystal clear understanding of your data points and how they change thorough your process. This level of granularity is needed to create the tables, columns, automations and notifications that will run your process in Coda.
Now that we know the outline and sequence of how things will be done, we will focus in on each process step and get very specific about what is happening, who is doing it, and what they need to achieve it.
A single step in a process is a set of interactions with a set of data points. These interactions may performed by one or more individuals.
There are 4 ways one can interact with a data point:
➕ Create: Adding a value to a data point when no value was previously specified.
✏️ Update: Changing the value of a data point that had a previously specified value.
👀 View: Looking at or referencing the value of a data point.
📣 Notification: Alerting another person to the value or change in value of a data point.
How detailed should you be?
As detailed as possible. You want to identify every field that will be used in every step.
To illustrate, let’s take the action of adding a task to a task table. Under ➕ Create, you’d list the task name, but you’d also add any other fields are preset for the task, like status, owner, date created, due date, etc. Each of those additional fields for the task would be added as their own row.
Here is another example, later on in the task management process. That same task is now ready for manager approval. In the approval step, the manager uses several fields. They will 👀 View task name, task status, owner, and any other field that is useful for evaluating a task. They will also ✏️ Update the task status field when they approve the task.
This seems like a lot of work. . . is this level of detail actually necessary?
Listing out every single piece of information used in a process may seem tedious, but its essential for building workflow solutions. These details will be used to create the tables, columns and automations of your eventual doc. Knowing who uses what data when will also allow you to set up dashboards and views created specifically for each contributor, showing them only what they need to see, when they need to see it.
This level of detail is also inevitable; identifying data interactions/fields isn’t a task that just “goes away” if you choose not to think about it now. Eventually, you’ll have to identify what columns you’re adding to your tables, align on who is responsible for updating each one, when, and who needs to see what to do their jobs. If you put the effort in now, you’ll know exactly what columns to add to your tables, making the actual build process a breeze.
Objectives
Identify what information/data fields are manipulated and referenced in every step of a process
