Troubleshooting¶
Common issues and solutions for workflows.
Connection Issues¶
"Could Not Connect" When Testing a Credential¶
- Verify the Server URL includes the database name (for example
https://acme.lime-crm.com/acmedb). - Confirm the API key is correct and has not been rotated.
- Check that the workflow tool instance can reach the Lime CRM server (network/firewall).
401 Unauthorized¶
The API key is invalid or has been rotated. Generate a new key from Lime Admin (System Settings → Security → Users) and update the credential.
403 Forbidden¶
The API key exists but lacks permission for the operation. Check the API user's permissions in Lime Admin — it may need access to additional Limetypes or operations.
429 Too Many Requests¶
You have exceeded the rate limit (3 000 requests per 5 minutes on Lime CRM Cloud). Solutions: - Add a Wait node (5–30 seconds) between batches. - Switch from individual CRUD to bulk operations for large datasets. - Spread scheduled workflows across different hours.
Trigger Issues¶
Workflow Is Active but Events Are Not Firing¶
- Confirm the workflow is toggled to Active (not just saved).
- Check that the correct Limetype and Events are selected in the trigger node.
- Open Executions to see if events are arriving but failing mid-workflow.
- Verify the webhook subscription was created: check the webhook list in Lime Admin.
"Webhook URL Could Not Be Reached"¶
This typically affects on-premises Lime CRM installations. The Lime CRM server must be able to reach the workflow tool over the network to deliver webhook events. If Lime CRM is behind a firewall or VPN, contact your infrastructure team to allow outbound traffic to the workflow endpoint.
Webhook Stops Receiving Events After Working Previously¶
Lime CRM can automatically disable a webhook subscription if deliveries fail repeatedly (for example, if the workflow tool was unreachable). To re-enable: deactivate the workflow and reactivate it — this recreates the subscription. Check the webhook list in Lime Admin to confirm it is active again.
Field in $json.body.body.values Is Null or Empty¶
The trigger payload always includes every field key — a key is never absent. If a field evaluates to null or an empty string in your expression, it simply has no value set on that record in Lime CRM. Check the record directly to confirm, and handle null values defensively: {{ $json.body.body.values.fieldName ?? 'fallback' }}.
Data Operation Issues¶
404 Not Found on getSingleObject¶
The record ID passed to the node does not exist. Common causes:
- The ID comes from the trigger payload ($json.body.body.id) but you are reading from the wrong path.
- The record was deleted before the workflow processed the event.
- You are mixing test and production data.
Check the exact expression: {{ $json.body.body.id }} (note the double body).
Validation Error (400) on Create or Update¶
The payload contains an invalid value for a property. Common causes:
- A date field received a string in the wrong format (use yyyy-MM-dd for dates).
- An option field received a display label instead of the option key. Use getSingleLimetype to inspect valid option keys.
- A required field is missing.
- A relation field received a string instead of an integer ID.
getManyObjects Returns an Empty Array¶
Check:
1. The query filter — a typo in a field name will silently return no results.
2. The limit — the default is 50; if you set 0 it fetches all (auto-batched), not none.
3. The Limetype — confirm you are querying the correct entity.
updateSingleObject Is Not Saving Changes¶
Confirm you are using the correct parameter names for updateSingleObject:
- Parameter: ID (not "Object ID" as used in getSingleObject).
- Parameter: Input type and JSON data (not "Input method" and "Object JSON" as used in createSingleObject).
The parameter names differ between create and update operations — this is a common source of errors.
Bulk Import Issues¶
"Package Not Installed" Error¶
Bulk operations require an additional package to be activated on the Lime CRM instance. Contact Lime support or your instance administrator to enable it.
Bulk Job Succeeds but Records Are Not Created¶
- Check
summary.failedin the output — a non-zero value means some records failed silently. - Verify that
matchingPropertyis set to a field that actually has data in your input. - Confirm that the property names in your input match the CRM property API names (not display names).
"Non-Unique Matching Property" Warning¶
The field used as matchingProperty has duplicate values in the existing data. This means the upsert cannot determine which record to update. Use a truly unique field (for example orgnumber, email) or add a deduplication step before the bulk node.
Automations and Webhooks Are Not Firing after Bulk Import¶
This is expected behavior. Bulk operations bypass the entire application layer including Python logic, Lime Automations, and webhooks. If these must fire, use the individual upsert pattern (Pattern 3) instead.
Expression Issues¶
Expression Shows [Object object] Instead of the Value¶
The value is an object, not a scalar. Use JSON.stringify() to inspect it:
undefined or Empty Value in Expression¶
- Check the output panel of the previous node to confirm the field exists at the path you are referencing.
- Use optional chaining:
{{ $json.body?.body?.values?.name ?? 'fallback' }} - If referencing a previous node by name:
{{ $('Node name').item.json.field }}— the node name must match exactly (case-sensitive).
IF Node Is Not Routing Correctly¶
The IF node evaluates expressions strictly. Check:
- For Lime CRM trigger values, the field key is always present — check for null or empty string rather than undefined: {{ $json.body.body.values.fieldName !== null && $json.body.body.values.fieldName !== '' }}.
- For other paths where a key may genuinely be absent, use {{ $json.fieldName !== undefined }}. An empty string is falsy, so {{ $json.fieldName }} alone will not distinguish between missing and empty.
- Boolean fields in Lime CRM are true/false — not "yes"/"no" or 1/0.
Inspecting and Debugging Requests¶
When a node fails or returns unexpected data, the first step is to see what was actually sent and received. This applies equally to Lime CRM operations and any other system your workflow calls — external APIs, webhooks, third-party services. The workflow tool and browser both expose this information.
Read the Node Output Panel¶
Click any executed node in the canvas to open its Input / Output panel. This shows: - The exact JSON payload that was sent to the Lime CRM API. - The raw response body returned by the server (including error details). - The status code and headers.
This is usually enough to diagnose a 400 validation error or a 404 — the response body contains the specific field or message that failed.
Use the Browser Network Tab for Deeper Inspection¶
When the node output panel does not show enough detail, open the browser developer tools (F12 or Cmd+Option+I) and go to the Network tab before re-running the node.
- Filter by Fetch/XHR to reduce noise.
- Click Test step on the node.
- Find the request to your Lime CRM domain in the list.
- Click it and inspect:
- Headers — verify the
X-API-Keyheader is present and correct (Lime CRM usesX-API-Key, notAuthorization). - Payload — the exact JSON body sent to the API. Compare this against what the Lime CRM API expects.
- Response — the full error message from the server, which may be more detailed than what the node surface shows.
This is particularly useful when you suspect the node is serializing a value differently than expected (for example, sending "true" as a string instead of true as a boolean).
Use the Browser Console to Evaluate Expressions¶
If an expression produces an unexpected value, open the browser console and evaluate it directly:
You can also manually construct the object path from data you copy out of the output panel to verify your expression before putting it back in a node.
Pin Data to Reproduce the Failure¶
If the failure only happens with specific production data, use Pin data on the trigger node:
- Open Executions, find the failed run, and click it.
- On the trigger node, click Pin output data.
- Return to the canvas and click Test workflow — the workflow replays using the exact same payload that caused the failure, so you can iterate on the fix without waiting for the event to fire again.
Call the API Directly to Isolate the Problem¶
When you are unsure whether the issue is in the workflow or in the target system itself, reproduce the call directly from a terminal or the browser console. Copy the URL, headers, and body from the Network tab and run it with curl or a REST client:
# Lime CRM example
curl -H "X-API-Key: <your-api-key>" \
"https://your-instance.lime-crm.com/your-database/api/v1/limeobjects/company/123/"
# Generic POST to a third-party API
curl -X POST "https://api.example.com/v1/contacts" \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{"email": "test@example.com"}'
If the direct call also fails, the problem is in the target system (permissions, invalid data, service outage) rather than the workflow configuration. If the direct call succeeds but the workflow does not, the issue is in how the node constructs the request — compare the two payloads carefully.
General Issues¶
Node Changes Are Not Taking Effect¶
If a workflow is already active, changes to a node take effect on the next execution, not the current one. For test executions, click Test workflow again after saving.
"Test Data" Appears in Production Executions¶
Pinned data (from listening for test events) only applies to test executions. It does not affect production executions. Clear pinned data from the trigger node before activating.
Workflow Runs in Test but Not in Production¶
Common causes: - Credentials set to a test/staging environment in the test but not updated for production. - Webhook URL registered in the trigger points to a test instance. - The workflow is saved but not activated.