Loading
These are platform capabilities, so they behave the same way in every product rather than being configured separately in each.
An automation can be triggered by a stage change in Flow and act in Loop and Books, because all three read the same record. There is no connector to configure, no API credential to rotate, and no partial failure where one system moved and the other did not.
Some hand-offs stay human on purpose. As a rule: if a customer would find the error, a person should approve it. Automations that draft an email or propose a price change surface a suggestion rather than sending it.
Triggers are record events rather than product events: a stage change, a field crossing a threshold, a date arriving, a document being approved, a record being created by anybody through any route. Because the record is shared, a trigger defined once catches the change whether it came from a person in the interface, an import, the API or another automation.
An action can create or update anything the acting user could create or update by hand — automations run under a permission scope rather than as an unconstrained system account. That constraint is deliberate: an automation that can do more than its author can do is a security hole that looks like a feature.
Automations run in a defined order and a failure stops the chain rather than half-applying it. On a stack of integrated tools this is the hardest thing to guarantee, because each system commits independently and a failure halfway leaves two systems disagreeing. Sharing a record turns that from a distributed-systems problem into a transaction.
Yes — an automation can be run against past records to show what it would have done before it is switched on.