Unsubscribe runs one set of actions; one that lands in Left Company runs another.
Available action types
Sync Contact to Eloqua

- Static values — e.g.,
leadStatus = Subscriber - Dynamic values — tokens that resolve at runtime from Mary’s classification or extracted data, e.g.,
leadStatus = [allGood] {{ classification }}
| Mode | Behavior |
|---|---|
Create or Update | Update the contact if it exists, otherwise create it (the safe default) |
Create Only | Create a new contact; fail if one already exists for that email |
Update Only | Update an existing contact; fail (or skip) if no contact is found |
| Token | What it resolves to |
|---|---|
{{ classification }} | The category Mary assigned (e.g., Unsubscribe) |
{{ rationale }} | Mary’s plain-English reasoning for the classification |
{{ from.address }} | The sender’s email address |
{{ from.name }} | The sender’s display name |
{{ extractedFields["<field>"] }} | Any field defined in Data Extraction for that category |
Add to Eloqua Shared List

Unsubscribe in Eloqua

isSubscribed = false). This is the cleanest way to honor an opt-out, because it uses Eloqua’s native subscription status rather than just flipping a custom field.
If the contact isn’t found in Eloqua, this action skips quietly by default. You can flip this behavior with the skip if not found toggle if you’d rather treat a missing contact as a hard error.
Example: Unsubscribe actions

Unsubscribe category would run:
Unsubscribe in Eloqua
Honor the opt-out using the Unsubscribe in Eloqua action so the suppression is respected everywhere
Sync Contact to Eloqua
Record the reason on the contact for the audit trail. Using
Create or Update mode also guarantees the contact exists before the later steps run.| Field | Value |
|---|---|
leadStatus | Unqualified |
allgoodReason | [allGood] {{ classification }}: {{ rationale }} |
{{ rationale }} token is particularly useful here — it gives your ops team a human-readable audit trail directly on the contact record explaining why Mary marked someone as unsubscribed.
Stacking and reordering actions
You can configure multiple actions per category, and they run in the order they’re listed. Use the up/down arrows on each action row to reorder them. Click + Add Action to add more. Order matters in two cases:- Dependent actions. If an
Add to Shared Listdepends on the contact existing, putSync Contact to Eloqua(inCreate or Updatemode) first. - Field dependencies. If a later action references a field set by an earlier action, make sure the order reflects that dependency.
Conditional actions
Every action supports an only-if condition — a token expression that must evaluate totrue for the action to run. This lets you fan out behavior within a single category. For example, only add to a “Hot Leads” list when an extracted intent field is high, while still running the rest of the chain for everyone.
Actions that look a contact up by email also expose a skip if not found toggle, which controls whether a missing contact is treated as a quiet skip or a hard error.
Best practices
- Use the
[allGood]prefix in audit fields. Following the example above (allgoodReason = [allGood] ...) makes it easy to see at a glance which records were touched by Mary versus a human or another system. - Use field internal names, not labels. The field map keys must be Eloqua’s internal contact field names, not the friendly labels shown elsewhere in the UI. A field name that doesn’t exist will fail at execution time.
- Prefer the native unsubscribe. For opt-outs, use Unsubscribe in Eloqua rather than just setting a custom field — it updates Eloqua’s subscription status so suppression is honored everywhere.
- Test the full chain, not just the classification. The Test Suite validates categorization and extraction; once those pass, sanity-check the actions in a sandbox Eloqua instance before going live.
- Watch the order when adding to lists. Most shared-list add failures we see are contacts that didn’t exist yet. Lead with a Sync Contact to Eloqua in
Create or Updatemode to be safe.