A network gives your workflows a controlled path to systems that aren't sitting on the open internet. By default, a step's requests go straight out to public services. When a step needs to reach a database behind your firewall, an internal API, or a service that only trusts traffic from a known address, a network is how that traffic gets there.
Reaching what's off the open internet
Most connectors talk to public APIs, and those need nothing special. Networks exist for the cases that do:
an internal tool on your private network
a system that isn't exposed to the internet at all
a destination that only accepts requests coming from an address it recognizes.
A network is the bridge between Tines 3B's sandboxed execution and those otherwise-unreachable systems.
The common shape is a tunnel: a small gateway you run inside your own environment that Tines 3B connects to. Requests bound for your internal systems travel through that tunnel instead of out the front door, so your workflows can reach private destinations without you opening them to the world.
Routing by destination
A network is defined by its destinations, the addresses reachable through it, written as IP ranges or hostname patterns. That list is what makes routing automatic. When a step sends a request, Tines 3B looks at where it's headed: if the destination matches one of a network's routes, the traffic goes through that network; if it matches nothing, it takes the normal path to the public internet.
This is worth stressing, because it's different from connectors: you don't point a step at a network. Networks are ambient. A step just makes its request, and the routing table decides the path based on where the request is going. Add a destination to a network and any step reaching that destination starts using it, with no change to the step's code.
A shared resource, governed by access
Networks are one of Tines 3B's shared resources, so access to them is controlled the same way as spaces and connectors, with roles for viewing, editing, and using. Using a network is a distinct permission, and it interacts with spaces: a space can route traffic through a network only when the people who run code in that space are also allowed to use the network. That keeps routing honest, so a workflow can't quietly send traffic somewhere its space members aren't permitted to reach.
Read about how access control works here.
When a space isn't allowed to use a network it would otherwise reach, routing fails closed. Rather than falling back to sending the request straight out to the internet, Tines 3B blocks those destinations. Losing access to a network stops the traffic instead of leaking it.
Enforced routes as a guardrail
Some destinations shouldn't be reachable any other way, and for those a route can be marked as enforced. An enforced route takes precedence, forcing matching traffic through its network as a guardrail rather than a preference. Turning enforcement on or off is a tightly held tenant-level power, so this is a control administrators use to guarantee that certain traffic always takes the intended path.
Where networks fit
Networks are set up and managed at the tenant level, since they usually involve infrastructure like a gateway you provision. Once a network exists and a space is allowed to use it, everything downstream is automatic: the routing happens at Tines 3B's egress boundary, the same place that injects connector credentials and blocks unsafe destinations. So networks slot into the request path your steps already use, extending where those requests are allowed to go.
