Can somebody view customers without being able to export the list? Teams and permissions

“Can somebody view customers without being able to export the list?” Yes: viewing a customer and exporting customers are separate permissions, granted to a person through a role or to a team, and the server refuses an export to anyone who lacks the export permission, whatever their screen shows.

If you need to make sure that only the right people in your business can see — and especially export — your customer and membership records, this is the page you want. By the end of it you will have a role or a team that lets its people look up a customer without being able to download the customer list, scoped to the branch they work at. It takes about 20 minutes the first time.

This matters for more than tidiness. Under Malaysia’s Personal Data Protection Act 2010 (PDPA), your business is the data user, and the Act’s Security Principle expects you to put real technical controls around personal data. Separating “may view” from “may export” is one of the clearest controls you can demonstrate to an auditor. This guide shows you how to configure it.

Locking down customer data, at a glance

1. Check Before you start, then create the team in the Team Maintenance applet, or give a role to each person in Tenant Admin instead (Step 1). Team Code and Team Email are permanent, so choose them with care.
2. Add the people by their confirmed akaun.com e-mail (Step 2).
3. Grant viewing and exporting separately. Viewing a customer does not let anyone export the list (Step 3).
4. Scope each document permission to a branch, with a company target as well for every role that creates documents. A target restricts documents, not master data: a cashier scoped to one branch can still find every customer (Step 4).
5. Test on one person before rolling out, reopening the applet after each change (Step 5).
6. Ask everyone who can export to turn on multi-factor authentication (Step 6).

The setup runs across three pages. Steps 1 and 2 are on this one, Steps 3 to 6 are on Grant, scope and test, and what BigLedger keeps behind these screens, with what it will not do, is on How teams and permissions work.

Meet GadgetSphere Sdn Bhd

Throughout this guide we use GadgetSphere Sdn Bhd, a Malaysian consumer electronics retailer with 22 branches across Klang Valley, Penang, Johor Bahru, Kota Kinabalu and Kuching, and around 85,000 customer records in BigLedger. Most of those customers are walk-in retail shoppers who joined the loyalty programme — so their names, mobile numbers and email addresses are all sitting in the system. GadgetSphere’s cashiers need to look customers up at the counter. They absolutely do not need to download all 85,000 of them to a spreadsheet.

The four ideas you need

Just four terms, then we start clicking.

A permission is one specific thing a person is allowed to do — “read a customer record”, “export customer records”. Each permission has a technical code behind it, like TNT_API_CUSTOMER_READ. You will see those codes on screen; you don’t need to memorise them.

A permission set is a bundle of permissions you group together and name, so you can hand out the whole bundle at once instead of ticking boxes one by one. Think of it as a bag of tools.

A role is a job title — “Cashier”, “Branch Manager”, “HQ Marketing”. You put permission sets into a role in the Tenant Admin applet, then give the role to people. This is how you avoid configuring 400 staff individually.

A team is a group of people. Permissions granted to the team are held by everyone in it, so GadgetSphere can give all 18 cashiers at GS-KV-01 the same rights in one move — and take them away from one cashier by removing that person from the team.

The important part, and the reason you are probably here: a permission can be scoped to a target — a specific company, branch or location. Scoping is real, and Step 4 is where you set it. But it does not reach every screen equally, and the single most expensive assumption people make about BigLedger access is that it does. Read Step 4 before you design anything around it.

What BigLedger keeps when you grant a permission, what it checks on every request, and what a team depends on are on How teams and permissions work.

Before you start

You will need:

• An account with Owner or Admin rank on the tenant. The Tenant Admin applet refuses a Member-rank user outright. The team screens check something else — the tenant owner or admin permission, or one of the team permissions — so a person can hold the rank and still be refused there.
• Your staff already signed up at akaun.com, with their e-mail confirmed.
• A rough idea of your roles. Even a scribble on paper helps: who views, who edits, who exports. There is a worked example in Step 3 you can copy.
• Your companies, branches and locations already set up in the Organisation applet: a target grid has no rows to tick until they exist (Grant and scope, Step 4).
• At least two people holding the tenant owner or admin permission. Taking it off the only role that carries it can leave nobody able to use the team screens or assign roles.
• A hand-over plan for anyone whose branch target will move: the old branch’s documents leave their listing at once, including any they were half-way through.

Step 1: Create the team

The outcome of this step is a named container you can drop people into.

Navigate to: Team Maintenance applet → Create

If the Team Maintenance applet is not on your menu, you are not missing a setting: it has no entry in the Applet Store’s list today. Skip to Step 3 and give the role to each person directly under Tenant Admin → Tenant Roles → (the role) → User. The permission check treats a role given to a person exactly like a permission reached through a team, so nothing in Steps 3 to 6 changes.

