Data Management Best Practices

This page is for whoever answers for the member base at a group like GadgetSphere: the programme owner, and the person your company has made responsible for personal data. A loyalty programme collects names, phone numbers, birthdays and identity numbers from tens of thousands of people, and BigLedger copies them further than the member form suggests. By the end you will know what you hold and where each copy lives, how to keep the record clean as members arrive from the till, the website and a spreadsheet, and how to answer a member who asks what you hold or wants to be removed — with your position decided before the first one asks. Reading takes twenty minutes; the decisions take an afternoon with whoever advises you on the law.

GadgetSphere Sdn Bhd (GS) enrols members at the till in 22 branches, GadgetSphere Online (GSO) enrols them on its website, and the same card earns GSPTS points in every company of the group, GSD included. The examples below use that shape.

What a member record is

One membership card per member. The form shows you its fields; what it does not show is that the card is only one of several places the same details sit, and that a member carries more than one thing called “status”.

Three statuses that are not the same thing

Status	Where it is set	What it means
Record status — `ACTIVE`, `INACTIVE`, and `DELETED` once somebody presses Delete Member	The Status box on the Details tab; the delete button	Whether the card is in use. `DELETED` is a status too: the row stays
Verification status — `VERIFIED`, `UNVERIFIED`, `REVIEWED`, `EXPIRED`	Its own box on the Details tab; a new member starts `UNVERIFIED`, whether created in Membership Admin or at the till	Whether somebody has checked who the member is. The till can be set to refuse redemption to any member who is not `VERIFIED` (Cash Conversion: decide before you switch it on)
Custom status 1 and 2	Two boxes your settings name; the upload’s `MEMBERSHIP STATUS` column fills the first	Whatever your programme decides. Writing `INACTIVE` here does not stop the card

When a colleague says a member is “inactive”, ask which of the three they mean. A spreadsheet uploaded with INACTIVE in its status column leaves every one of those cards in use.

Where else a member’s details go

A member enrolled at GS-KV-01 puts a name, mobile number, e-mail, date of birth and often an identity number on the card. From there:

The linked customer record gets a copy when the card creates one. After that, a change of name, date of birth or gender on the card is copied onto the customer records that share the card’s phone or e-mail — up to five individual ones — and onto their cards (Customer and Member).
Every bill copies the customer’s identity when it is saved and keeps that copy.
The Audit Trail keeps the whole record as it was at every create and change made through the member screens and the member API, and the whole record again when it is deleted. An upload writes no entry.
Exports, the exception e-mail and any webhook take further copies, most of them outside BigLedger (security and compliance lists each one).

Defend every field on your enrolment form before you print it

The form shows what the product can hold, not what you should ask for. Name, identity number, date of birth, mobile and e-mail together are enough to impersonate somebody, and you will hold them for every member you ever sign up. Before the form is printed, whoever owns the programme states the purpose of each field in one sentence — “date of birth, so the birthday gift processor has something to fire on” — and drops any field that cannot get one.

The two that need the most defending are the ones the product treats as ordinary:

Identity or passport number. It is genuinely needed if you use it as the card number rule, or if members are billed and the number feeds e-Invoice. If neither is true, you are holding a national identity number to no purpose.
Date of birth. Worth collecting only if a birthday gift schedule actually exists. A database of birthdays nobody sends anything to is risk with no return.

One catch on date of birth. The member form in Membership Admin will not save an edit until a date of birth (and a phone number) is filled in. A member can be created without a birthday — at the till, by upload, even on Membership Admin’s own create form — but the first correction anybody makes in Membership Admin will ask for a date. If you have decided not to collect birthdays, decide also what staff type there, and that no birthday rule reads it — otherwise a made-up date sends a made-up member a real gift. (A known issue, reported to engineering.)

You know the form is right when every field on it is either used by a rule you have configured or printed on something the member receives.

Members come from four places — decide which you allow

