Core concepts#

A short tour of the ideas the rest of the docs assume.

The connection is the atom#

Everything in Forgeworks hangs off a connection — an authenticated link to one external system (a Salesforce org, a HubSpot portal, a Stripe account, …). You connect a system once; the products are lenses over that connection. Switch products and you re-frame the same connections, you don't re-authenticate.

Connections are per-tenant and isolated. Credentials are encrypted at rest, never returned by any API, never logged, and scrubbed out of error messages.

Sources and destinations#

Every connector is bidirectional:

• As a source, it captures changes out of the external system and feeds them into Forge Stream (a new contact in HubSpot, a closed deal in Salesforce, an updated ticket in Zendesk).
• As a destination, Forge Load writes records into the system — with a snapshot taken first, so the write can be rolled back.

Pipelines and mappings#

A pipeline moves data from a source to a destination. It has trigger conditions (when it fires), field mappings (how a source field becomes a destination field), and an ordered set of steps. You build mappings visually in the console.

Some pipelines target a workflow instead of a destination system — Deal Desk is one: its "mapping" is the set of deal fields shown on the Slack approval card.

Snapshots and rollback#

Before Forge Load writes, it captures a snapshot of the records it's about to change. If a load goes wrong, one click rolls it back to that snapshot — including recreating deleted records. This is what makes loads safe to run.

Alerts and history#

• History is the who-did-what-when trail across the platform.
• Alerts surface conditions that would otherwise be silent: a re-trigger suppressed because an approval was already in flight, an approval left waiting for days, a dispatch failure, a connector whose auth expired and needs reconnecting.

Note: Read more in Concepts.