Troubleshooting & Support
When something doesn't work as expected, this section helps you figure out what happened, fix it yourself where you can, and reach support with the right information when you can't. It focuses on the failures builders and administrators hit most often: signing in, permissions, workflow runs, knowledge base ingestion, and Autopilot availability.
Most issues fall into one of a few buckets, and each has a reliable first move:
- You can't sign in. Almost always a one-time sign-in code that expired or was already used, an account soft lock from too many code requests or failed attempts, or single sign-on (SSO) routing. By default a code is valid ~10 minutes; requesting more than 3 codes, or hitting the 3rd failed verification, within a 10-minute window triggers a ~10-minute lock. See Common failure modes and Account lockout and sign-in code limits.
- An action is blocked or hidden. Usually your role doesn't grant that capability — building, admin actions, and API keys each require a specific role. See Common failure modes.
- A workflow run failed or produced no output. Open the run and read its step trace to find the failing step. See Common failure modes.
- A document didn't make it into a knowledge base. Check the document's ingestion status and the source connection. See Common failure modes.
- Autopilot is missing or won't respond. It's enabled per tenant and shows a banner when the service is under load. See Common failure modes.
In this section
| Page | What it covers |
|---|---|
| Common failure modes | Symptoms, causes, and fixes for sign-in and authentication, permissions and access, workflow run failures, knowledge base ingestion, tool calls, and Autopilot. |
| Support | How to get help, what to include in a request so it can be resolved quickly, and the self-service resources to check first. |
Before you troubleshoot
A few checks resolve a large share of issues before you need to dig into traces or contact support:
- Confirm your role. Many "missing button" or "permission denied" reports are simply a role that doesn't include the capability. Builders build; administrators manage connections, knowledge bases, users, and keys. See Governance and permissions.
- Check the AI Employee is published. A draft AI Employee won't run from its live trigger. Publish a version first — see Launching and monitoring.
- Read the run's step trace. For anything that ran but failed or returned the wrong thing, the run's debug logs show exactly which step failed and what it received. See Debug logs.
- Verify the source. For knowledge base and tool issues, confirm the underlying connection is still authenticated and the external service is up.
Ema runs as a set of services behind a single workspace. A problem in one area — say, a slow connected app — doesn't mean your AI Employees or data are affected. Isolate the failing step first, then act on that step.
What's next
- Common failure modes — the symptom-to-fix reference.
- Support — how to reach Ema and what to send.