Channel access: who handles requests from each channel

SENSEVER

The official Sensever channel: guides and API documentation for Chat, Requests, Flow, Studio, bots and messaging channels.

6 dk okuma

Channel access: who handles requests from each channel

A project can receive requests from several contact channels: WhatsApp, Telegram, MAX and Instagram, the website widget and the contact page. Often different people should handle them: sales answer Instagram, support answers the widget. "Channel access" lets you choose, for each channel, who on the team sees its requests and can work with them.

Where to set it up

Open Projects, choose the project and click the "Team" tile. The tile has two blocks at the bottom of the "Team and departments" card:

  • Request routing and team limits: auto-assignment, reminders, the assignment method ("Least busy" or "Round robin"), the first and next reply SLA, auto-close and per-agent limits;

  • Channel access: a row for every contact channel of the project.

Channel access is configured by the project's owner and admins. An admin's project page has no tiles, so for an admin the "Channel access" block is a separate card on the project page. Agents don't see the block.

Choose who sees a channel

Each row shows the channel ("WhatsApp · Shop", "Site example.com", "Contact page name") and "Who sees requests from this channel":

  • Whole team: every active staff member of the project, according to their usual permissions. This is the default.

  • Selected people: tick "Departments" and "People". A ticked department gives access to everyone in it. The line "Sees it: …, the owner and admins" shows who will see the channel's requests. If nothing is ticked, the channel is available "Only the owner and admins".

Click "Save" in the channel's row.

Things to know:

  • The owner and admins see every channel, always. That's why the "People" list shows only the other staff members.

  • The website widget and the contact page are separate channels, each with its own access, even though both belong to the same site.

  • A department in the list is a group of people: whoever is in the department has access. An empty department gives access to no one. When you add someone to such a department or remove them from it, their access to the channel changes too.

  • Channel and department work together. A person must have access to both the request's channel and its department. A department that is on and has staff shows its requests only to its staff, the owner and admins; a department that is off or empty doesn't limit who sees its requests.

  • "All conversations" works within the person's channels. A staff member whose conversation access is "All conversations" sees all requests of the channels open to them; with "Own and unassigned" they see the unassigned requests of those channels and the requests assigned to them or where they take part.

  • The current channel counts. When a conversation moves from the website widget to a messenger, the messenger's access applies from then on.

When someone loses access

When you save a change, Sensever first works out who it affects and, if anyone is affected, shows the "Change channel access?" confirmation, for example:

  • "Anna loses access to the channel." / "Max gets access to the channel.";

  • "Open requests returned to the queue: 3." These are the person's open requests in this channel: they lose the assignee and go back to the shared queue, where auto-assignment or a colleague picks them up;

  • "Removed as participants from requests: 2." The person is no longer a participant of those requests.

Click "Change" to apply or "Cancel" to keep things as they were. After the change, the channel's requests disappear from the lists of people who lost access without a page reload, and their old requests from this channel no longer open for them. Nothing is deleted: the requests and their history stay in the project for everyone who still has access.

The same happens when access is lost in other ways: someone is removed from a department that has access, an admin becomes an ordinary staff member, or a conversation moves from the widget to a messenger with different access.

Assigning and notifications

  • Auto-assignment picks only people who have access to the request's channel and department.

  • In a request's colleague list, people the channel or department doesn't let in are greyed out with "No access to this channel or department". Assigning such a person fails with "This person has no access to the request's channel."

  • Notifications about a channel's new requests go only to the people who can see them.

The Channel filter in Requests

In Requests, next to the "Department" filter there is a "Channel" filter: "All channels" or one channel. It lists only the channels you can see, so an agent with access to one messenger sees just that messenger.

Access in channel cards

The cards of the channels themselves show their access too: the messenger's settings (the gear in the "Channels" tile), the "Widget" tile and the "Contact page" tile. You see "Available to the whole team", "Available to: …" with the names, or "Only the owner and admins". "Change" opens the "Team" tile at this channel's row.

In a messenger's settings the department field is called "Department for new requests": it sets where a new request from this messenger goes. Who may see the channel's requests is set in "Channel access".

AI answers in this channel

Every channel row and every channel card has the switch "AI answers in this channel". It is on by default and saves at once. When it is off, the project's AI assistant doesn't answer in this channel, neither the Sensever model nor your own server's bot, and requests from this channel go straight to people. Use it, for example, to keep the assistant on the website and let people answer WhatsApp. More about the assistant: Project AI assistant: setup, knowledge and hand-over to your team.

For developers: the API

The settings are stored in Chat and read and changed with these endpoints. They accept only a signed-in owner or admin of the project; requests made with an API key or as a bot are refused with 403.

  • GET /api/v1/projects/{tenant}/channel-access returns channels (each with key, kind = telegram, max, whatsapp, instagram, site or talk, name, access = {mode, department_ids, user_ids} and ai_enabled) and members (with the channels each person can reach).

  • PUT /api/v1/projects/{tenant}/channel-access/{key} with {"mode": "all"} or {"mode": "restricted", "department_ids": [...], "user_ids": [...]} (whole lists), and/or {"ai_enabled": false}.

  • Add ?dry_run=1 to calculate the same change without saving it: the response's affected shows unassigned (requests returned to the queue), participants_removed and, for each affected person, losing_access or gaining_access. This is what the confirmation window shows.

A channel key is ch:<id> for a messenger and site:<id> for the website widget or the contact page. Errors: 403 forbidden (not an owner or admin), 404 not_found (no such channel in the project), 422 validation_failed (a department of another project, an inactive or unknown staff member, or lists without a mode).

Yorumlar

Yazarlar