Source	What it creates
Membership Admin → Member Create, or Upload Membership CSV	The member row; class and labels by code. An upload row whose name and mobile match a live member updates that member instead (next section)
POS General member panel	A member with the POS default class and end date, created at the counter. The till first shows Possible Duplicate Found for customers with the same phone or e-mail
CP Commerce Admin → Post Registration Config	On storefront sign-up: a member, a customer, or both, in the website’s default class
The membership API, with or without a customer	A member, or member plus customer entity, from an external system

The back-office create routes link or create a customer, so a member with no customer entity is usually a storefront sign-up made without one, or an older record. For those, Entity Linking for Member Processor (in the Scheduler applet’s processor picker), if scheduled, creates and binds a customer for every member whose entity is empty — but that customer is a thin one: it is named from the part of the member’s e-mail address before the @ (and has no name at all when there is no e-mail), carries the phone, date of birth, gender and branch, and carries neither the member’s name nor their identity number. Check one such customer before you schedule it, because those are exactly the fields an invoice or an e-invoice prints.

The API’s with customer route matches the customer by customer code only, creates one when none has that code, and writes the member’s name, identity number, phone, e-mail, date of birth, gender and addresses over the customer it found, so an integrator sending a stale member overwrites a good customer record (Customer and Member). Unified Contact Center agents link a conversation’s contact to a membership card by hand (Contact Merging). The Customer Maintenance Membership tab shows the plan and points from the customer side.

A correction to a member’s identity number does not reach the customer record. An identity number edited on the member’s Details tab changes the card and not the customer; the member form’s E-Invoice tab and the API’s with customer routes are what write an identity number onto the customer. (A change of name, date of birth or gender does travel, and further than you may want — see Customer and Member.)

On create the mainstream path does link an entity — matching on login, phone or e-mail, or creating a new one with the identity number on it — but where it matches an existing customer it leaves that customer’s details alone. So a member whose identity number was added or fixed after enrolment has it on the membership card and not on the entity, and the symptom lands somewhere else entirely: an e-invoice with no buyer identification (Chase a missing identity number in membership, not in e-invoice). Whoever corrects a member’s identity details checks the Customer Maintenance record in the same sitting, and knows it is right when the identity number shows on both screens.

Check an upload after it runs, not before

Upload Membership processes the file in the background the moment you press ADD and lists it with a status, never its rows. A row with no END DATE fails the whole file; any other bad row is skipped while the file still ends DONE; and a row whose name and mobile number match a live member overwrites that member, though the file’s labels do not attach to it. No upload writes an Audit Trail entry. Bulk Import has what each row does and what an update overwrites, before you build the file.

Whoever runs the upload counts afterwards: the number of members you expected to add, against the listing before and after, and one updated member opened to see that the overwrite is the one you meant.

Upload Member Point Transaction is a different screen with a Checking tab that lists its rows; give every row validity dates, because a lot without an end date never expires (Bulk Import).

Treat every export as the database leaving the building

The Membership Report CSV carries, for every member who is not deleted, the card number, name, phone, e-mail, gender, date of birth, nationality, ethnicity, marital status, occupation, job, and an address taken from one of the member’s documents. A file you prepare for Upload Membership adds the identity number. Either is your member database in clear text, in a file that can be e-mailed, left in a downloads folder or opened on a laptop in a coffee shop.

Once generated, an export stays on the Membership Report screen until somebody deletes it, and the listing shows its file name (which carries the date filter used), status and dates — not who generated it, and not why. So the record of why a file exists is one you keep:

Whoever runs the report decides where the file is allowed to live before they run it: a named folder rather than a desktop, deleted when the task it was run for is finished, never attached to an e-mail, never sent to a marketing agency with more columns than the job needs.
They write one line in an export log — date, who, why, where the file went, when it was deleted.
Each quarter, the person who answers for members’ data reads the listing against the log. Every listed export has a line; any that has done its job is deleted from the screen; and whoever should not be generating exports at all is taken up with whoever administers permission sets (the quarterly review).

