Group Maintenance

Maintains groups, named sets of platform logins with a code, a name, an e-mail address, a visibility rule and a joining rule, so that a permission screen elsewhere can name a group instead of every user. It is not an organisation designer: groups are flat, with no nesting and no inheritance, and the applet is withdrawn from the registry, so there is no install path today.

This is not separately installable. The Groups applet is withdrawn from the registry, so nothing lists it in the Applet Store and there is no install path. Groups themselves are real: they are a platform concept, and they are what permission screens across BigLedger mean when they let you pick a group rather than a user. This page documents the maintained front end for them so the concept is documented somewhere, not because you can add it to a tenant today.

Overview

A group is a named set of platform logins. It has a code, a name, its own e-mail address, a visibility rule and a joining rule, and it holds members. Permission screens elsewhere in BigLedger let you assign a permission to a group instead of naming each user, which is the whole point of the object.

The Group Maintenance applet is one screen: a listing of groups, with create and edit behind it. It is not an organisation designer.

There is no designer, no nesting, no inheritance and no dynamic membership: a single listing, a create form with seven fields, and an edit screen with three tabs.

Where it fits

Upstream	This applet	Downstream
Platform logins	Groups and their membership	Any permission screen that offers “select group” instead of “select user” — the permission-set, user, team and role listings shipped inside most applets

Screens and menus

Menu	Route	What it shows
Group Maintenance	`group-maintenance-listing`	The group listing, and create / edit behind it. The landing screen
Settings	`settings/…`	Field Settings, Default Selection
Personalization	`personalization/…`	Field Settings, Default Selection, Sidebar

Listing columns: No, Group Code, Group Name, Rank. The listing carries search, a column toggle, pagination and a grid toggle — and no action buttons; you work through the row.

Create is a single form with a CREATE GROUP button.

Edit has three tabs:

Tab	What it does
Edit General Info	Save keeps only Name, Description and Status. Code and e-mail cannot be changed; Visibility and Joining can be changed on screen but are not written. Description opens blank and Save stays disabled until you type one again (at least 4 characters), which then replaces the old one
Edit Members	The member list — columns No, Email, Rank, Status. ADD opens the add-user panel; a member row opens an edit panel with SAVE and Delete
Import Users	Registers people from a CSV (first_name, last_name, email, password, group, role) and joins each to the group its own group column names, matched by group code — not to the group you have open. Everyone joins as MEMBER. A row whose group code matches no group stops the import there, with the rows before it already done

Six settings routes exist with no menu entry and are reachable only by URL: webhook, feature-visibility, permission-set-listing, user-permission-listing, team-permission-listing and role-permission-listing.

Configuration

There is nothing to configure before you create a group. It needs no branch, no company, no GL code, no numbering sequence and no tax setting — a group is a name, a code, an e-mail address and two rules, and it exists the moment you press CREATE. The only prerequisite is being able to open the applet at all, which today you cannot: see the warning at the top of this page.

Applet settings

Neither settings screen in this applet can save anything. Both are template scaffolding that was never wired up, and this is worth stating plainly because they look exactly like the working versions in other applets:

Settings → Field Settings renders eight slide toggles, none of which is saved, above a SAVE button that does nothing. Pressing SAVE does nothing and shows nothing.
Settings → Default Selection and Personalization → Default Selection do not save either: the first picker change fails in the browser rather than saving.

Nothing else follows from that, because nothing in this applet reads a setting of any kind. A group has no branch and no location for a default to apply to.

How settings are stored and who they apply to explains the mechanism the other applets use.

On the screen and doing nothing

The eight toggles on Field Settings, named so nobody spends an afternoon on them: Unit Discount, SST/VAT/GST, WHT, Blanket Order (under Lines Settings) and Segment, G/L Dimension, Profit Center, Project (under Department Settings). They are the document applets’ line and department toggles, inherited wholesale by a master-data applet that has neither lines nor departments. Not one of them has a key, so there is nothing to set and nothing to search for later. The same eight appear, equally inert, on the Daily Cashier Reports settings screen.

Who can change what

The applet defines no client-side permissions. The registry holds 1,610 permission definitions across 59 applets and none for GroupApplet (queried 2026-09-19), which follows from its row being DELETED. So there is no field-level or button-level gating inside the applet: whoever can open it can create, rename and delete groups and change their membership.

Group permissions are a different thing entirely, and they are not managed here. A group is backed by the platform’s team object, so what you grant on the team permission surface is granted to the team, and the group is how you pick the people. The Edit Permissions tab that once led there is switched off in this applet, so from here that surface is reachable only by URL (below). That is the whole reason groups exist: a permission screen elsewhere in BigLedger can name a group instead of naming every user.

Six permission and utility routes are wired but have no menu entry, so they are reachable only by typing the URL: webhook, feature-visibility, permission-set-listing, user-permission-listing, team-permission-listing and role-permission-listing.

Fields

Create a group

Field	Meaning	Required	Validation
Group Name	The listing’s name column, and the only one of name, code and e-mail you can change later	Yes	At least 4 characters. Not checked for uniqueness — two groups can share a name, and the code tells them apart
Group Code	The identifier	Yes	At least 4 characters; letters, digits, `_` and `.` only. A code already in use is refused by the server when you press CREATE — the screen’s own check shows nothing
Group Email	The local part of the group’s address	Yes	At least 6 characters; letters, digits, `_`, `.` and `-` only. Not effectively checked against other groups: the screen’s duplicate test looks for team addresses, not group ones, so a group address already in use is accepted
Email domain	The domain the address sits on	—	Defaults to `@groups.akaun.net`
Description	Free text, rich-text editor	No	At least 4 characters if given. It does not come back: Edit General Info opens with it blank and requires it again before saving
Group Visibility	Who can see the group	Yes	All members of the team (`MEMBERS_ONLY`) or Anyone on the web (`PUBLIC`)
Group Joining	How someone becomes a member	Yes	Anyone on the web (`PUBLIC`), Only invited users (`INVITED_USERS_ONLY`), or Anyone can ask (`SEND_JOIN_REQUEST`)

A group also carries a status of ACTIVE or INACTIVE (Active / Not Active).

Members are listed by e-mail with a rank and a status.

Lifecycle and effects

This is a master-data applet. It writes groups and group membership, and reads the platform’s teams for permissions. It has no document, no journal and no stock effect.

Groups are flat. Nothing in the applet or behind it expresses a parent, a child or an inherited permission.

Related applets

Employee Maintenance — an employee is an entity; a group is a set of logins. They are different objects and a group is not an org chart
Entity Maintenance — the entity master, for the same reason

Troubleshooting

Symptom	Cause	Fix
The applet is not in the Applet Store	Its registry row is DELETED	There is no install path today. Ask your BigLedger contact
A group code or e-mail is rejected	Character rules — code allows letters, digits, `_` and `.`; e-mail also allows `-`. A duplicate code is refused only at CREATE	Change the value; spaces and other punctuation are not accepted
You cannot nest one group inside another	Groups are flat	Model the structure with separate groups, or use branches and companies, which do have a hierarchy
Visibility or Joining changes do not stick	Edit General Info’s Save writes only name, description and status	No fix on this screen today; the values set at creation stand