A NAMED SEQUENCE OF STEPS, TRIGGERED BY SOMETHING. Why it is A FIRST-CLASS THING YOU DESIGN rather than GLUE BETWEEN COMPONENTS.
Module 2 named action chains as one of the four things you will live in. This module is about them, and the framing in this title is what decides whether an application stays maintainable.
WHAT IT IS: A SEQUENCE OF STEPS, WITH A NAME, THAT SOMETHING STARTS. A button, a page loading, a value changing. The steps run in order, they can branch, and they can call services and set variables. That is the whole of the behaviour layer of every application in this course.
THE TEMPTING VIEW IS THAT A CHAIN IS PLUMBING — the wiring that gets a value from a service into a table. Under that view a chain is written per button, named after the button, and never read again. Which is how you arrive at forty chains that each do a version of the same thing slightly differently.
THE USEFUL VIEW IS THAT A CHAIN IS THE UNIT OF BEHAVIOUR, AND IT HAS A NAME BECAUSE IT IS A THING. "Save the customer" is a chain. It is called by a button today, and might be called by a keyboard shortcut, a second page, or another chain tomorrow — and none of that requires rewriting it.
SO THE NAME SHOULD DESCRIBE THE BEHAVIOUR, NOT ITS TRIGGER. saveCustomer, not button3Click. That single habit is what makes a chain reusable, findable and readable — and the tool's default name is always the trigger, so this is a deliberate act every time.
AND IT IS WHY THE REST OF THIS MODULE EXISTS AT ALL. If a chain were plumbing, questions about failure, size, readability and reuse would be pedantry. Because it is where the logic lives, those are the questions that decide whether somebody else can change this application — which is the maintenance bill Module 1 said is the whole cost of this product.