How teams and permissions work behind the screen, and what they will not do

The part of locking down customer data that the screens do not show: what BigLedger keeps when you grant a permission, what it checks on every request, what a team depends on, what the controls will not do, and how they map to the PDPA. Read it before you design your roles, or when a change seems not to have taken. The steps themselves are on the front page and on Grant, scope and test.

What BigLedger keeps, and what it checks on every request

None of this is on the screen, and all of it explains something you will see.

• Every grant is one record. It names a permission, who holds it — one person, one role or one team — and at most one target: a company, a branch, a location or a single record. A team is a team record plus one membership per person, each carrying the rank and status you chose. A role is a role record plus a link to each person who has it.
• Signing in proves who you are; it does not carry your permissions. The sign-in token tells the server who is calling; the permissions are looked up afresh. Each screen’s request asks your tenant’s database which permissions you hold at that moment, gathered along five routes: grants made to you directly, to any team you belong to, to any role given to you, to any role linked to one of your teams, and to any team linked to one of your roles. A permission that reaches you through a team counts exactly like one given to you by name.
• So a change takes effect on the person’s next action, not their next login. Nobody has to sign out. What lags is the screen: a document applet asks once, when it opens, which permissions and targets you hold, and builds its company and branch drop-downs from that answer — a snapshot taken at the time it opened, while the server’s own check is always the live figure. After you change someone’s access, have them close and reopen the applet before anyone judges whether it worked.
• Two settings on a team are records, not rules. Team Visibility and Team Joining are saved with the team, and nothing on the server reads either of them. Who gets into a team is decided by whoever adds the members.

What a team leans on, and what leans on it

• What must exist before you start. Your companies, branches and locations, in the Organisation applet — a target grid has no rows to tick until they do. And every person must have an akaun.com account with a confirmed e-mail address, because adding a member looks them up among confirmed sign-ins; somebody who has only been invited does not appear.
• What becomes possible once it is set. The sales invoice listing at GS-KV-01 shows GS-KV-01’s invoices and not Penang’s, because document listings apply the targets on your grants. New documents offer only the permitted companies and branches. The export button works for HQ Marketing and refuses the cashiers. And the customer change history becomes readable by the person you name as auditor.
• Role or team — when to use which. A role lives in Tenant Admin, carries whole permission sets, and is the one with the Branch, Company and Location grids and Copy Permission Set; you give it to people one by one. A team takes single permissions, each with one target, and every member holds them; use it when membership changes more often than the rights do. The contact centre’s Configurations → Teams in the Unified Contact Center writes the same kind of team record for routing work, so look at who is in a team before you grant it anything.
• What breaks elsewhere when it is wrong. Removing a member mid-month ends their access on their next action; the documents they raised stay exactly where they are, because a document is scoped by its own company and branch, never by who raised it. Moving a person’s branch target takes the old branch’s documents out of their listing at once, including any they were half-way through, so hand those over first. And taking the tenant owner or admin permission off the only role that carries it can leave nobody able to use the team screens or assign roles, because both check that permission (or a narrower team or role-assignment permission) rather than the rank shown under Tenant Admins — keep it on at least two people.
• What it pairs with in practice. The Audit Trail guide, for showing what changed and when, and Tenant Admin’s Tenant Users, which is where a person’s roles are visible in one place when you run the quarterly review.

What BigLedger does not do today

We would rather you plan around the real limits than discover them later:

• No record-level restriction on master data. Company, branch and location targets narrow documents. They do not narrow the customer, supplier or item masters, and no setting makes them.
• No field-level masking. There is no built-in option to show a customer’s IC number, phone or email as **** to someone who holds view permission. Access is controlled at record and function level, not column by column.
• Views are not logged. Creates, edits and deletes are fully recorded with the user’s identity. Reading a record is not. The system cannot currently tell you who looked at a particular customer.
• Reports need reviewing separately. As in the common mistakes — each report carries its own permission.
• Teams and roles do not combine on the screens. A team holds permissions granted to it; it does not take a role. Put a right on a role or on a team, not half on each.
• MFA is each person’s own setting. You decide who must have it; they switch it on.
• No ERP can prevent screenshots and manual copying. Those belong to your internal policy and staff undertakings, not to software.

If your organisation needs field masking or read-access logging for a compliance programme, these are development enhancements rather than configuration. Raise it with your BigLedger contact and we will scope it as a formal request.

How this maps to your PDPA obligations

Under the PDPA, your business is the data user. The policy side stays with you: the purpose and consent notice you give customers, how long you keep their data, who you decide is authorised to see what, and how you handle a breach.

What BigLedger supplies are the technical and organisational security measures the Act’s Security Principle calls for:

• Access control by role and by team
• Separation of view, edit and export rights, checked on the server
• Scoping of documents by company, branch and location, checked on the server
• Multi-factor authentication on login
• A change audit trail showing old value, new value, user and timestamp

Describe the third of those accurately if an auditor asks. Document scoping is a real technical control. It is not a control over who can read the customer master, and a control programme that claims it is will not survive being tested.

Configure the steps and you have something concrete to point at when someone asks how personal data is protected in your system.

Related documentation