A bridge is not limited to one destination. In the builder, click Add a destination app as many times as you need, and each destination becomes its own step in the wizard.
What each destination keeps independently:
- Its own target list, channel, board or webinar.
- Its own action, where the connection supports more than adding to a list.
- Its own field mapping, including name handling, custom fields and tags.
- Its own optional delay, so one destination can fire now and another can fire tomorrow.
A worked example:
A WooCommerce order fires one bridge that does three things at once. Destination one adds the buyer to your autoresponder onboarding list with a custom field recording the product. Destination two posts the sale into a Slack channel so the team sees it immediately. Destination three waits two days, then adds a review request tag on the same autoresponder.
Why fan out beats chaining:
Because all destinations sit on one bridge, they all see the same contact, the same filters and the same source fields. You get one row in the Activity Log with a per destination result, rather than several disconnected bridges that are hard to debug.
Order of delivery:
Destinations without a delay are delivered during the same run. Destinations with a delay are queued and delivered by the poller once they come due, which reuses the identical delivery and logging path, so a delayed destination behaves exactly like an immediate one, just later.
Editing later:
Open the bridge, and every destination step is pre-filled with what you saved. You can change one destination without touching the others, or remove a destination entirely.