Teams are created in their own applet, Team Maintenance; roles and permission sets — which you will need in Step 3 — live in the Tenant Admin applet. The form is plain, so only the parts the screen does not explain.

• Team Name — plain English, because you will read this in a list six months from now. GadgetSphere uses Retail Cashiers — Klang Valley.
• Team Code — at least four characters: letters, digits, underscore and full stop. It is saved in lower case whatever you type, and the edit screen shows it greyed out. GadgetSphere uses cashier.kv.
• Team Email — you type only the part before @teams.akaun.net. The team gets an address on BigLedger’s own domain; it is not a mailbox of yours. It must be unique among active teams and it is also greyed out once saved.
• Team Description — optional.
• Team Visibility and Team Joining — saved with the team, and today nothing acts on them. Choose All members of the team and Only invited users so the record says what you intend.
• Team Status — Active or Not Active.

Click Create. The server also adds you to the new team as its first member, ranked Owner. Open the team from the listing to carry on.

Step 2: Add the people

The outcome is a team with the right humans in it.

Navigate to: the team → Edit Members → add

Reusing a team? A person you add holds whatever the team already holds, from that moment. Read the team’s Permissions List before you add anyone to it.

Type the person’s e-mail and click Verify Email. BigLedger looks the address up among confirmed akaun.com sign-ins. If it finds nobody, the screen offers Send Invite, which e-mails them an invitation to akaun.com — and stops there. It does not put them in the team; once they have registered, come back and add them.

Each member carries a rank — Member, Admin or Owner — and a status of Active or Not Active. Rank is recorded on the membership, and that is all: the server does not read it when it decides what the member can do, which is everything granted to the team, or who may change the team, which is decided by tenant permissions.

To take someone out, open their row and click Delete. From their next action they no longer hold anything granted to the team.

The Import Users tab is a bulk sign-up from a spreadsheet — its columns include a password for each person — and this guide does not cover it.

Step 3: Split view, edit and export

In brief: viewing a customer does not give anyone the ability to export customers, and export is itself two permissions — API_TNT_DM_ENTITY_EXPORT_CREATE asks for the file and API_TNT_DM_ENTITY_EXPORT_READ lists and downloads it. The API refuses the request, so this is not merely a hidden button. The full step, with the permissions that govern customer and membership data and a role table you can copy, is Step 3 on Grant, scope and test.

Step 4: Scope each permission to a branch or company

In brief: leaving a permission with no target means full access across everything, so scope a cashier’s document permissions to their branch, and give every role that creates documents a company target as well, or a new document opens with an empty Company selector. A target restricts documents. It does not restrict master data: a cashier scoped to one branch can still look up every customer. The full step is Step 4 on Grant, scope and test.

What success looks like

Thirty seconds to confirm you are done. Log in as one ordinary member of the team, open the applet fresh, and check all three:

1. The document listing shows your own branch’s documents and not another branch’s. ✅
2. A new document offers your company and branch in the selectors, and saves. ✅
3. The export function is either absent or refuses you. ✅

If all three hold, the export refusal is live and your document scoping is enforced on the server. The three checks do not test the view / edit split itself: compare what the member can change with your role table from Step 3. Note what is deliberately not on this list: finding a customer from another branch. That will succeed, and it is not a sign that you have configured anything wrongly.

Common mistakes

The mistakes in granting, scoping and testing — granting the role but forgetting the scope, scoping the branch and forgetting the company, judging a change from a screen that was already open, expecting a target to hide master data, locking down the applet but leaving the reports open, and assuming view permission covers export — are on Grant, scope and test, beside the steps they spoil. These belong to the rest of the task:

Adding people to a team that already holds permissions. They hold whatever the team currently holds. For a brand-new team that is nothing at all, which is why this guide adds people (Step 2) before it grants anything (Step 3). A team you are reusing, such as a contact-centre team, passes on whatever was granted to it before: read its Permissions List before you add them, so you know what they will hold the moment they join.

Never reviewing it again. Staff move branches and leave. A quarterly pass over who holds export rights takes fifteen minutes and is exactly the sort of evidence a PDPA review asks for.

What BigLedger does not do today

In brief: company, branch and location targets narrow documents and not the customer, supplier or item masters; there is no field-level masking; reading a record is not logged; each report carries its own permission; teams and roles do not combine on the screens; MFA is each person’s own setting; and no ERP can prevent screenshots and manual copying. The full list, and what to do if your compliance programme needs more, is on How teams and permissions work.

How this maps to your PDPA obligations

In brief: under the PDPA your business is the data user, and the policy side stays with you. BigLedger supplies the technical and organisational security measures — access control by role and team, view, edit and export rights checked on the server, document scoping, multi-factor authentication and a change audit trail. Document scoping is not a control over who can read the customer master. The full mapping is on How teams and permissions work.

Related documentation