The report’s own traps — the join-date filter, the Life Time box, where the address comes from — are on Membership reports.

Where each copy and figure comes from

What you are looking at	Taken from	When
The member’s details on Membership Admin	The card	Live
The same person on Customer Maintenance	The customer, copied once from the card when the card made it	At creation; name, date of birth and gender again when they change on a card sharing its phone or e-mail
Buyer name and identity on a bill or an e-invoice	A copy of the customer	When the bill was saved, and kept
A row in the Membership Report CSV	The card, plus an address from one of the member’s documents	When the queued job ran, frozen in the file
An Audit Trail entry	The card as it was before and after	At each create, change or delete through the member screens or API; not for an upload
The points balance	The card’s stored running total	As each points line is written

So when a member says “you have my old phone number”, the question is which copy. The card may be right and last year’s bills still show the old one, correctly — that is what they said then.

Answer a member who asks what you hold, and know what “delete” can mean here

A member may ask you what you hold about them, to correct it, or to remove it. BigLedger has no request workflow, no single export of one person’s record and no erasure button, so the answer is assembled by a person. What the Personal Data Protection Act 2010 requires of your answer — what you must give, by when, and what you may keep — is a question for your adviser; this section describes what the product holds and does, so the person answering knows what they are working with.

What to gather when a member asks to see what you hold

Find the card from the listing’s search by card number, name or mobile (the advanced search adds the identity number). A card already deleted is not in the listing; its last state is in the Audit Trail. Then, in one sitting:

The card’s tabs: Details, Labels, Member Photos, Upload Attachments, Referrals, Member Suspension and Point Transaction, plus the E-Invoice tab when the card has a customer.
The customer record in Customer Maintenance, and its Membership tab — which may show other people’s cards on the same customer.
The member’s bills, which carry their own copy of the identity details.
Any export still listed on the Membership Report screen, which holds the member as they were when it ran.

The Membership Report has no filter for one member, so it is no help here. Write the answer from what the screens show, and keep a copy of what you sent with the date.

Correct on the form, and check the customer

Edit the member form — and the customer record too, because an identity number, phone or e-mail does not cascade (above). Correct on the form rather than by re-upload, so the Audit Trail shows who changed what. Before you change a name, check whether the member shares a phone or e-mail with anybody else: the new name is copied onto every customer and card that shares them (Customer and Member). You know it is done when the corrected value shows on both screens and the Audit Trail has the entry.

What “delete” does today

Delete Member sets the record status to DELETED. The card row stays, with its extension rows marked the same way.
The points stay. Its transaction lines, lots and stored balance are untouched.
The Audit Trail keeps the whole deleted record, with the login that deleted it.
Member-topic webhooks are told, and each receiver keeps whatever it already had.
The customer record and the bills are not touched.
The card drops out of the listing, the Membership Report and the upload’s matching. If the same person enrols again, they get a new card — possibly linked to the same customer, through the phone number — and the old card’s points history stays on the old card.

Across the groups that run a membership programme, deleting a member is rare and setting one INACTIVE rarer still — so you are probably writing your first rule, not following an old one.

Three positions you can take, and what each costs

Decide this before the first request, with whoever advises you on the law. This wiki recommends none of them, because the right one depends on what your adviser says you must keep.

Position	How you do it	What remains	Its cost
Stop using the record	Set the card `INACTIVE`, or Delete Member	Everything listed above	Simple, and honest only if you tell the member their details are kept
Overwrite, then delete	Replace the name, identity number, phone, e-mail and date of birth on the card with placeholders, then Delete Member; deal with the customer record in Customer Maintenance separately	The Audit Trail holds the old values in each entry; bills keep their copies; webhook receivers keep theirs	Removes the details from the screens people use. But the form insists on a phone number and a date of birth, and a new name is copied onto every customer sharing the phone or e-mail the card carries at that save — so the placeholders must match nobody. Work the sequence out once on a test member before using it on a real one
Ask for a genuine erasure	A request to your platform contact, not a screen	Depends on what is agreed: the points history is tied to bills you keep for other reasons	The only route that reaches the Audit Trail and the database, and the slowest; establish what is possible before a member asks

