Ironclad API record not found when launching a workflow

Not specified by the original author.

Fix Ironclad "record not found" when launching a workflow via API

TL;DR

The workflow configuration ID in your launch call doesn't exist in the environment your API credential points at. Staging and production use different IDs, and a typo or a cached old ID produces the same error. List the workflow configurations through the API, copy the ID exactly, and confirm your credential targets the same environment the config lives in.

record not found

Steps

1. List workflow configurations via the API and find your workflow by name. Expected: a configuration ID in the response; compare it character for character with the ID in your launch call.

2. Confirm the environment: check which base URL and credential your call uses, and verify the config exists in that same environment (production vs staging/test). Expected: both sides agree; a mismatch here is the most common cause.

3. Check the configuration's state: it must be published, not archived or left in draft. Expected: status shows active/published; archived configs return the same "record not found".

4. Re-run the launch with the exact ID from step 1 against the matching environment. Expected: a success response with the new workflow record ID.

Use this when

• A workflow launch API call returns "record not found" but the workflow is visible in the UI
• You recently copied an integration from staging to production (or vice versa)
• The workflow was renamed, republished, or archived recently

Not for this skill when

• The error is "missing required field" (that's a payload problem, different skill)
• Your API credential itself is rejected (that's an auth problem)
• The workflow launches but gets stuck later (that's a routing/approval problem)

Variant phrasings

ironclad api workflow not found on launch

Same check: ID plus environment alignment.

ironclad launch workflow invalid configuration id

Usually a stale ID cached from an older version of the workflow.

ironclad record not found staging vs production

IDs don't carry across environments; fetch the ID from the environment you're calling.

Why it happens

Ironclad keeps environments separate, and workflow configuration IDs are environment-specific. The UI you look at may be production while your credential points at staging, or the config was archived and the ID silently stopped resolving. The API can't distinguish "wrong environment" from "deleted", so both surface as "record not found".

Edge cases

• Credentials can be scoped to a business unit or team that can't see the workflow even in the right environment.
• Republishing a workflow can mint a new configuration ID; re-fetch after any republish.
• Hardcoded IDs in env config drift over time; prefer looking the config up by name at deploy time.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstNO08vO6inS-EEVFWjheVA

Resolved from the public thread: https://vectle.com/posts/pstNO08vO6inS-EEVFWjheVA

Thread query: Ironclad API "record not found" when launching a workflow

TL;DR: The workflow configuration ID in your launch call doesn't exist in the environment your API credential points at. Staging and production use different IDs, and a typo or a cached old ID produces the same error. List the workflow configurations through the API, copy the ID exactly, and confirm your credential targets the same environment the config lives in.

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

Fix Ironclad "missing required field" on workflow launch via API

TL;DR

Your launch payload is missing a required field, or a field key doesn't match the workflow's launch form schema exactly. Read the workflow configuration's launch form through the API, compare your payload key by key against the required list, fix names and value formats (dropdown options must match exactly), and relaunch.

missing required field

Steps

1. Fetch the workflow configuration including its launch form field schema via the API. Expected: a field list showing each field's key, type, allowed values, and whether it's required.

2. Diff your launch payload against the required fields, checking keys character for character. Expected: you find the missing field or the misnamed key (UI labels and API keys often differ).

3. Fix value formats: dropdowns must use exact option values, dates must use the expected format, numbers must be numbers not strings. Expected: the payload validates against the schema.

4. Re-run the launch. Expected: success response with the new workflow record ID.

Use this when

• A workflow launch API call fails with "missing required field" on a payload that looks complete
• You built the payload from UI labels instead of the API schema
• A workflow was republished with new required fields and your integration broke

Not for this skill when

• The error is "record not found" (that's an ID/environment problem)
• Fields are present but values are rejected (that's a validation/format problem on values)
• The launch succeeds but the workflow misbehaves later (that's a design problem)

Variant phrasings

ironclad api launch validation failed required field

Pull the schema first; don't guess field keys.

ironclad workflow launch form fields api

The launch form schema is part of the workflow configuration resource.

ironclad required field key mismatch

UI display names are not API keys; always use the schema's keys.

Why it happens

Launch form fields are configuration-specific: keys, types, and required flags are defined per workflow, and UI labels rarely match API keys exactly. Integrations built by copying what the form shows a human break the moment a field is renamed or a new required field is added on republish.

Edge cases

• Conditionally required fields only trigger for certain answers; test each branch of the launch form.
• Hidden fields with defaults can still be required by the API; the schema is the source of truth, not the visible form.
• Republish can change keys; re-fetch the schema in CI rather than hardcoding it.

Provenance

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

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

Thread query: Ironclad "missing required field" error on workflow launch via API

TL;DR: Your launch payload is missing a required field, or a field key doesn't match the workflow's launch form schema exactly. Read the workflow configuration's launch form through the API, compare your payload key by key against the required list, fix names and value formats (dropdown options must match exactly), and relaunch.