Troubleshooting and support

For

Everyone

Owner

Customer operations

Outcome

Identify the failure state, recover safely, or contact support with useful evidence.

Last verified

2026-08-30

Next review

2026-11-28

Status

supported

Customer journey

Monitor and recover

Estimated time

10 min

Permissions and roles

Admin · Manager · Frontline user

Open the completion checklistSteps, proof, and recoveryClose checklist

Prerequisites

• The affected workspace and page
• The action, approximate time, and visible status
• A safe error code or request identifier where available

Permissions in practice

• Manager or operations owner: inspect queues, provider state, and recovery controls.
• Support owner: collect safe evidence and coordinate escalation.

Steps

• Confirm the workspace, user role, record, page, and action that failed.
• Check read-only state, operations, health, sync, provider, or execution evidence.
• Decide whether the work failed, is delayed, needs approval, or completed without a refresh.
• Pause the affected path when a repeat could create a duplicate side effect.
• Recover one logical action, verify the result, and record the next owner.
• Send support only the page, time, safe code, expected result, actual result, and steps tried.

Success proof

• The failure has a known state and owner instead of an unverified retry.
• The recovered record or communication appears once with the expected status.
• Support can act without receiving credentials or unnecessary customer data.

Common failures

• A timeout is mistaken for a failed side effect.
• Logs or support notes contain tokens, passwords, message content, or customer data.
• A provider or approval delay is treated as a Sakhaa data failure.

Recovery

• Refresh read-only state and inspect provider or execution evidence before repeating work.
• Use the focused login, import, email, WhatsApp, calling, automation, or API guide.

Rollback

• Pause the dependent send, call, import, or automation path while evidence is collected.
• Restore the last known-good configuration after the owner approves the change.

Next task

Export approved data and review the offboarding controls when the work is complete.

Open next guide

Start with the affected record, action, time, and visible status. Do not repeat a send, call, import, or automation until you understand whether the first action completed.

Identify the failure

1. Confirm the correct workspace, user role, record, and product page.
2. Record the approximate time, action, visible status, and any safe error code.
3. Check the relevant operations, health, sync, or failure view.
4. Decide whether the work failed, is delayed, needs approval, or completed without a refreshed page.

Recover without duplicates

• Refresh read-only state before repeating an action.
• For imports and APIs, keep the same idempotency key only for the same logical request.
• For communication, confirm provider and Sakhaa delivery state before retrying.
• For automation, pause the affected path and inspect its execution evidence.

Contact support

Send the page name, approximate time, safe error code, expected result, actual result, and the steps already tried. Do not send passwords, access tokens, API secrets, message content, or unnecessary customer data.

Use the in-app support path when the answer depends on a workspace, tenant, provider, or customer record.