Settings and Permissions

“My colleague can see it and I cannot.” The quickest first reply is “can I have your role?” — and it is the right first question. Its close relative is “before this I could, and now I can’t”, usually followed by “nobody changed anything”. Both are usually true at once: somebody opened a settings screen for a perfectly good reason, pressed SAVE, and every other toggle on that screen was written along with the one they came for.

This page is for whoever looks after a BigLedger tenant — the finance lead, the office manager, the person colleagues ask when a column vanishes. It explains the machinery underneath those complaints: where an applet’s settings are kept, who they apply to, when a change reaches other people’s screens, why a setting that has never been saved does not behave like one that is switched off, and how a setting differs from a permission when the two sit side by side on one screen. Ten minutes. It is true of every applet, so every applet page links here instead of explaining it again. The examples use GadgetSphere Sdn Bhd, our fictional three-company electronics retailer with twenty-two branches.

The short answer

An applet’s settings are one JSON document, one per applet, shared by everybody in your tenant, with no per-company copy. On top of it each person can keep a personal layer for that applet, and where the two disagree the personal value wins — for that person only. A permission is a different thing entirely: it is granted to a role — whoever holds the role gets it — it can only ever add something to what they see, and it is enforced in the browser rather than on the server.

So: if you want a rule that applies to the whole business, that is a setting. If you want two colleagues to see different things on the same screen, that is a permission. And if you change a setting, your colleague’s screen changes too — including the colleague on the other side of the country — unless they have switched that same setting on for themselves.

Where a setting lives, and who it applies to

Every applet you have installed carries a single settings record — a JSON document holding every toggle, default and threshold that applet knows about. When you open Settings › Application Settings, that document is what you are editing.

The shared document is tenant-wide. Not per company, not per branch. If GadgetSphere’s group has three companies and twenty-two branches, there is still exactly one Sales Invoice settings document, and a change made from a branch terminal in Penang lands on the screen of the accounts clerk in Klang Valley. That is not an inference from the screen: the record is keyed to the applet and to nothing else — there is no company, branch or user column on it to hang a second copy from.

And it reaches them the next time they open the applet, not the moment you save. An applet reads its settings — and your permissions — once, as it starts. A colleague who already has Sales Invoice open keeps working with the old values until they reload the page or open the applet again. That is why “I switched it on and she still can’t see it” is so often fixed by a browser refresh, and why a change made mid-morning can look as if it “took a while” to spread across the branches.

But the applet never reads that document alone. When an applet opens, it loads the shared document and your personal settings for that applet — a second, smaller document kept against your login — and lays yours over the top, key by key. Wherever your personal copy holds a value, that value is the one your screen obeys. Two places write to it:

• The settings gear on a listing or a simplified document screen, where your applet shows one. An owner or admin can switch between the shared settings and their own; everybody else edits only their own. The personal list offers only the switches the shared document leaves off, and saves only on — so a person can switch on, for themselves, a hide or show setting the business left off, and can never switch off one the business switched on.
• Personalization, which in most applets holds a personal Default Selection and in some a Personal Settings panel.

And one thing that looks like an applet setting and is not: Branch Settings (Settings › Branch Settings) saves onto the branch record, not into the applet’s document. That is genuinely per branch, and every applet that reads the branch sees it.

That division is the answer to the question readers actually ask, which is “will my change affect my colleague?” For Application Settings the answer is yes, everyone — except a colleague who has already switched that key on in their own settings, who keeps it on whatever you do. When two people see one screen differently and no permission explains it, ask whether one of them used the gear.

Absent is not off — and sometimes absent means on

Here is the part that makes “nobody changed anything” true and “it used to work” true at the same time.

A key exists in that JSON document only after somebody has opened the relevant settings screen and pressed SAVE. Until then it is simply not there, and the applet falls back to whatever its own code does when the value is missing. That fallback is written in the code that reads the setting — not on the settings screen — so the screen cannot show it to you, and a toggle sitting in the “off” position on a screen that has never been saved is not telling you what the system will do.

Most of the time the fallback is the harmless one: the key is missing, the feature is off, the field is shown. But not always, and the exception is worth knowing because it is expensive.

The worked example. Sales Invoice has a toggle labelled Disallow negative stock for basic item (validate stock balance). While the settings screen has never been saved, the applet sends nothing about stock validation to the server — and the server’s own default is to validate. So a brand-new tenant refuses to finalise an invoice for stock it does not have, with Not Enough Stock for item …, and nobody switched that on.

Then somebody opens Application Settings to change something else entirely, and presses SAVE. The toggle is sitting in its off position, so false is now written into the document, the applet starts sending it, and the server stops checking. A stock control was switched off by saving a settings panel. Nothing on the screen says so, and nothing is logged in a way a finance person would find.

