Changelog

What's New

• A new Fetch from URL link above the Domain field, and a separate one above the Location ID field
• Each one reads the corresponding value directly from the URL of the tab you're on and fills in that field
• Works for agency and sub-account setup — switch to a different sub-account tab and fetch again to pull in its Location ID

Why It Matters

• Removes manual copying and pasting for both fields
• Makes it easier to switch to a second sub-account and fetch its details once you've already onboarded the first
• Cuts down the risk of a mistyped or mismatched Location ID sending you to the wrong sub-account's checklist

What's New

• After a successful profile fetch, the action automatically updates the contact with the retrieved data: photo, headline, summary, field IDs, connection status, and more
• Updates use the same field mappings already set in the LinkedIn settings panel — nothing to reconfigure
• No changes to the action's inputs, outputs, or how it runs in a workflow — previously, the action fetched profile data and returned it to the workflow but never touched the contact record; this write-back is the only change

Why It Matters

• Removes the Update Contact step most workflows had to add manually after every profile fetch
• Contact records stay current the moment a profile is retrieved, with zero added workflow logic
• Existing workflows keep working exactly as they do today — the update happens automatically alongside the fetch

Read the Retrieve User Profile documentation

What's New

• Three new fields on the trigger payload: is_relationship, invitation_status, and network_distance (returns FIRST_DEGREE for new connections)
• A non-blocking write-back: if a contact was matched, the trigger now stamps that record after it sends — Is Connection → true, Invitation Status → cleared, Network Distance → FIRST_DEGREE
• Previously, the trigger fired and stopped there — the matched contact was never touched, and every workflow had to add its own Update Contact step to record the connection

Why It Matters

• One less step in every New Connection workflow — connection status lands on the contact automatically
• The write-back runs after the trigger sends, so it never adds delay or blocks the rest of your workflow
• The new payload fields give you connection context — relationship status, invitation state, network distance — without a separate lookup

Read the New Connection documentation

What's New

• Faster message delivery — a rebuilt messaging system with real speed and scalability improvements
• Built for what's next — new infrastructure laying the groundwork for future capabilities, including multi-account support and read receipts
• Outbound messages sent from LinkedIn now sync automatically — send a message from LinkedIn directly and it now appears in the conversation thread in your CRM

Why It Matters

• A faster, more scalable messaging system keeps your CRM conversations in step with what's actually happening on LinkedIn
• Every message now gets added to the conversation whether it was sent via a workflow, the message composer or LinkedIn itself.
• This groundwork sets up bigger things — multi-account support read receipts, message editing and deletion.

What's New

• Workflow actions now log three stages: Request (what was sent from your workflow), Response (what came back from the provider), and Returned (what was passed back to your workflow)
• Workflow triggers log two stages: Response and Returned, since triggers don't send an outbound request
• Status indicator on every stage — green for a successful (200) response, red if that specific stage failed
• Each stage is expandable, so you can inspect the exact payload sent or received at that point

Why It Matters

• Pinpoint exactly where a failure happened — the request, the provider response, or what came back to your workflow — instead of guessing from a single pass/fail result
• Confirm what was actually sent and received at each step when a workflow doesn't behave as expected
• Faster troubleshooting means fewer support tickets and quicker fixes when something goes wrong

Overview

When an action fails for a small, transient reason — a temporarily disconnected account, a provider hiccup — you no longer have to re-trigger the contact from the top of the automation. Open the failed action, hit Retry, and it's requeued and re-attempted on the spot.

What's New

• Retry button on failed workflow actions — available at the bottom of each failed action in the Activity Logs
• Instant requeue — the activity is re-attempted immediately and the result updates in the log
• No workflow re-run required — recover a single failed action without re-triggering the contact through the whole automation
• Clear success/fail result — see straight away whether the retry succeeded

Why It Matters

Some failures aren't your workflow's fault. An account drops its provider connection for a moment, or a request times out — the setup is fine, the timing just wasn't. Before, recovering meant re-running the automation. Now it's one click.

• No more re-triggering a whole workflow to recover one failed action
• Triggers contacts to progress through workflow when stuck waiting for a response.

Overview

You no longer need a separate Update Contact action after every Send InMail. As long as your Chat ID field is mapped (it already needs to be), the action handles it for you.

What Changed

Chat ID written to the contact automatically

When the action runs, the returned Chat ID is written to the mapped Chat ID custom field on the contact — no extra workflow step required. That keeps contact lookups and reply-to-last-message logic working without any manual wiring.

No more Update Contact action after Send InMail

Workflows that previously included an Update Contact step to map the Chat ID onto the contact can drop that step entirely. The action now handles it directly.

Why This Matters

• Fewer actions per workflow
• No manual Chat ID handling
• Reliable contact lookup and message threading on follow-ups
• Cleaner InMail automations

How to Update Your Workflows

1. Confirm the Chat ID field is mapped in your CRM at App Marketplace → Installed Apps → LinkedConnector (this is a required mapping, so it should already be in place — just double-check)
2. In your existing InMail workflows, delete any Update Contact actions that were storing the Chat ID after Send InMail
3. Save and publish

