Overview

Member Groups is a redesign of how access and permissions work in frontline.io Web. Instead of configuring who can see and do what project by project, you now manage members, roles, groups, and access together at the workspace level, from a single, redesigned Members page in Workspace Management.

The core idea is simple: organise your users into groups, grant each group access to the projects and content it needs, and let members inherit that access automatically. For the cases that don't fit a group, you can still grant access to an individual member directly.

Member Groups is configured per workspace and the exact options you see can vary by your workspace's setup. If an option described here isn't available in your workspace, contact the frontline.io service team.

Key Concepts

Four building blocks work together in the new model:

• Members — the users in your workspace. They are managed on the Members page in Workspace Management.

• Roles — define what a member can do (which features and functionality are available to them, for example Operator or Instructor). Depending on your workspace's configuration, a role can also affect which content a member can see.

• Groups — named collections of members that are granted access to specific projects, folders, and items collectively. When a member belongs to a group, they inherit the group's roles and access.

• Access — the projects, folders, and items a member or group is allowed to open. Access is assigned through a hierarchical selector (an "access tree") so you can grant access at the project, folder, or individual-item level.

What Changed — Before and After

Previously, access was managed inside each project. You invited users to a project and set which roles could view which items, repeating that work for every project. With Member Groups, that configuration moves up to the workspace, where it can be defined once and reused.

How Content Access Works

A workspace's content-access behaviour is set to one of three modes. Which mode applies to your workspace is configured by frontline.io, so the experience can differ between workspaces:

• Role-based only — the legacy behaviour. Groups are not available. Access to content is determined by project invitation and by which roles are permitted to view each item.

• Group-based and direct sharing only — roles no longer affect content access (they only affect which features a member can use). Access is granted through groups and direct sharing.

• Both — groups and individual invitations are the first layer of access to projects and items. After that, the system also checks whether the specific item is available to the member's role.

If you're not sure which mode your workspace uses, contact the frontline.io service team. The mode determines whether you'll work primarily with groups, with roles, or with both.

The Members Page

The Members page (Workspace Management → Members) is the central place to see and manage everyone in your workspace. For each member you can see and manage their roles, groups, and access in one place.

From here you can invite new members, move members into and out of groups, and open any member's access to review exactly what they can reach.

Inviting Members

The redesigned invite panel lets you configure new members correctly at the moment you invite them, rather than afterwards. When inviting, you can:

• Assign a group — the invitee inherits that group's roles and access. (Choosing a group disables the individual role and access fields, because the group provides them.)

• Or assign a role and access directly — for members who shouldn't belong to a group (see Individual access below).

The panel also helps you stay within your plan:

• An indicator shows how many seats remain.

• The Invite button stays disabled until at least one valid email is entered, and the number of invitees does not exceed the remaining seats. A warning appears if you go over the seat limit.

Scan a document for emails (AI): Instead of typing addresses, you can use the upload button (tooltip: "Scan for emails from a document") to select a document — PDF, XLSX, DOC, DOCX, or TXT — and have frontline.io extract the email addresses from it. Extracted addresses that aren't already in the workspace or the invite list are added to the invite list automatically.

Working With Groups

Groups are how you grant the same access to many people at once. You assign members to a group using the Groups context menu, which is available both from the invite panel and from the multi-selection menu on the Members page.

To move several members at once: select them on the Members page, open the multi-selection menu, and choose Edit Group. The Groups context menu lists all groups in your workspace (if none exist yet, the only option is "None"), and clicking a group assigns the selected members immediately.

Example: an admin selects four members, chooses Move to Group, and selects "Instructors". All four are moved into that group and immediately inherit its permissions.

When a member belongs to a group, they inherit the group's roles and access, and their individual role/access controls are disabled. To give a member custom permissions, remove them from the group first.

Granting Access (the Access Tree)

Access — whether for a group or an individual — is assigned through a hierarchical selector, often called the access tree. It mirrors the structure of your content, so you can grant access at the level of a whole project, a folder, or specific items.

When you open a specific member's access in the Members list, you see their access tree: a clear view of everything they can reach. If an item or folder is blocked to that member's role, the access tree indicates it, so you can tell at a glance why something isn't visible to them.

Role Access Rules in Project Settings

When your workspace uses roles for content access, you can fine-tune visibility per project. The Project settings page includes a Role Access Rules section where a project owner or workspace admin can control content visibility by role:

• Toggle an item's visibility based on a member's role.

• A dropdown lists all available roles together with access statistics — showing the accessible vs. total content count for each role — so you can see how much of the project each role can reach.

• Selecting a role opens an access configuration modal where you set exactly what that role can see.

Managing role access in Project settings means you configure content permissions in the same place you manage the project's other settings.

Individual Access for Special Cases

Groups cover most situations, but sometimes a member needs a unique set of permissions. In that case you can invite (or configure) a member with individual access instead of a group:

• Skip group assignment during the invite.

• Manually select which projects, folders, and items the member can access.

• Set the access level (role) per project.

Members configured this way are clearly distinguished from group-based members, so it's easy to see who has bespoke access.

Where "Collaborators" Went

The Collaborators tab has moved. You'll now find collaborator settings inside Project settings, under the Privacy section, alongside the project's other access and privacy options.

Member Slots

Workspace Management now shows the available member slots (seats) for your workspace, and the invite flow enforces them — so you always know how many members you can still add before reaching your limit.

What Happened to Your Existing Permissions

You don't need to rebuild your permissions by hand. When Member Groups is enabled, existing project-level access is automatically migrated into equivalent workspace groups, so members keep the access they had.

The migration works like this, per workspace:

• Any role that had custom access to only a subset of items (interactive flows, digital twins, digital assets, and so on) is identified.

• A workspace group is created, named after that role (for example, Operator Limited Access).

• All members with that role are added to the new group.

• The group is granted access to exactly the items the role previously had — nothing more, nothing less.

Example: in the "Factory A" workspace, the Operator role had access to only 10 of 100 interactive flows. After migration, a group called Operator Limited Access exists, every Operator is a member of it, and the group can access exactly those 10 interactive flows. The end result is that custom access is preserved — but it is now managed entirely at the workspace level.

Frequently Asked Questions

Do I have to use groups?
No. Groups make it easy to manage many members at once, but you can still grant access to an individual member directly for special cases.

Why are the role and access fields greyed out for a member?
That member belongs to a group and inherits the group's roles and access. Remove them from the group to set individual permissions.

Why can a member not see a particular item?
Open their access in the Members list and review their access tree. If an item or folder is blocked to their role, the access tree will indicate it.

Where did the Collaborators tab go?
Into Project settings, under the Privacy section.

The options I see don't match this article.
Member Groups behaviour depends on your workspace's configuration (role-based only, group-based only, or both). Contact the frontline.io service team if you need your workspace's mode confirmed or changed.