Ironclad workflow failed to trigger on the Salesforce event - how to fix

TL;DR

An Ironclad workflow that never triggers from a Salesforce event is almost always an integration or mapping problem, not a workflow bug: the Ironclad connected app lost authorization, the launch event mapping points at the wrong object or field, or the record does not meet the workflow's launch conditions. Verify the Salesforce connection is still authorized, check the event-to-workflow mapping, and test with a record you know meets the conditions. Launch conditions are evaluated before anything runs, so a silent non-launch means the event never qualified.

The query

Ironclad workflow failed to trigger on the Salesforce event  -  how to fix

Use this when

• A Salesforce event (new opportunity, status change) should launch an Ironclad workflow but nothing happens
• The workflow launches from manual or API triggers but not from Salesforce
• Launches stopped working after a Salesforce admin change or a user deactivation

Not for

• Workflows that launch but then stall mid-approval - that is a workflow routing problem, not a trigger problem
• API-launched workflows failing with field errors - those reach Ironclad and fail there
• Salesforce flow errors unrelated to Ironclad - check the Salesforce debug logs first

Steps

1. Confirm the Ironclad Salesforce connection is authorized

In Salesforce, check the connected app / named credential Ironclad uses and confirm the OAuth is still valid. Connections installed by a user who was later deactivated silently break. Re-authenticate as an active integration user and confirm the connection test passes. Expected output: the connection test succeeds and shows the expected Ironclad environment.

2. Check the event-to-workflow mapping

Open the Ironclad launch configuration for Salesforce and verify which object and event (create, update, field change) maps to which workflow. A mapping pointed at the wrong object, or at a sandbox object after a refresh, fires on events you are not watching and ignores the ones you are. Expected output: the mapping names the exact object and event your test record produces.

3. Test the launch conditions against a real record

Workflows have launch conditions (record type, amount threshold, region). Pull the record that should have triggered and evaluate each condition by hand. The most common miss is a picklist value that changed in Salesforce but not in the Ironclad condition. Expected output: every condition evaluates true for the test record, or you find the one that does not.

4. Check Ironclad's launch and run history

In Ironclad, look at the workflow's run history and any launch-attempt log. Rejected launches (failed conditions, mapping errors) are recorded even when nothing visible happens. The rejection reason tells you whether the event arrived and was filtered, or never arrived at all. Expected output: either a rejection entry naming the cause, or no entry - which points back at Salesforce delivery.

5. Fire a controlled test event end to end

Create a test record that meets every condition and watch both sides: the Salesforce outbound event and the Ironclad run history. If the event fires in Salesforce but Ironclad shows nothing, the break is in delivery; if Ironclad shows a rejection, the break is in mapping or conditions. Expected output: a workflow run appears in Ironclad tied to the test record.

Tool compatibility

Ironclad workflow automation with the Salesforce integration (connected app / named credential). Applies to launch-on-event configurations; the debugging path is the same for other CRM triggers.

Variant phrasings

• Ironclad workflow failed to trigger on Salesforce event
• Ironclad Salesforce integration not launching workflow
• Salesforce event does not start Ironclad workflow launch conditions
• Ironclad connected app Salesforce authorization expired workflow not triggered

Why it happens

Event-driven launches have three independent gates: the event must be delivered (connection healthy), it must be routed (mapping correct), and it must qualify (conditions met). A failure at any gate is silent by design - Ironclad does not spam you for events that simply do not qualify. That silence is what makes a mapping or condition drift look like the integration is broken when it is actually filtering correctly.

Edge cases / pitfalls

• Salesforce sandbox refreshes invalidate the connected app mapping - re-link after every refresh.
• Bulk data loads can fire thousands of events; check whether a flood guard or duplicate rule swallowed yours.
• Field-level security can hide the triggering field from the integration user, making conditions silently false.
• Time-based Salesforce flows fire on their own schedule - confirm the event actually fired before debugging Ironclad.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstBMuxC0ODv22BuJQoOPA4A