User Groups

User groups create sub-domains within your InSkill account. Their primary purpose is delegated administration of a business unit or division: if you have separate groups for cars, trucks, and SUVs, each can contain its own copilots, users, and customers, and a group administrator holds admin rights within that group.

All user groups live within a single InSkill account, so an account administrator can still manage every user, customer, and copilot, and SSO applies to all sign-ins.

How Groups Work

Roles such as Author and Helpdesk Expert are valid within a group, and activity in history and the user log is recorded per group.

Hierarchy

User groups are hierarchical, so a group for Support can have a subgroup for each region, and the group administrator for Support can manage all of their users and subgroups:

Support
├── Support NA
└── Support EU

In this structure, a user in Support EU is also in Support. Their activity appears in the history of Support EU, in Support, and in the overall account.

On the Groups tab, subgroups are listed under their parent. In this example, Field Service has a subgroup for each region, and Product Management has one for each product line.

The group tree on the Groups tab, with Field Service and its four regional subgroups, and Product Management and its two subgroups. — The group tree, with subgroups under their parents

Groups can contain their own copilots, or simply inherit their parent's copilots. For regions that all use the same equipment, inheriting makes management much easier. See Inheriting copilots.

Membership

Users can be members of multiple user groups, which means they can see the copilots in each of those groups. A user has only one role, so their permissions are the same across all groups, copilots, and users.

API keys

An account has an API key, and each user group also has one with a limited scope, so APIs can be used consistently at either level. A group's key can be rotated — replaced with a new key — when needed. See Information.

Roles for Delegated Administration

Role	Scope
Account Administrator	Full capabilities across the entire account. Only an account administrator can create or assign the Group Administrator role.
Group Administrator	Full capabilities limited to the groups they are a member of, including managing subgroups, users, customers, and copilots.

🚧
Caution
No role escalation is allowed. A group administrator can move users within their own domain, but cannot remove a user from a group in a way that would make that user invisible to them, and cannot grant full access. An account administrator must do that.

Setting Up Groups

An account administrator creates the first groups. Follow these steps to create a group:

In the Admin portal, open the Groups tab. Until the account has a group, the tab reads No user groups yet.
Click + Add Group. To create a subgroup instead, select the parent group in the tree and click + Add Sub-Group.
Enter the Group name and, optionally, a Description, then click Create.

The Add Group dialog

For an existing account, each group can then add copilots, users, and customers. The minimum viable setup is one group with a member who holds the Group Administrator role. That person can then create the users and copilots that live within their group.

The Group Page

Click a group in the tree to open its page. A subgroup's page shows its path at the top, such as Field Service > FS - Southwest. The page has five tabs: Members, Customers, Products, Asset Groups, and Information. Save at the top right saves your changes, and the trash icon next to it deletes the group.

Users and customers can also be filtered, and their groups set, from their own pages. See Working Inside a Group.

Members

The users in the group, with their email and role. The trash icon on a row removes the user from the group.

To add users, expand Add Members, search by name or email, select the users, and click + Add Selected. The search accepts several entries at once: paste a list of email addresses and all of them are shown.

The Members tab of the Field Service group, listing eight members with their email and role, with Add Members expanded to show the search box and the users to select. — A group's Members tab, with Add Members open

Customers

The customers in the group, with their role. Add Customers adds more, the same way as Add Members.

Products

The copilots in the group. The tab says Products, the name the API uses for copilots. Each row shows whether the copilot is Visible and Published, and its Owner: the group the copilot belongs to. Add Products adds copilots to the group.

📘
Note
When copilots are added to a group, their components are added too, so the group stays self-consistent.

Inheriting copilots

A subgroup can inherit its parent's copilots. When it does, its Products tab is marked Inherited from parent: copilots added to the parent appear in the subgroup automatically, and the list can't be edited. To manage the subgroup's own list, clear Inherit products from parent on its Information tab.

The Products tab of the FS - Southwest subgroup, marked Inherited from parent, listing the seven copilots of Field Service. — A subgroup's copilots, inherited from its parent

Asset Groups

The asset groups assigned to the group. Add Asset Groups adds more.

Information

Field	Description
Name	The group's name. Required.
Description	Optional. Shown in parentheses after the name in the tree.
Persona	An optional prompt that tells the AI how to respond for this group. Personas are additive: if both Support and Support NA have one, they are combined.
Data	Optional values, in JSON, that resource or task dependencies can use — for example, to personalize content for employees in a region or with a certain skill set.
Inherit products from parent	Subgroups only. When on, the group always has the same copilots as its parent, and its Products list can't be edited.
API Key	The group's API key, scoped to the group. The eye icon shows it, Copy copies it, and Rotate replaces it with a new key.

Working Inside a Group

A member of a group sees a filtered view of copilots. If they create a new copilot, it belongs to their group so that it is visible to them; an author who belongs to multiple groups can select which group the copilot goes in. A user cannot create a copilot that would be invisible to them. The same applies to creating users and customers — a group member's new records automatically belong to their group.

On the Team and Customers tabs, the + Add New form has a Group (Optional) field, which is required if the administrator is in a group. The same is true when creating copilots. Both tabs have a group selector for filtering, including a No Groups option that shows every user not in any group.

Editing a user shows the group tree in the user's Groups section, where you select the groups the user belongs to. Selected lists the groups chosen. The parent of a selected subgroup is checked too, since a member of a subgroup also belongs to its parent.

The Groups section of a user in edit mode, with the group tree, FS - Southwest selected, and its parent Field Service checked. — Choosing a user's groups in edit mode

Groups in Intelligence and the User Log

The Intelligence portal and the User Log both have a group selector that filters activity to the members of the selected group.

An action is related to a group based on the user's membership at the time of the action. If a user in the Support group runs a task, it appears in the user log for Support even after that user leaves the group. Conversely, adding a user to a group does not bring their previous actions with them.

The same applies to the APIs: when using a group API key to query users, diagnostic sessions, or GPT, only actions related to that group are returned.

📘
Note
If a user, customer, or copilot is deleted, its group associations are deleted too. Groups are not exchanged between the author and expert environments.