From the next InMail onward, the Chat ID will be written to the contact automatically.

Overview

You no longer need a separate Update Contact action after every Send A Message. As long as your Chat ID field is mapped (it already needs to be), the action handles it for you.

What Changed

Chat ID written to the contact automatically

When the action runs, the returned Chat ID is written to the mapped Chat ID custom field on the contact — no extra workflow step required.

No more Update Contact action after Send A Message

Workflows that previously included an Update Contact step to map the Chat ID onto the contact can drop that step entirely. The action now updates the field directly.

Consistent behavior across conversations and workflows

We already update the Chat ID on contact records during normal LinkedIn conversations. Send A Message now follows the same behavior, so the field stays accurate regardless of how the message originated.

Why This Matters

• Fewer actions per workflow
• No manual Chat ID handling
• Cleaner messaging automations
• Contact records stay in sync with every outbound message

How to Update Your Workflows

1. Confirm the Chat ID field is mapped in your CRM at App Marketplace → Installed Apps → LinkedConnector
2. In your existing messaging workflows, delete any Update Contact actions that were storing the Chat ID after Send A Message
3. Save and publish

That's it. From the next send onward, the Chat ID will be written to the contact automatically.

Overview

You no longer need a separate Update Contact action after every invitation. As long as your advanced fields are mapped, the values flow through in the background.

What Changed

Invitation status and ID written automatically

When the action runs, the backend updates the contact's Invitation Status and Invitation ID custom fields directly — no extra workflow steps required.

New field to map: Invitation ID

The Invitation ID field is a new addition to the advanced field mapping. Map it once and every subsequent invitation will populate it on the contact record.

No more Update Contact action after Send Invitation

Workflows that previously needed an Update Contact step to store invitation data can now drop it. The action takes care of writing the values for you.

Why This Matters

• Fewer actions per workflow
• No manual handling of invitation status or ID
• Cleaner outreach automations
• Contact records stay accurate without extra wiring

How to Set It Up

1. Open your CRM and head to App Marketplace → Installed Apps → LinkedConnector
2. Open the Advanced Fields mapping
3. Make sure every field is mapped — and confirm Invitation ID is mapped (this one is new)
4. Save the mapping
5. In your existing invitation workflows, delete any Update Contact actions that were storing Invitation Status or Invitation ID — the action handles both now
6. Save and publish

Once mapped, every contact that runs through Send Invitation will have Invitation Status and Invitation ID updated automatically.

Overview

The trigger now passes the Contact ID directly. Your downstream actions can find the sender straight from the trigger output — no separate Provider ID and Chat ID lookup needed.

What Changed

Contact ID now flows through the trigger

The backend resolves the Contact ID from the inbound message and passes it into the trigger output. Workflows can wire Find Contact by Contact ID directly off the trigger.

Provider ID and Chat ID lookup handled in the backend

Previously, workflows needed one lookup by Provider ID with a fallback by Chat ID for redundancy. That logic now lives on our side. The trigger output gives you a single Contact ID to work with.

Wait step no longer required

The 15-second wait that previously sat between the trigger and the contact lookup is no longer needed.

Why This Matters

• Fewer actions per workflow
• No 15-second delay before lookup
• Cleaner, more maintainable V5 (and earlier) workflows
• Faster end-to-end execution

How to Update Your V5 Workflow

1. Open your existing New Message workflow
2. Delete the old Provider ID lookup and the Chat ID fallback lookup
3. Add Find Contact, change the reference field to Contact ID
4. Map Contact ID from the New Message trigger
5. Save the action, then move Find Contact directly under the trigger
6. Delete the 15-second wait step
7. Save and publish

If Provider ID or Chat ID aren't mapped yet, head to LinkedConnector → Getting Started → Map Fields and reconnect both before publishing — the backend uses them to resolve the Contact ID.

Overview

The trigger now passes the Contact ID directly, so your downstream actions can look up the contact straight from the trigger output — no separate Provider ID and Public ID resolution needed.

What Changed

Contact ID now flows through the trigger

The backend resolves the Contact ID from the new connection and passes it into the trigger output. Workflows can wire Find Contact by Contact ID directly off the trigger.

Wait step no longer required

The 15-second wait that previously sat between the trigger and the contact lookup is no longer needed.

Provider ID and Public ID still required as backup

Behind the scenes, the lookup uses Provider ID first and falls back to Public ID. Make sure both fields are mapped in Map Fields so the Contact ID resolves correctly.

Why This Matters

• Fewer actions per workflow
• No 15-second delay before lookup
• Cleaner, more maintainable V5 workflows
• Faster end-to-end execution

How to Update Your V5 Workflow

1. Open your existing New Connection workflow
2. In Find Contact, change the lookup field to Contact ID
3. Map Contact ID from the trigger
4. Save the action, then move Find Contact directly under the trigger
5. Delete the 15-second wait step
6. Save and publish