Support
When you're stuck, the fastest path to a fix is to gather a little context first, then route your request to the right place. This page explains what to try before reaching out, how to get help, and exactly what to include so your issue can be resolved on the first reply.
Try self-service first
Many issues have a documented cause and fix. Before contacting anyone, check:
- Common failure modes — symptom-to-fix reference for sign-in, permissions, runs, knowledge bases, tools, and Autopilot.
- Debug logs — open the failing run and read its step trace.
- Governance and permissions — confirm your role includes the capability you're missing.
- Audit log — find a recent configuration change that may have introduced the issue.
A large share of reports turn out to be a role that doesn't grant the action, an AI Employee that hasn't been published, or a source connection that needs re-authenticating — all of which you can resolve yourself or with your administrator.
Who to contact
Route your request to the channel that matches the problem:
| If your issue is… | Start with… |
|---|---|
| A role, access, invitation, or "missing button" problem | Your workspace administrator (a system admin or user admin). Most access issues are resolved by adjusting a role or access list. |
| A source connection, knowledge base, SSO, or API key you can't manage | Your workspace administrator. Connections, knowledge bases, SSO, and keys are administrator-managed. |
| A platform bug, an unexpected error, or something you can't explain | Ema support, through the in-app help option in your workspace or the support channel your administrator or Ema account team set up for your organization. |
| A feature request or product idea | Your Ema account team, or the same support channel — describe the outcome you want, not just the feature. |
The exact support entry point — an in-app help option, a help desk portal, or a contact your account team provides — depends on how your organization is set up. If you're not sure where to send a request, ask your workspace administrator.
What to include in a request
The more precise your report, the faster it's resolved. For a technical issue or bug, include as much of the following as applies:
| Detail | Why it helps |
|---|---|
| What you expected vs. what happened | The single most important framing — it tells the team what "fixed" looks like. |
| The run ID | Shown on the run detail page. It lets the team trace the exact execution that failed. This is the highest-value detail for any run problem. |
| The AI Employee name (and which step failed) | Narrows the investigation to the right workflow and node. |
| The exact error text | Copy it verbatim, including any quoted message. Don't paraphrase. |
| Steps to reproduce | The sequence of actions that triggers the issue, as specifically as you can. |
| When it happened | A timestamp (with time zone) helps the team locate the relevant logs. |
| Screenshots or a screen recording | Visual evidence of the symptom, especially for UI issues. |
| Browser and operating system | Rules out client-side and environment-specific causes. |
Don't include secrets. Never paste API keys, passwords, one-time passcodes, or raw sensitive data into a support request. Reference a resource by its name or ID instead.
For a feature request, describe the use case you're trying to accomplish, why the current capabilities don't meet it, and an example if you have one.
Escalating an open request
If an issue is urgent or hasn't moved in the expected time:
- Reply on the existing request with the added context or urgency — don't open a duplicate, which splits the history and slows things down.
- State the business impact. Note whether the issue is blocking production use and who it affects. Requests are prioritized by impact.
- Loop in your Ema account team if you have one — they can escalate internally on your behalf.
What's next
- Common failure modes — check here before you file a request.
- Troubleshooting & Support — the section overview and first-step checklist.