People & groups

Teams on a Synaplan instance can work from named groups of people. Everything still belongs to exactly one owner; groups do not take ownership. Sharing a folder or a chat with a group is a separate, optional step.

This page covers groups, the People page, and sharing a folder, chat, assistant, saved task, or chat widget with a team. Groups, sharing, group policies and directory sync are all on by default since 4.8; an operator can switch each of them off.

In three sentences#

Everything in Synaplan belongs to exactly one person, its owner, and that never changes. A group is a named list of people — made by an admin or, later, pulled in from your company login — so you can say “Sales” or “Support” instead of picking people one by one. Admins manage people and groups and set defaults, but they do not see private content unless someone shares it with them.

Who this is for#

• Administrators create and rename groups, add or remove people, set per-group policies, and decide whether the feature stays on.
• Everyone else can belong to groups and receive a folder, a chat, an assistant, a saved task, or a chat widget that someone shared with that group.

Widget visitors and anonymous guests are never members of a group.

The People page#

Operate → People (/admin/people) is the one home for people on the instance — the old Users tab on Operate Overview is gone, and /admin?tab=users redirects here. Its tabs:

With groups switched off, People keeps the Users tab only.

Create a group#

1. Open Operate → People → Groups.
2. Choose Create group and type a name (for example Sales).
3. Open the group and add people by email. Each person is a member or a manager.

A manager can add and remove people in that group. Instance administrators can manage every group.

Leaving a group#

Everyone sees their own memberships under Account → My groups (/groups). Leave removes a membership you were added to by hand; you lose access to everything shared with that group. A membership that comes from your company login cannot be left here — it is managed by the login and returns at the next sign-in.

Groups from company login#

A group that comes from your company login (kind = directory) shows From your login and is read-only on the People page: you cannot rename or delete it, and login-managed memberships update at the next sign-in. You may still add extra people by hand; they carry a manual badge and survive the next sync. Directory groups from your company login below explains how to turn the sync on.

The flags (operators)#

Groups, the Groups / Policies / Audit tabs and the group API are gated by IAM.GROUPS_ENABLED (BCONFIG group IAM, owner 0). Since 4.8 the seeder inserts the flag as 1, and the migration Version20260911090000 switched it on for installs created earlier. Switch the four flags under Operate → System configuration → Features → People & sharing, pin them per deployment with the environment, or in SQL:

-- automation that talks to the database directly; '0' switches a flag off
INSERT INTO BCONFIG (BOWNERID, BGROUP, BSETTING, BVALUE)
VALUES (0, 'IAM', 'SHARING_ENABLED', '0')
ON DUPLICATE KEY UPDATE BVALUE = '0';

The app picks a change up on the next runtime-config fetch; group rows and shares stay in the database while a flag is off. A FEATURE_*=false variable beats the database row and locks the admin toggle.

Related settings with a non-empty default: IAM.EVERYONE_SHARES (any_owner / admins_only), IAM.ADMIN_IMPERSONATION (audited / disabled), IAM.AUDIT_RETENTION_DAYS (365; 0 keeps audit rows forever), IAM.DIRECTORY_GROUPS_CLAIM (groups), IAM.DIRECTORY_GROUP_NAMES ({}). They live under Operate → System configuration → Access → Sharing; changes apply without a restart.

Sharing is effective only when both GROUPS_ENABLED and SHARING_ENABLED are on.

Directory groups from your company login#

Turn Directory groups on (IAM.DIRECTORY_SYNC_ENABLED) and every OIDC sign-in reads the groups claim (IAM.DIRECTORY_GROUPS_CLAIM, default groups, dotted paths allowed) and reconciles the person's login-managed memberships: new groups are created as kind = directory, missing memberships are added, memberships no longer in the claim are removed. Manual memberships are never touched. Role and admin mapping from the login is unchanged.

IAM.DIRECTORY_GROUP_NAMES is an optional JSON map from claim value to display name ({"eng-berlin": "Engineering Berlin"}). Users who arrive through a partner token exchange (OpenCloud) see the same groups and shares as in the browser.

Audit, admin privacy and impersonation#

People → Audit lists who shared what with whom, group changes, login-group updates, impersonation, and when an administrator opened another user's resource list — with when, who, action, kind and resource, but never content. Filter by actor, action, kind and date. Rows older than IAM.AUDIT_RETENTION_DAYS are reaped.

Administrators can share, unshare and delete (manage), but they cannot read another person's chats, files or assistants unless those are shared with them. View as user on the Users tab is the audited exception (IAM.ADMIN_IMPERSONATION = audited); set it to disabled to remove the action entirely.

Group policies and locked defaults#

With IAM.GROUP_POLICIES_ENABLED on, People gains a Policies tab. Pick one group at a time and set:

A personal setting still wins over a group default — unless you lock the global row. Locked settings show Set by your administrator in the user's model settings and a change attempt is refused with a clear message; an unlocked group default shows Default from your group. A feature switch left unset on a group inherits the instance default rather than forcing it off; instance-level locks are shown on the instance row, not repeated in every group panel. With the flag off nothing is read from the group layer and every install behaves exactly as before.

API keys#

Empty or legacy webhook-only scopes keep full access. A key that opts into iam:read or iam:manage is limited to People, group, and (when sharing is on) share routes:

What does not change#

• Ownership never moves. Deleting a group never deletes chats, files, or knowledge; deleting a person removes only what that person owned.
• Public links (a chat or file shared with a token) stay as they are.
• Widgets, mobile apps, /v1 gateways, and OIDC login keep the same contract.
• Admins do not get a back door into other people's chats or files. Impersonation stays the audited exception it already is.

Sharing a folder or a chat#

Sharing is a second flag, on by default. Groups can exist without anyone sharing anything. When both IAM.GROUPS_ENABLED and IAM.SHARING_ENABLED are on, an owner can share a knowledge folder, a conversation, an AI assistant, a saved task, or a chat widget with a person, a group, or everyone on this instance.

Ownership never moves. The share is a permission on the owner's item. Public token links (a chat or file opened with a URL) stay as they are; team sharing is a different action.

Switching sharing off (operators)#

Sharing is ignored unless groups are also on. Switch it under Operate → System configuration → Features → People & sharing (IAM.SHARING_ENABLED), pin it with FEATURE_IAM_SHARING_ENABLED=false, or use the SQL above with '0'.

Who may share with everyone on this instance is IAM.EVERYONE_SHARES: any_owner (default) or admins_only. Set it under Operate → System configuration → Access → Sharing.

While sharing is off:

• Share routes return 404.
• There is no Share button, chip, Incoming tab, or Shared with me filter.
• Knowledge search stays exactly as it is today (your files only).

How to share#

1. Open the folder on Sources, the chat in history / the sidebar, the assistant under Manage → Assistants → Assistants (Publish section; Instructions on instances without Assistants), the saved task, or the widget under Manage → Channels → Chat widgets.
2. Choose Share.
3. Search for a person (name or email), a group, or Everyone in this organization.
4. Pick a permission and confirm.

The same dialog lists who already has access and lets you remove them. For a chat, Public link is still the existing token link — it is not a group share.

Permissions#

Finding what was shared with you#

• Chats — All chats → Incoming (/chats/incoming) lists every conversation shared with you, with a shared by pill and a source banner when you open one; Account → Incoming chats shows a badge for new ones. The chat sidebar filters the same way.
• Folders — the Incoming tab on Sources. Shared folders open in chat as that person's folder (the AI can use those files only if you have Can use or higher). You cannot delete someone else's folder from this list.
• Assistants, saved tasks, widgets — the Shared with me filter on Manage → Assistants → Assistants, Manage → Automations → Saved tasks and Manage → Channels → Chat widgets.

Publishing an assistant to a group#

Create a custom assistant (the built-in system assistants are already available to everyone and cannot be shared). Open Share and grant Can use to the group. Members see it in their assistant list; people outside the group cannot open it. The assistant's knowledge folder stays with the assistant. With Assistants on, a shared assistant is always its latest published version — the owner's draft edits reach the group only on the next publish.

A saved task shared with you is not run on the owner's schedule. Choose Run as my copy (or Use template on a task saved as a template) to create your own paused copy — it stays off until you turn it on, and the confirmation names any assistant, tool or connection your copy still needs. Mailbox credentials and the owner's connections are never copied.

A chat widget shared with Can view opens the configuration and stats, not visitor transcripts. Can edit lets a teammate change the configuration; the embed code and billing stay with the owner.

Answers that used someone else's files show that person's name on the source.

Continue as my copy#

A conversation you can only view is read-only: you can read it, you cannot type in it.

Continue as my copy (when you have Can use) makes a new chat you own. Messages are copied; the owner's files stay where they are and are referenced, not duplicated. If the owner later deletes a file, the copy shows that it is no longer available.

What happens when you stop sharing#

Removing a person or group from the share list takes effect on the next request. They can no longer open the original item. A copy they already made stays theirs. Knowledge search no longer includes those files for them.

Deleting a group deletes shares to that group. Deleting a person deletes shares granted to them and by them, together with the assistants and saved tasks they owned — a shared saved task cannot keep running for an owner who no longer exists. Copies other people made stay theirs.

Related pages#

• Administration — users, providers, security checklist
• Assistants — build, version and publish assistants to a group
• Linked platforms — approve Nextcloud / ownCloud / OpenCloud servers whose users link their Synaplan account
• Using Synaplan — chat, files & RAG
• First-Run Setup & Administrators — how the first admin is created