> ## Documentation Index
> Fetch the complete documentation index at: https://docs.linkiasoft.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Letting the help assistant make changes
> The assistant can set things up for you — distribution, shifts, roles, channel access, invitations and AI agents — but only ever with your explicit approval.
Ask the assistant to *make* a change, not just explain it, and it will offer to do it —
"only send chats to agents who are Ready", "create a morning shift 9 to 5, Sunday to
Thursday", "give Sales Team B the support channel".
## You never need to know an id
Refer to things the way you normally would — "the Sales role", "the morning shift", "Ahmed".
The assistant looks them up itself and finds the right one.
If more than one thing matches, it asks which you meant **by name**. If nothing matches, it
says so and lists what does exist. It will not ask you for an id.
Looking things up is read-only and needs the matching view permission, so it can only see
what you could already browse in the app.
## Nothing happens without you
The assistant cannot change anything on its own. When it proposes something you get a card
showing **exactly what would change**, with the current value beside the new one:
```
Only distribute to Ready agents
Off → On
```
Those values are read from your workspace at the moment it proposes, not from what the
assistant says it will do. **If its explanation is wrong, the card still shows the truth.**
Nothing is applied until you press **Apply**. **Dismiss** discards it.
## It can only do what you can
Every action requires the same permission as doing it by hand:
| Action | Permission |
| -------------------------------------- | ------------------------------- |
| Distribution and presence settings | `inbox:manage` |
| Shifts | `analytics:manage` |
| Roles, channel access, assigning roles | `roles:create` / `roles:manage` |
| Inviting users | `users:create` |
| Suspending or reactivating a user | `users:manage` |
| AI agents | `inbox:manage` |
If you do not hold the permission, the assistant is never offered the action at all — it
will explain how to do the thing instead, and you can ask an admin.
Your permission is checked **again** when you press Apply, so an approval cannot outlive
your access.
## Asking versus telling
The assistant is deliberately conservative about this:
* *"How do I only send chats to Ready agents?"* — a question. You get an explanation.
* *"Only send chats to Ready agents."* — a request. You get a card to approve.
If it is unsure, it answers the question and offers to make the change rather than
proposing one you did not ask for.
## Diagnosing a problem
You do not have to describe your setup. The assistant can read it.
Ask *"why isn't Ahmed getting any chats?"* and rather than handing you a checklist, it looks
up his roles, their data scope, the channels each role grants, and the workspace
distribution settings — then tells you which of those is the cause.
It checks, in one pass:
| Check | What it catches |
| --------------------------------------------------- | ------------------------------------------------------------ |
| Do they have a role at all? | A user added but never given one |
| Is the role frontline? | An oversight role is deliberately excluded from distribution |
| Does the role grant channels? | The most common cause by far |
| Which channels are missing? | Named individually, not "some" |
| Chats-only or groups-only grants? | Half the conversations silently withheld |
| Is auto-assign on for the workspace? | Nobody is dealt chats at all |
| Does the workspace distribute only to Ready agents? | Chats queue instead of arriving |
It reports **every** cause it finds, not just the first — these stack, and fixing one while
two remain is why "we already checked that" happens.
If the configuration is clean it says so, and points at the two things it cannot see:
current presence, and open-chat load. Distribution gives new conversations to whoever has
the **fewest open chats**, so an agent whose colleagues are lighter will legitimately be
skipped. See [How assignment works](/help/routing/how-assignment-works).
### Why sending stopped
The other half of the support load, and the one no amount of channel troubleshooting
surfaces: plan limits fail **silently**. The unit pool runs out, outbound messages stop, and
incoming messages keep arriving — so the inbox looks perfectly healthy while nothing you
send leaves.
Ask *"why aren't my messages going out?"* and it checks:
| Check | What it catches |
| ----------------------------------- | ------------------------------------------------------------------------------------------ |
| Units remaining in the monthly pool | Sending and AI replies stopped because the pool is spent |
| Approaching the limit | Warns under 10% left, before a broadcast dies mid-send |
| AI enabled on the plan | The bot is silent because the plan has no AI |
| Campaigns enabled | Broadcasts unavailable |
| Automations enabled | No flow is running |
| SMS credit balance | SMS fails while every other channel works — it is billed separately and comes with no plan |
Bonus units from a growth package count toward the allowance, and an unlimited plan is never
reported as exhausted.
If nothing at the plan level is wrong, it says so and points at the next likely cause: the
channel's connection status, and whether the
[24-hour customer service window](/help/campaigns/meta-pricing-and-windows#the-24-hour-customer-service-window)
has closed — outside it only an approved template can be sent.
### Reading the facts directly
When you want data rather than a verdict, it can also read back:
* **A whole account** — email, status, roles, each role's data scope, and exact channel access
* **Everyone and their roles**, optionally narrowed by a search
* **The workspace inbox settings** — the distribution and presence configuration
* **The plan** — limits, which features are enabled, usage this period and SMS credits
All of this is read-only and permission-checked: it can only see what you could already
open in the app yourself. Nothing here changes or deletes anything — the assistant cannot
alter a setting without showing you a confirmation card first.
## What it can do
The five [distribution toggles](/help/routing/how-assignment-works#the-five-settings),
and the [presence thresholds](/help/routing/presence-ready-busy-off) — idle, auto
sign-out and the offline grace period.
Create a [shift](/help/routing/shifts-and-rotas), change its hours, days, grace minutes
or default flag, replace its roster, or delete it.
Create a role, duplicate one (the documented way to
[build a team](/help/team/roles-and-permissions#channel-access-and-teams)), set which
channels a role covers and whether that includes groups, and give a user a role.
Invite someone by email with the role they get on acceptance — if that role has no
channel access the card says so, since that is the most common reason a new agent
receives nothing. It can also suspend or reactivate an account.
Create an agent with its instructions, set the default, and turn one on or off.
Assigning an agent to channels, uploading knowledge and training still happen in the
[agent wizard](/help/ai/agent-wizard).
## Deleting things
Destructive actions look different — they are styled as a warning, spell out the
consequence ("3 agents on this shift will fall back to the default"), and require you to
**type a word** rather than just click.
Deleting a role or a user is not something the assistant will do at all — suspending is
offered instead, which is reversible. Removing a role
strips access from everyone holding it, and removing a user
[needs their conversations and customers reassigned first](/help/team/users-and-invitations#removing-someone-who-has-left)
— steps that belong on the real screens, where you can see what you are affecting.
## Everything is logged
Every applied change is written to the audit log, attributed to **you**, with the mechanism
recorded — so it reads "changed via the assistant" rather than hiding how it happened.
Failed and refused attempts are logged too.
## If applying fails
Somebody else changed the same thing while the card was on your screen. Applying anyway
would overwrite their change with a value you never saw, so it is refused. Ask again to
see the current values.
Your access changed between the suggestion and the approval. Try **Recheck access** in
the user menu.
Suggestions last ten minutes and can only be applied once. Ask again.