Data Management Best Practices

What a member record is

One membership card record per card: card number (from the rule you choose — running number, IC or mobile), member ID, referral code, name, mobile, IC or passport, e-mail, date of birth, gender, class, verification status (VERIFIED, UNVERIFIED, REVIEWED, EXPIRED; new members are UNVERIFIED), join, start and end dates or LIFETIME, branch and sales agent if enabled, e-Invoice buyer fields, up to two custom header statuses, remarks; plus labels, attachments, suspension rows and the point transactions. The customer entity link is optional.

Defend every field on your enrolment form before you print it

That list is 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.

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

The member API’s back-office create routes link or create a customer, so a member with no customer entity is the exception — an older record, or one written some other way. 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 creates both at once and copies the name and identity number across. 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. Editing a member touches the card and never the customer; only the API’s with customer routes copy name, identity number, phone, e-mail and date of birth across. 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. 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.

Read the Checking tab before you accept an upload

• Upload Membership takes the Sample Format CSV (MEMBER NAME, GENDER, DATE OF BIRTH, COUNTRY CODE, MOBILE NO., IC/PASSPORT, EMAIL, MEMBER CLASS, JOIN DATE, START DATE, END DATE, MEMBERSHIP STATUS, REMARKS, LABEL 1…3). Classes and labels must already exist by code. Read the Checking tab before you accept the file: a class code not found, a date in the wrong format or a missing mandatory column rejects the row there, not silently later.
• Upload Member Point Transaction takes card number, company and branch, point currency, points, transaction type and date, description, validity and document reference. Give every row validity dates — a lot without an end date never expires.

Treat every export as the database leaving the building

Look at that column list again. The upload template and the Membership Report export are the whole member database in clear text — names against identity numbers against dates of birth against phone numbers — in a file that can be e-mailed, left in a downloads folder, or opened on a laptop in a coffee shop. BigLedger applies no protection to it once it is produced: there is no watermark, no expiry, no record of who opened it.

Whoever runs the report decides where the file is allowed to live before they run it, and the rules worth having are dull and effective: export to a named folder rather than a desktop, delete it when the task it was run for is finished, never attach it to an e-mail, and never send it to a marketing agency without stripping the identity numbers first. The product will record that the report was run — the report queue keeps the run with its status — and that is the only trace, so the check that this is working is a quarterly look at the report queue asking who ran a full export and why.

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

A member is entitled to ask to see, correct or delete what you hold about them, and you have to answer without the product’s help — there is no data-subject-request workflow, no portability export and no erasure button.

On deletion, say what you can honestly say. Setting a member DELETED or INACTIVE stops them being used, and the underlying record survives because the point transactions are tied to finalised sales documents you are obliged to keep for other reasons. If you need a genuine erasure, it is a request to your platform contact, not a screen — and the time to establish what is possible is before a member asks, not in the week you have to answer them.

Who and when: whoever answers customer complaints logs the request the day it arrives and runs the export the same week, because the clock on these does not stop for a configuration question.

Merge two cards for one person, in this order

The product does not merge members. The API offers a duplicate check by phone and e-mail that an enrolment form can call before creating — note that it returns the customer records carrying that phone or e-mail, not membership cards, so it finds the person behind an existing card only where that card is linked to a customer. Inside the applet, search the listing by mobile number before pressing +. If two cards exist for one person, choose one, move the points with an adjustment (a negative one on the card you retire, a positive one on the card you keep, both with a reason), and set the retired card INACTIVE yourself. Do not expect the zero-balance membership-status processor in the Scheduler’s picker to do it: 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 merge is a person’s job and it has a right order: move the points first, check the receiving card’s balance afterwards, and only then retire the old card — because an INACTIVE card’s points are still countable but nobody will think to look for them.

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.

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.

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. Under the Malaysian Personal Data Protection Act the obligations of consent, purpose, retention and access fall on you as the data user. 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), the branch targets on the membership read permission, the Audit Trail, and your own retention decisions.

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” — and a job somebody does on a date. There is no last-activity filter to run it from: the Membership Report filters on date of birth, start date, end date and lifetime only, so the list of dormant members is built from …/membership-points-txn/lines/query — everyone with no line since your cut-off date — and worked against the member listing by hand. Decide the period when you write the terms, not when somebody asks.

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.