Invisible Tech: To Show or Not To Show

Welcome to the Invisible Tech series. This is a space to discuss the concepts and data that are deeply encoded into our technology, but which manifest for the most part in the realm of our imagination. This topic comes up again and again in my work and fascinates me, and I am hoping to find other people who want to engage with me and each other on the interesting questions and philosophies that are part of invisible tech.


A video version of this blog post is available here as well:

Part One:

Today I started with a piece of visible tech, and through a series of questions and decisions I made it disappear into the invisible tech space. I’m not really sure if that was the right thing to do. With technology, there are often many different ways to get to a very similar spot and my guess is that in about 90% of cases where you need to make a technology decision you won’t have a “wrong” choice, although some decisions will likely be more well-advised than others. 

Here is the scenario: In our Salesforce system, we create records for each year a student participates in our program. At the end of each academic year, we update fields that mark a student as having completed the year, and that they are returning for the next school/program year. (Side-convo: Emily, have you heard about PMM yet? Yes, I have, thank you for your concern). When we update a participation record with these values, a Salesforce Flow is initiated. (Side-note: A Salesforce Flow is a series of pre-defined steps that can happen automatically based on criteria of your choosing). The Flow will create a new participation record to reflect the student’s participation the following year - if we didn’t have the Flow, we would need someone to individually or in bulk create the new records and update the field values with the right information each time.

Image of a Salesforce ListView with 2 records in it. Table provided below for screen readers.

Table version for screen-readers:

PARTICIPATION RELATED LIST

Participation Record Name

Program Year

Returning to Program?

Grade in Participation

P-003750

FY21

Yes

6

P-003791

FY22

Null

7

 

We also have a field on the record called “Student’s School” that links to an Account record. Usually we just copy the same value to the same field on the new record created. But last year we introduced a new field for our students who are seniors continuing on to college - “College Attending”. Now instead of just copying the school value from the previous year record, we need to make a decision - if the Grade in Participation is 12th on the previous year record, then instead of copying the same value from the school field onto the new participation record, copy the value that is in the “College Attending” field. Otherwise, if the Grade in Participation is any other year, do what we’ve always been doing - copying the same school from “Student’s School” onto the next year’s record.

Image showing how data is meant to move from one record to the next - table provided below for screen readers.

Table version for screen-readers:

Previous Year’s Record

 

Next Year’s Record

Grade in Participation: 6

 

Grade in Participation: 7

Student’s School: PS1

 

Student’s School: PS1

College Attending:

 

College Attending:

     

 

Previous Year’s Record

 

Next Year’s Record

Grade in Participation: 12

 

Grade in Participation: College, Yr 1

Student’s School: PS1

 

Student’s School: Howard University

College Attending: Howard University

 

College Attending: Howard University

     

 

At first, that seemed like an easy next step - I created the a Decision element in the Flow, and depending on the Grade in Participation it would lead to two different Update Records elements - one that would leave the Student’s School field alone (because we essentially cloned the original record and we want the value to stay the same) and another that would update the Student’s School field to instead match what was in the “College Attending” field from the previous year’s record.

This is a picture of a Salesforce Flow that is Record-Triggered, starts with a Create Records element and moves from there to a Decisions Element. The decision options are “Yes, 12th Grade Record”, “No, Not a 12th Grade Record”, and “Default Outcome”

As I was making the changes to the two different “Update Records” actions, I saw that the person who built the flow (my amazing intern-turned-colleague Jordan) had used some formula fields originally to determine what value the Grade in Participation field would have on the next year’s record (If grade was 6 on last year’s record, then 7, if grade was 7 on last year’s record, then 8, if grade was 8 on last year’s record, then 9, etc etc). Maybe I could be more efficient in my Flow with that approach. Instead of the Decision Element leading to the two different Update Record elements, I wrote a formula that was basically the same concept as the Decision Element, just a little “codier” and less “clicks-not-code”. I’m writing here in English: IF the Grade in Participation on the next year’s record is “College, Yr 1” THEN bring in the value from the College Attending field. If it isn’t, then bring in the value from the Student’s School field. The Decision is hidden inside of a formula which is hidden inside of a variable - which is an invisible container for data. Now the flow looks back to like the way it started, but when the Salesforce automaton is updating the records, the value that gets put in the Student’s School field will be whatever value was calculated by the formula and variable that don’t show here:

This is a picture of a Salesforce Flow that is Record-Triggered, starts with a Create Records element, followed by a Create Records element, then ends.

So where did that Decision go?! You could follow the breadcrumbs here to figure out what was going on. But at first glance, you wouldn’t be able to see that a decision was even needed or that records are being treated differently based on their values. Something that was visible disappeared.

The Flow is better because it uses fewer elements. That is good for processing time and for making changes in the future. I am far from a power user of Flows, but I know and work every day with automated processes and my impression is that it is just better practice as a solutions-builder to calculate what should go in the Student’s School field first and then update the records with that calculation in hand, rather than to do that as part of the elements of the Flow (adding a Decision Element and having two nearly identical Update Records elements). 

But that visual of the decision branches in the Flow really make an impact on me.

A friend once told me that she had begun transitioning some of her work out of spreadsheets and statistical analysis systems and into using the programming language R. She mentioned that one of the benefits is that everything is transparent and “there for the observer to see”. However, her staff members reported feeling less visibility into the work, because they didn’t know R, so they couldn’t see the transparency - it was in fact having the opposite effect.

For someone just dipping their toes into the Flows water, I think the visible tech option is much more digestible and easier to begin to learn what is going on. When we turn tech invisible, we might be getting fancier and prettier and more compact on the tech side, but we might be putting a roadblock in place for someone to better understand how their technology is actually working. At the same time, within the fancy solution there are core database and programming concepts that are super important and everyone should have some understanding of, like variables. The formula in the Flow is determining whether to use the value from the “Student’s School” field OR the “College Attending” field on the new record, and then places that value in an invisible temporary container called a variable. In this case, I named my variable “SchoolForNextYear”. That variable doesn’t exist on a record, you can’t see it filled in anywhere with the right option, it is this invisible concept that we need to hold in our imaginations and make real there, so that we can use it to help us get to where we want to be.

What do you think?

I often encounter these aspects of and questions about invisibility in data & tech in my work with non-profits. How much should we consider the learning & development of our colleagues in this work when we are creating our solutions? Certainly we don’t all have to create beautiful Flows or even crappy ones - but in order to reap the benefits of how technology can support mission-driven work, people of all backgrounds and roles in non-profits should be empowered to be on a learning journey with their technology. And we all have a great opportunity and responsibility to support each other’s learning and skill-building in technology to allow us all to better use the tools we have available for achieving our missions.


Previous
Previous

Surfing with Zapier, Part 2: The Integration Wave

Next
Next

Surfing with Zapier, part 1