A worked request at GadgetSphere

A member who joined at GS-PEN-01 writes to GadgetSphere Online asking what you hold and to be removed. Whoever answers member complaints logs it the day it arrives. They search the listing by the mobile number in the e-mail, gather the four items above, and find the card shares its customer with a second card on the same family phone. They send the member what the screens show. For the removal, they apply the position GadgetSphere decided in advance — and, because the customer is shared, they change only the card and leave the customer, which the second card still bills to. They know it is done when the card is in the state the decided position says, the second card’s customer still carries the family’s details, and the request log carries both dates.

Merge two cards for one person, in this order

The product does not merge members. Duplicates are cheaper to stop than to merge.

Stop the duplicate before it is made

At the till, the member panel shows Possible Duplicate Found with every customer that has the same phone or e-mail. The cashier links the existing one, or presses Proceed Create New.
In Membership Admin, search the listing by mobile number before pressing +.
From an enrolment form of your own, the API’s duplicate check by phone and e-mail returns the customer records carrying them, not membership cards, so it finds the person behind an existing card only where that card is linked to a customer.
In an upload, a row matches a live member only on the exact same name and mobile number. The same person keyed as 012-345 6789 once and 0123456789 the next time becomes two cards.

The order

If two cards exist for one person, choose the one to keep. Then:

Move the points with Add Point Adjustment: a negative one on the card you retire and a positive one on the card you keep, in the same points currency, both with the same reason.
Check both balances. The kept card has gained exactly what the retired card held, and the retired card reads zero.
Set the retired card INACTIVE yourself, and put the surviving card number in its remarks.

Do not expect the zero-balance membership-status processor in the Scheduler’s picker to do the last step: despite its general name it reads only balances in a points currency coded ACCESS, so for a programme like GadgetSphere’s GSPTS it changes nothing.

The order matters because a status change does not touch points. A card set INACTIVE before its points were moved keeps its balance, and nobody will think to look for points on a card they retired. If the two cards sit on different customers, decide which customer the person’s bills belong to, re-point the kept card if needed, and leave the old bills where they are.

Keep the consent record yourself — a label is not one

Labels group into label lists and drive notification-topic subscriptions (the storefront’s newsletter topics) through the label-topic assignment processors — one subscribes by label, a separate one unsubscribes. Keep label codes stable: the link is by code on the CSV and by GUID in the tables (member labels).

A label is not a consent register. It records that you put a member in a group, not that the member agreed to be marketed to, and nothing in the product distinguishes the two. If you market to members, the record of who agreed and when is yours to keep — and the workable version is to make consent its own label, applied only from the enrolment form, and to build every newsletter topic from that label rather than from a segment. Remember that an upload does not attach labels to a member it updates; consent given on a re-uploaded form goes on by hand.

Check what a shopper can see on your own website

The storefront membership widgets — the card, the points balance, the QR code — read the logged-in shopper’s own record (selectCurrentMembershipCard), and show “Please login to view your member points” when nobody is signed in. That is correct behaviour and it is not the risk.

The risk is the shared device: a tablet in GS-PEN-01, a browser on a display machine, a member who signed in and walked away. Whoever configures the storefront tests it once, deliberately: sign in as a test member, walk away, come back on the same browser and see whether the balance is still on screen. If it is, the session policy on your site is the control and not the widget, and that is a question for whoever runs the website.

Personal data and PDPA