This is the single best reason to treat a settings screen as a live control rather than a form. Which brings us to the next mechanism, which is the cause of it.

Saving one panel saves the whole screen

The settings screen is one form. Press SAVE anywhere on it and every control’s current value is written, not just the section you were looking at. The write is a merge, so a key already in the document is updated and keys not on the screen are left alone — but every key that is on the screen gets stamped with whatever it is showing.

And the merge never removes anything. A key written once stays in the document for good, even after a later release stops reading it. That is why a long-lived tenant’s settings document drifts larger than the list of settings the applet actually has, and why “this key is in our settings” is not evidence that the key still does anything.

The practical rule: before you press SAVE on a settings screen, look at the whole screen, not the panel you opened it for. If you are not sure what a section is currently doing, that is a reason to find out first, not a reason to save and see.

The settings menu is eight screens, not one

Settings is a menu, and each entry stores somewhere different. When somebody says “it’s in the settings”, this is the list they might mean:

Alongside them sits Personalization, which is yours alone — usually a personal Default Selection, in some applets a Personal Settings panel as well, both kept in the personal layer described above — and the permission listings — Feature Visibility, Client-Side Permission, Permission Set, User, Team and Role — which are the subject of the rest of this page.

Nearly everything our applet pages have historically called “applet settings” is the first of those eight.

A setting is not a permission

They sit on adjacent rows of one screen and govern adjacent fields, which is why nobody can tell them apart. They are not the same mechanism and they are not changed by the same person.

The pair that proves it. Finalise a sales invoice and every field in the header goes read-only — then exactly two of them come back, by two different mechanisms:

• The Sales Agent field is re-enabled by an applet setting. Switch it on and the agent is editable after finalising for everyone, which is usually what a business wants, because the commission is being corrected by whoever notices. It is a setting rather than a fixed rule because businesses asked for opposite things: one wanted the salesperson locked once posted, so nobody could quietly move a commission; another wanted a wrong pick from the drop-down fixed without reversing a posting that was otherwise correct. Left alone, the field stays locked.
• The Transaction Date stays editable only for a user who holds a client-side permission — the ability to back-date a finalised invoice. That one you almost certainly do not want to give everyone, which is exactly why it is a permission and not a setting.

Same screen, same moment, two fields, two mechanisms, two different administrators. When a reader asks “why is the sales agent greyed out?”, the answer is a setting; when they ask “why can’t I change the date?”, the answer is a permission — and the applet page for each screen says which is which.

What a client-side permission actually does

Four facts, and the last two are the ones that surprise people.

It is grant-only. A permission code starts off absent, a grant turns it on, and nothing turns it back off except removing the grant. There is no “deny” that overrides a grant. So you cannot use permissions to take something away from one person while leaving it for the rest of their team — you take it away from everybody and grant it back to the people who should have it.

It is registered per applet, and it travels on a role. Across the platform there are 1,575 active client-side permission definitions covering 59 applets and 518 distinct codes, as at 13 October 2026 — counted from the platform’s own register, which grows as applets ship, so treat the figure as a size rather than a constant. A big document applet declares dozens; a small one declares none at all. If an applet declares none, permissions are not the lever for it. The grant itself is assembled in the browser when you sign in: it takes your login, finds the roles you hold, and for the applet you are currently in collects that role’s client-side permission links. Two consequences, and both catch people out. You cannot grant a client-side permission to a person or to a team — only to a role, so “just give her the one extra column” means making a role. And the same code granted in the Sales Invoice applet does nothing in Sales Order; each applet is a separate grant.

A setting and a permission on the same column combine with OR, never AND. Where a grid column is governed by both — and on the document listings dozens are — the rule is: a key named HIDE_… shows the column unless the setting is on, a key named SHOW_… shows it only if the setting is on, and in either case holding the matching permission shows it regardless. So on a sales invoice’s item lines, switching on the setting that hides the Sales Agent column hides it from everybody except the people whose role holds the matching show sales agent permission — which is usually the arrangement you wanted, and is never what the toggle’s label suggests. Turning the toggle on and then wondering why the column is still there for one colleague is the permission doing its job.

That rule is the shared grid’s, and it holds for columns. Buttons on a document’s own screen are written applet by applet, and some do not follow it. The DRAFT button is the example worth knowing: in Sales Quotation the setting or the permission shows it; in Sales Order the listing follows the OR rule but the order’s own screen needs both; in Stock Requisition the setting alone decides and the permission does nothing. When a button behaves differently from the column next to it, the applet’s reference page says which rule that screen uses.

