Make every contact route explicit

A sync rule says when a workflow should run, which contacts qualify, and where each one should go. OpenContact turns that logic into something your team can read, test, and maintain.

Build your first rule · Explore triggers

Three parts, one clear decision

Every rule combines:

1. A trigger — the contact event that starts evaluation.
2. Conditions — the fields, source, status, or verification signals that must match.
3. Destinations — connected providers or OpenContact lists that should receive the contact.

Leave conditions empty for a universal rule, or narrow them around the exact audience and workflow.

Fan out or choose one route

Use send to all when a contact should reach several destinations, such as a CRM and newsletter platform.

Use route to first when destinations represent alternatives. Order the conditions and OpenContact selects the first matching path—for example, one provider for EU contacts and another for US contacts.

Map data for each destination

Translate canonical contact fields into the names each provider expects. Use supported transforms, static values, and defaults while keeping the source record consistent.

Provider resources and fields are loaded from the connection where supported, reducing guesswork when choosing a list or mapping a destination field.

Decide how suppression travels

Enable a global suppression policy when an unsubscribe, bounce, or complaint should propagate to every provider destination in the rule. Use dedicated suppression triggers when the workflow needs more precise conditions.

Test without sending

Dry-run a rule against a real or sample contact before saving. The result shows which conditions match, which destinations would run, and which fields would be sent. No provider data changes during the test.

Next steps

See every trigger · Understand suppression sync · Read the rule guide