The member row stores IC or passport number, date of birth, mobile number and e-mail. What the Malaysian Personal Data Protection Act 2010 asks of you as the holder of that data — consent, purpose, retention, access — is for your adviser to state; this wiki does not state it for you. This wiki does not claim that BigLedger is certified against the Act or any other privacy regime; the controls you have are the field-level hide settings on the counter (POS_HIDE_DOB, POS_HIDE_MEMBER_PHONE_NO), who holds the member permissions, the Audit Trail, and your own retention decisions. Branch targets on the membership read permission do not narrow the member listing, so the control is the list of holders, reviewed by the person who answers for your members’ data (Security and compliance).

Retention is the obligation with no product support at all. Nothing in BigLedger ages a member out, flags a record as overdue for deletion or reports how long you have held one. So retention is a rule you write — “a member with no transaction for five years is set INACTIVE and their contact details cleared” is the shape, and the period is yours and your adviser’s — and a job somebody does on a date. There is no last-activity filter to run it from: the Membership Report filters on join date, end date, lifetime and date of birth only.

The list of dormant members is built from the points transaction lines — every card with no line since your cut-off date — which your integration or platform contact pulls through the points transactions query, and worked against the member listing by hand. Decide the period when you write the terms, not when somebody asks.

When it goes wrong

What you see	Why	What to do
An upload shows `FAILED` and no member arrived	A row in it has no `END DATE`	Fill every end date and upload again
An upload shows `DONE` and members are missing	Rows with no name, no mobile and no e-mail, or an unknown class or label code, were skipped	Count the file against the listing; fix and re-upload only the missing rows
A long-standing member’s details changed after an upload	The row matched them on name and mobile and overwrote them	Correct on the form; next time, build upload files from today’s data
Members uploaded with `INACTIVE` are still earning	The `MEMBERSHIP STATUS` column fills custom status 1, not the record status	Set the record status on each card
Membership Admin will not save a correction	The form wants a date of birth and a phone number	Enter the member’s real ones, or the placeholder your rule names
A member who asked to be deleted turns up as a new card	A deleted card is left out of the listing and the upload’s matching, so nobody finds it to reuse	Treat the new card as a new enrolment, and check your request log
A household’s names all changed at once	A name was edited on a card that shares a phone or e-mail	Correct each record; separate the contact details before renaming next time
Old exports nobody can explain are on the Membership Report screen	Nobody keeps an export log, and the listing does not say who ran them	Delete those that have done their job and start the log

How you know it is right

Run these in ten minutes, once a quarter:

Open three members enrolled this quarter — one from the till, one from the website, one from an upload. Each has a customer, and the identity number on the card matches the customer.
Search the listing for a mobile number you know belongs to a regular. It returns one card.
Read the Membership Report listing against the export log. Every file has a line, and none has outlived its purpose.
Read the request log. Every request has a date received, a date answered and the position applied.

How this fits with the rest of membership

What must exist first: the enrolment form’s field list and its purposes, the position on deletion, and the export log — all decided before the first member is keyed, because each is harder to fix than to set.
What it makes possible: member data the finance side can bill and e-invoice from, a request answered in a day rather than a week, and a merge that does not lose points.
Its sibling: security and compliance covers who can see and change members and how points are stolen; this page covers what the records hold and how they are kept clean. Use that one for an access review, this one for a member’s request.
What breaks if this is wrong: e-invoices with no buyer identity, a household renamed in one save, a deleted member who comes back as a stranger, and an export that outlives everyone who remembers why it was run.
What it is used alongside: Membership Admin and Customer Maintenance open side by side, and Customer and Member for how the two records link.

What the old page had and the product does not

Data-quality dashboards and completeness scores; fuzzy duplicate detection and automatic merges; OTP-verified profile changes; bounce-tracking of e-mail and SMS; regional sync and conflict resolution; RFM segmentation reports; a 21-day data-subject request workflow; GDPR portability. None has a screen or a processor — and the two that matter most are handled above: the data-subject request is a procedure, and the duplicate merge is an adjustment done in a fixed order by a person.