Administration
Two unrelated jobs sit in this section and they use the same word for different things. Knowing which one you are in saves a lot of confusion.
“Member” means two things, and only one of them is here
| If you mean… | You want |
|---|---|
| A person who works for you and needs access to BigLedger | Teams and permissions or groups |
| A customer in your loyalty programme who collects points | Registering a loyalty member and the pages around it |
Everything on this page whose title starts with Member is the loyalty programme. Staff access is teams, groups and roles.
Access control: who can do what
The shape of it, in one line: permissions go into permission sets, permission sets go into roles, roles are linked to teams (or groups), and people are put in teams. Each permission set is scoped to a target — a company, a branch or a location — and a set with no target confers access to everything.
Multi-factor login is supported on the platform’s login service, and is worth insisting on for any account that can export customer data.
The loyalty programme
The shape of it: a member belongs to one class and carries any number of labels; labels are grouped into label lists. Points are earned and redeemed at the counter and configured here. The class is what pricing and commission read — labels are for your own segmentation and nothing in pricing evaluates them.
Where the rest of administration lives
Much of what an administrator configures is not in this section at all, because it belongs to the applet it governs:
- Company, branch and location structure — the Organisation applet. Almost every other configuration decision hangs off this.
- Default GL codes, sections and categories — chart of accounts setup.
- Cashbooks and settlement methods — the Cashbook applet.
- Tax codes — the Tax Configuration applet.
- Per-applet defaults and visible buttons — each applet’s own gear menu. See finding your way around for the Settings-versus-Personalization distinction.
- Document approvals — document approvals, which covers only purchase orders, purchase requisitions and stock requisitions.
What success looks like
You are oriented here when you can answer:
- Where do you add a new staff member’s access? (A team, linked to a role built in Tenant Admin.)
- Where do you add a new loyalty customer? (Member Listing, in Membership Admin.)
- What happens to a permission set with no target? (It confers access to everything — which is almost never what was intended.)
Common mistakes
| What goes wrong | The fix |
|---|---|
| Looking for user accounts under Member Listing | That is the loyalty programme; staff access is teams and groups |
| Granting a permission to a person directly | Build a role, link it to a team, put the person in the team |
| Permission sets left unscoped | Scope every set to a company, branch or location in Tenant Admin |
| Building a loyalty tier as a label | Tiers are classes; labels are not read by pricing |
| Configuring access before the organisation structure | Companies, branches and locations are what permissions are scoped to — build them first |
| Never reviewing who can export | A quarterly pass over export rights takes fifteen minutes |