Managing Agent Access
Every agent belongs to the organization, but day-to-day building is usually handled by a few specific people. This page explains contributors — the way an Owner or Admin says "these Builders are allowed to work on this particular agent."
What a contributor is
A contributor is an organization Builder who has been granted permission to manage and contribute to one specific agent.
Think of it this way: your organization may have many Builders and many agents. You rarely want every Builder editing every agent. Contributors let you match the right people to the right agent.
Two things are important to understand up front:
- Owner and Admin always have access to every agent in the organization. They do not appear in the contributors list, because their access is automatic — there is nothing to grant or remove.
- Contributors are therefore only ever Builders. Someone with no role, or who only holds Billing, cannot be added as a contributor — grant them the Builder role first.
Mental model: contributors are the "build crew" assigned to a single agent. Owners and Admins are the supervisors who can walk onto any site without a badge.
Who can manage contributors
| Role | Can manage contributors? |
|---|---|
| Owner | Yes |
| Admin | Yes |
| Builder | No |
| No role | No |
| Billing | No |
Only Owner and Admin can add or remove contributors. Only Builders are eligible to be added.
Where to find it
Open the Organization page → click your organization → open the Agents tab → on the agent's card, click Manage Contributors.
This opens that agent's contributors page, which lists everyone currently assigned to it.
Reading a contributor card
Each contributor gets a card. The top of the card identifies the person; below it sits one block per permission, each with a sentence explaining what the current setting actually allows.
| Part of the card | Meaning |
|---|---|
| Name | The contributor's display name. |
| Email · Added | Their account email address, and the date they were added. |
| Conversation history | A switch deciding whether they may read this agent's conversations. On by default. See below. |
| Participant Data | Their access level to what the agent remembers about people. See below. Disabled while the organization switch is off. |
| Delete icon | Removes the contributor. |
Building an agent, reading its conversations, and reading what it remembers about people are three separate permissions. Being made a contributor grants only the first.
Adding a contributor
- On the agent's contributors page, click Add Contributor.
- The Add Agent Contributor dialog opens.
- Open the Organization Builder dropdown. It lists eligible Builders who are not already contributors on this agent.
- Choose the person you want.
- Leave Can view conversation history on, or switch it off for someone who should configure the agent without reading customer conversations.
- Choose a Participant data access level. It defaults to No access.
- Click Add.
The new contributor's card appears immediately and they can now build and edit this agent.
Tip: if a Builder you expect to see is missing from the dropdown, they are probably already a contributor, or they are not a Builder in this organization. Only Builders are eligible.
Removing a contributor
On the contributor's card, click the delete (trash) icon. They lose access to this agent right away.
There is one rule to remember:
Warning: an agent must always keep at least one contributor. You cannot remove the last contributor. If you need to change who maintains the agent, add the new person first, then remove the old one.
Conversation history access
Every conversation with an agent is recorded, so that a session can be picked up where it left off. Contributors have always been able to read those transcripts from the CMS — and some participants object, because a transcript can carry things they would not hand to whoever happens to be configuring the agent.
The Conversation history switch on each contributor card is the answer. The recording still happens; who may read it is now a deliberate decision.
| Setting | What it permits |
|---|---|
| On (default) | Can open the full transcript of this agent's conversations. |
| Off | Can manage the agent, but cannot read what its users said to it. |
Why it defaults to on
This permission describes something contributors could always do, so switching it on for everyone is the only default that does not quietly take a capability away. Every contributor who existed before the setting arrived keeps their access, and nothing had to be migrated. Withholding it is the deliberate act.
That is the opposite of participant data access below, which defaults to No access — there, nobody should gain sight of personal data by accident. The two permissions pull in opposite directions on purpose, and the page says so above the cards.
Owners and Admins keep it
The switch binds contributors. An organization Owner or Admin can always read conversation history, even if their own contributor card has the switch off — they are the people who hand the permission out, so refusing them would be theatre rather than protection.
There is also no organization-wide switch for this one, unlike participant data. Since the default is "allowed", an organization-level off switch would take away from everyone at once what each agent can already decide per person.
What someone without it sees
Three pages show conversation content, and each replaces it with a warning explaining what is missing and who can grant it:
- Conversation Detail — reached from every "View Conversation" button.
- A participant's Conversation History, under Participants.
- Thread Analysis, under Conversation Analysis. Only the message column is withheld; the analysis panel still renders, because a verdict about a conversation is not the conversation.
On Conversation Detail and Thread Analysis the participant's name is withheld along with the messages. On a participant's own Conversation History page the name stays, because you reached it from the Participants list, which shows it anyway.
The buttons that lead there stay exactly where they are. Someone who cannot read transcripts should still see that the feature exists, so they know what to ask an Owner for — hiding the buttons would make the product look broken instead.
Every opening of a transcript is recorded in the service logs: who read it, whose conversation, and when.
What it does not cover
The setting governs full transcripts. It does not hide the short previews that appear elsewhere — the first line of a conversation on the Dashboard, the message snippet on Feedback Insight, or the quoted evidence in a Conversation Analysis drill-down. If a conversation must not be readable at all by a particular person, remove them as a contributor.
Participant data access
Building an agent and reading what it remembers about people are separate permissions. Nobody — not even an organization Owner — holds the second one unless it is granted here.
Each contributor card carries a Participant Data level. The default for a new contributor is No access, so nobody gains sight of personal data merely by being made a contributor.
| Level | What it permits |
|---|---|
| No access | Cannot see anything the agent remembers about participants. |
| Read ordinary fields | May view ordinary remembered fields, but not special-category ones. |
| Read everything, change nothing | May view every remembered field including special-category ones, but may not change or delete any of them. |
| Manage ordinary fields | May view, correct and delete ordinary fields. Special-category fields stay hidden entirely. |
| Manage everything | May view, correct and delete every remembered field, including sensitive ones. |
These are not a ladder. Read everything, change nothing sees more than Manage ordinary fields but changes nothing — the shape an audit or compliance function needs. Manage ordinary fields changes data but never sees sensitive fields. Neither contains the other, so do not think of them as ranked tiers.
The organization switch above it
Every level here is inert until an organization Owner turns on Staff may view what agents remember about individual participants, on the organization's Personalization tab. It is off by default, and turning it on grants nobody anything by itself — each contributor still has to be given a level here.
That tab carries a second Owner-only switch, Agents may declare special-category memory fields, which decides whether an agent may declare health, beliefs, political opinion, sexual orientation or biometric fields at all.
It also carries two numeric limits, and those an organization Admin may set as well as an Owner:
| Limit | What it does |
|---|---|
| Memory fields per agent | How many Memory Fields any agent may declare, up to 30. The agent has no field-count setting of its own — a limit its own contributor could raise would not be a limit. |
| Prompt budget ceiling | The most any agent may spend on remembered data, up to 800. Each agent sets its own budget under it. |
The two bars differ because the decisions differ: the switches say what personal data the organization is willing to process at all, while the limits only bound how much of it an agent carries. Lowering a limit never erases fields already declared — the agent simply cannot add more until it is back under.
What access actually looks like
A granted contributor does not get a browsable table of everyone's memory. They open one participant's remembered data from that participant, and every opening is recorded — who looked, whose data, and when. Corrections a staff member makes are marked as staff edits rather than as the person's own, and unlike the person's own correction they are not protected from being overwritten later.
See Personalization for what is remembered in the first place.
Worked example
Sehat Clinic has an agent called WhatsApp Reminder. Dina is an Admin. She wants dr. Budi — an organization Builder — to maintain the reminder messages.
Dina opens the organization → Agents tab → the WhatsApp Reminder card → Manage Contributors, clicks Add Contributor, picks dr. Budi from the Organization Builder dropdown, and clicks Add. Budi can now edit the agent.
Later Dina tries to add Sari, but Sari has no role in the organization (she only handles Billing) — so Sari does not appear in the dropdown and cannot be added as a contributor. Dina would have to give Sari the Builder role first.
A month on, a patient asks whether the clinic's staff can read what they typed to the reminder agent. Budi writes the messages but never needs to see a patient's replies, so Dina opens his card and switches Conversation history off. Budi keeps editing the agent exactly as before; when he clicks a conversation from the Dashboard, he now gets a warning telling him to ask an Owner. Dina, as an Admin, still sees everything.
Next step
Continue to Transferring an Agent.