Recursive record-triggered flow loops
Key Takeaway
A chain of record-triggered flows runs in one transaction and shares one set of governor limits (per-transaction resource limits). If an element pushes the transaction past a limit, the entire transaction rolls back.
A record-triggered flow runs when a record is saved. If that flow saves records itself, those saves can start more automation, including other record-triggered flows. A runaway chain or loop can use up the limits and roll back all of the work, so app builders need to design flows that avoid extra saves and know how to trace the problem when it happens.
How flow chains form
A record-triggered flow runs inside the transaction that saved the record. If the flow runs a DML operation, that operation sends the affected record through the save procedure. That save runs the automation on the record's object, so one record-triggered flow can trigger other record-triggered flows, which can trigger more. Everything in this chain runs in one transaction.