Administrator, operator, developer, or support engineer
Diagnose from tenant context and evidence instead of repeated retries
Most FlowOS problems become understandable when you identify the workspace, permission, prerequisite, event, execution, and delivery in order. Do not retry a live action until you know whether it already produced an external effect.
Before you start
- Workspace, user, approximate time, and affected record known.
- Permission to view the relevant health or execution evidence.
#Use one repeatable decision path
- Confirm workspace, user, role, plan, feature flag, and time window.
- Find the relevant execution, delivery, activity, or health record.
- Identify the boundary: browser, tenant resolution, database, queue, scheduler, provider, signature, or permission.
- Check the prerequisite and exact recorded error.
- Correct the cause in staging or with a harmless case.
- Retry only after duplicate risk is resolved.
#Match symptoms to evidence
| Symptom | First evidence |
|---|---|
| Record is missing | Workspace and permission |
| Workflow did not continue | Execution, queue, scheduler, wait, or approval |
| Webhook rejected | Raw-body signature, timestamp, workspace, rate limit |
| Duplicate did not run | Idempotency record; this may be correct |
| Connector failed | Health, scope, token refresh, required provider IDs |
| AI unavailable | Provider, key, limit, feature flag, permission |
| Release unhealthy | Strict health and tenant doctor output |
#Prepare a safe support request
Include product version or commit, workspace slug, affected feature, approximate time, exact redacted error, execution or delivery reference, steps to reproduce, strict-health result when relevant, and what changed recently. Exclude all passwords, tokens, API keys, webhook secrets, personal data, raw provider payloads, and private URLs.
#Quick answers
Can I run workflows without a queue worker?
Do not rely on web requests for production workflow processing. Supervise the worker and scheduler.
Does rollback undo provider actions?
No. It changes the workflow definition. Resolve external effects separately.
Can one tenant user log in to another workspace?
Only if that workspace has its own authorized account and role.
Does “Configuration required” mean broken?
No. It means credentials or environment setup must be completed and proven.
#Common mistakes
- Changing several settings before recording the original error.
- Sharing an unredacted log bundle.
- Retrying a payment, webhook, or provider write blindly.
#Verify the result
- The workspace and permission context are confirmed.
- The failing boundary and prerequisite are known.
- Duplicate risk is resolved.
- The support bundle is redacted and reproducible.