It decides what the screen shows, and that is its whole job. A client-side permission keeps a column, a button or a field off a screen where it does not belong, for the people who do not need it. That is a tidiness and workflow control, and it is a good one — it is why one Sales Invoice screen can serve a cashier and a finance lead without either of them wading through the other’s columns.

Do not choose a client-side permission as the answer to “who may see our margins”. That is a confidentiality question, and it belongs to the permission sets inside a role in the Tenant Admin applet — a different list, checked by the server — and to your own access policy. If you are not sure which kind governs a figure that matters to you, ask BigLedger support before relying on either.

How to find out what a setting is doing on your tenant, in thirty seconds

You cannot read the stored document from the screen, but you can do better than guessing:

1. Open Settings › Application Settings on the applet and find the toggle.
2. Change something harmless on the same screen and press SAVE. Every visible toggle is now written with the value you can see, so from this moment the screen and the stored document agree. Before that save, they may not have.
3. Go and do the thing. If the behaviour matches the toggle, you now know. If it does not, the key is one the applet no longer reads — the applet page’s On the screen and doing nothing list is where we name those.

When it goes wrong: what you see, and what to do

Work down this list in order. It follows the order in which the causes turn up in practice: roles first, then stale screens, then the personal layer, then a settings save.

What success looks like

A thirty-second check after any change to a setting or a permission:

1. Ask the colleague it affects to reload the applet — not just the listing — so it reads the new values.
2. Have them open the exact screen and look for the column, button or field. For a permission, also ask someone without the role to look: the control should still be absent for them.
3. For a setting that changes what a screen shows, that look is the test. For one that changes what Finalise allows — the stock check — confirm the toggle’s position after the save instead of testing it on a live company: a test that succeeds has posted a real invoice.
4. If you changed Application Settings, note the date and what you changed somewhere your team can find it. The settings document keeps no per-toggle history, so your note is the only record of what changed and why.

If all four hold, you are done.

What settings will not do

• They are not an approval workflow. A workflow status is a label on the document. Unless a specific applet says otherwise, nothing refuses to post because a status has not been reached.
• They are not an audit trail. The document records who changed it. The settings document does not record who changed a toggle or when.
• Most of them do not change what the server accepts. The large majority are enforced in the browser, which means they shape what your staff can do through the screen and nothing about what an import, an API call or another applet can do to the same data. Where a setting really is enforced by the server, the applet page says so and cites where.
• They do not disappear when they stop working. A key can sit in the settings document, and sometimes on the screen, long after the code that read it has gone. That is not a hypothetical: applet pages under this standard carry a short On the screen and doing nothing list precisely because a reader who cannot find the switch assumes they are looking in the wrong place.

How this fits with the rest of BigLedger

Settings and permissions are invisible from any one screen, so here is where they sit.

• What must exist first. A client-side permission depends on a role: the grant hangs on a role, and the person must hold that role. Roles and the permission sets inside them are built in the Tenant Admin applet and linked to people and teams as Teams and Permissions walks through. If nobody in your tenant has a role yet, there is nothing for a client-side permission to travel on.
• What becomes possible once it exists. One grant on a role reaches everyone who holds it. That is what lets GadgetSphere hide the Sales Agent column for everyone and give it back to its twenty-two branch supervisors through one role — one grant to make, and one to remove.
• Its siblings, and when to use which. Use an Application Setting when the rule is the business’s — the same for every company and branch. Use Branch Settings instead of an application setting when the answer genuinely differs per branch and Branch Settings offers it — it holds a smaller, different set of choices, saved on the branch itself. Use Default Selection when you only want a sensible starting value the user may change. Use a client-side permission when two colleagues should see the same screen differently.
• What breaks if it is wrong. An application setting is shared across all three GadgetSphere companies and every branch, so one careless save reaches everyone who uses that applet, in every company and branch, at once. The stock toggle is the expensive case: switched off by a save, it lets sales invoices anywhere in the tenant finalise for basic-item stock the location does not hold, and the negative balances then show up in the inventory module’s stock reports. See the Sales Invoice configuration for the full list of settings that change what is allowed.
• What it pairs with in practice. On the document listings a setting and a permission are usually paired on the same column — a Hide … setting for everyone, a Show … permission for the people who still need it — which is the OR rule above working as designed. The Inventory Item Maintenance page is the clearest example of a screen governed by grants alone.

Where you meet it

Every applet page has a Configuration section with the same three parts: the handful of settings that change what the applet will let you do, the ones that are on the screen and do nothing, and who can change what. Three worked examples, deliberately different in shape:

What to read next

• Teams and Permissions — build the roles that client-side permissions travel on, and link them to people and teams.
• How work actually runs — what happens after you press Finalise, which is where a server-enforced setting such as the stock check shows its teeth.
• What a void undoes — the other half of that story.