Users and Teams
There are two groups of people in Achilles, and it helps to keep them apart. Your own team uses the console to build and run agents. Your customers and frontline staff chat with those agents. Each group has its own way of signing in, its own roles and its own controls. This page explains both.
The team side: workspaces and projects
| Term | Meaning | Example |
|---|---|---|
| Workspace | Your team's space in Achilles. Everyone in it works with the same agents. | Your company, or one business unit |
| Project | A group of related agents, data connections and channels inside a workspace | Retail Insurance Servicing |
| Agent | One AI assistant with its abilities and rules | Policy servicing agent |
You switch between projects with the project switcher at the top of the sidebar, and everything you see follows the project you have chosen. When you first sign up, a workspace is created for you automatically. See Key terms for the full vocabulary.
Staff roles in the console
| Role | Can do |
|---|---|
| Owner | Everything a member can, and invite teammates and send invites again |
| Member | See the team, and withdraw an invite that has not been accepted |
There is no finer-grained set of permissions today. Everyone in a workspace can work on its agents, so add people deliberately, and review the Audit trail, which shows who changed what.
Invite a teammate
- As an owner, open the workspace or team settings in the console.
- Enter your colleague's email address and choose Owner or Member.
- The person receives an email with a link. If email is not set up for your account, you can copy the link and send it yourself.
- They open the link, and the invitation shows the workspace and role before they sign up. They create an account or sign in with the same email address.
- Once accepted, they see the workspace straight away.
Good to know:
- Invitations last 7 days. An owner can send a new one to extend it.
- The email address must match the invitation, so a forwarded link cannot be used by someone else.
- Any member can withdraw an invitation that has not been accepted.
- Accepting twice does no harm.
Include console access in your normal joiners, movers and leavers checks. Owners can see who is in the workspace.
The customer side: how people are identified
When a customer or staff member chats with an agent, the agent needs to know who they are and what they may see. This identity always comes from your own systems, and it is never taken from what the person types. If a chat message could claim an identity, data protection rules would mean nothing.
For the website widget and voice, your website passes a secure, short-lived pass at the time the person signs in. The pass says who they are, and which role they have. It usually lasts around 15 minutes, so it is refreshed as people continue chatting. Your IT team sets this up once, and the console can create the keys and limit them to the roles and website addresses you choose. See Website widget.
For WhatsApp and Instagram, there is no sign-in, so every sender gets the default role you chose for the channel. See Messaging channels.
From identity to what a person can see
Your existing roles, such as broker, branch manager or claims handler, are matched to the agent's roles. This is called role mapping, and it is explained in Roles and access. Set it up carefully, because it is the foundation of who sees what.
Two separate sign-ins
The console sign-in and the customer pass are deliberately kept separate. Someone who can log in to the console cannot act as a customer, and a customer's pass cannot open the console. Console sessions last 12 hours.
What is not isolated yet
Agents belong to a workspace, but some resources, such as the shared list of conversations and channels, are common to the whole installation. If you run several business units that must be strictly separated, discuss your setup with your Achilles contact. See also Self-hosting.
Questions
If an invitation does not arrive or a person cannot sign in, see Troubleshooting.