Common Issues & Troubleshooting

Quick troubleshooting guide for common operational scenarios across permissions, CSV imports, automations, AI Assistant prompts, and inbound endpoints.

🔍 Diagnostic Checklist

1. “No Access” / Permission Errors

Symptom: Red error toast or No Access screen when opening a section.
Resolution:
1. Verify you are in the correct Project Workspace (use project switcher top left).
2. Confirm your user account role has permissions enabled for that module under Roles & Permissions → Settings.
3. Check if specific Template Restrictions or Attribute Restrictions under Resources are denying access to target items.

2. CSV Import Failures

Symptom: Import modal reports failed rows or skipped entities.
Resolution:
1. Export a fresh CSV from the template entity list to verify standard column headers.
2. Check row-level error breakdown in the import result dialog. Common issues include invalid List options or malformed date strings (YYYY-MM-DD).

3. Automation Rule Not Triggering

Symptom: Attribute value changes, but no Telegram message or Webhook POST occurs.
Resolution:
1. Open the automation’s Executions tab to view execution logs.
2. Verify the Trigger Condition (e.g. On Attribute Changed requires an actual value delta).
3. Check who made the write: changes made by another automation never fire On Entity Created, On Entity Updated, On Attribute Changed or On Action Executed automations.
4. Open Notification Channels and click Run Test to verify third-party credentials.

4. Automation Did Not Fire at the Expected Time

Symptom: A schedule, When Date Reached or No Change Within automation ran at the wrong time or not at all.
Resolution:
1. Check the trigger’s Timezone. A date without a time counts as midnight in that timezone, and the offset is applied on the calendar from there.
2. Open the record and look at Scheduled Automations. A moment that was already in the past when the date was set is never scheduled.
3. Remember that conditions are checked when the automation fires, against the record as it is then. A record that no longer matches is skipped.
4. For No Change Within, records that existed before the automation was created are only watched from their next write.
5. If the automation’s own action changed the date or watched attribute, its pending run was dropped on purpose; an automation never re-arms itself.
6. A schedule that matched more than 500 records is refused as a whole; narrow its conditions.
7. A run that came due during downtime fires once, late, and is marked fired N min late in the execution log.

5. Webhook or HTTP Request Action Fails

Symptom: The execution log shows a failed Send Webhook or HTTP Request action.
Resolution:
1. Target resolves to a private network address: automations cannot call localhost or private network ranges. Use a public, authenticated URL.
2. A response mapping path did not resolve: the API answered, but one JSONPath found nothing, so the whole action wrote nothing. Expand Response on the execution to see what came back, then fix the path, or remove that row if the API does not always return the field.
3. A rule violation on the mapped or written values: the record was left untouched; the message names the attribute.
4. Non-2xx status or timeout: check the channel’s base URL and credentials, and raise Timeout (up to 30 seconds) for slow APIs.

6. AI Assistant Request Fails / Times Out

Symptom: AI Assistant chat shows a red error response or battery indicator is low.
Resolution:
1. Check your available AI credits indicator in the Assistant toolbar.
2. Simplify your prompt to a single actionable outcome.
3. Verify your active session has write permissions for the requested template/entities.

7. Inbound Endpoint Rejects Deliveries

Symptom: The sending system reports errors, records do not appear, or the endpoint shows a Signature failing badge in the template’s Inbound tab.
Resolution: Check the HTTP status the sender received, and open the endpoint’s Delivery log (401, 422, quota 429 and partial deliveries are logged there; 404, 413 and rate-limited requests are answered before they reach an endpoint, so only the sender sees them). By status:
- 401 — the signature did not verify. The row’s reason tells you why:
  - does not match: the sender signs with a different secret, or the endpoint has the wrong sender preset or header. Paste the sender’s current signing secret with Add secret, then remove the old one.
  - outside the replay window: a timestamped sender (Stripe, Standard Webhooks) signed more than 5 minutes before or after the delivery arrived. Check the sending machine’s clock.
  - no signature / not in the expected shape: the header is missing or named differently, e.g. a Secret header sender that does not send X-Omnismith-Secret.
- 404 — the URL is wrong, the endpoint is disabled (Accept deliveries is off), or it was deleted.
- 422 / Partial — the payload reached the mapping but some records could not be written. Select the row: Record errors names each failing record and field — an unknown list label, a reference key no record holds, a value of the wrong type, or a template rule. Fix the mapping (try it first with Preview and Use a recent delivery) or the template, then click Replay.
- 429 — the endpoint received more than about 10 deliveries per second, or a plan quota is exhausted. The sender should retry later; check Billing and Usage for quotas.
- 413 — the body is over 1 MB; split the payload.
Duplicate metric readings: if a sender retries a delivery that was already processed and the endpoint has no Delivery id configured, the retry is processed again and metric readings are recorded twice. Set the delivery id source to the sender’s event id. See Inbound Endpoints.

Troubleshooting signal summary interface