Running the programme

The four admin screens — dashboard, referrals, conditions and rewards — what each number means, how approval and rejection reshape the tree, and which admin actions move money and which only move paperwork.

6 min readUpdated 3 August 2026admin, referrals, approval, rewards, dashboard

The admin side lives at /admin/affiliate, reached from Business Tools → Affiliate Program in the admin mega-menu. Four screens, plus settings.

Screen	Path	Permission
Dashboard	`/admin/affiliate`	`access.affiliate`
Referrals	`/admin/affiliate/referral`	`view.affiliate.referral`
Conditions	`/admin/affiliate/condition`	`view.affiliate.condition`
Rewards	`/admin/affiliate/reward`	`view.affiliate.reward`
Settings	`/admin/affiliate/settings`	`access.affiliate.settings`

Note that the menu item itself is gated on the mlm extension being enabled, so a correctly-permissioned admin still sees nothing if the extension is off.

The dashboard

Four headline metrics, each with a month-on-month comparison: unique affiliates (distinct referrers), total referrals, total earnings, and the share of affiliates who have earned at least one reward.

That last one replaced a "conversion rate" that divided this month's reward rows by all-time referrals and could therefore never be a rate of anything. What you have now is a straight percentage: how many of your affiliates the programme has ever actually paid.

Below the metrics:

Monthly earnings for the last 12 months.
Affiliate status distribution — how referrals split across PENDING, ACTIVE and REJECTED.
Top performing affiliates by earnings, with their referral counts.

Two blocks are worth building a routine around.

The pending queue. Referrals awaiting approval, rewards awaiting payout (a count and a total — this is your outstanding liability), and rewards already paid. Every figure is a full-table count or sum, not a sample of the current page.

Stalled affiliates. Members who introduced at least one referral in the last 30 days, have earned at least one reward at some point, and have earned nothing inside the window. That is the signature of somebody whose referrals stopped converting — usually because a condition they relied on was disabled, or its minimum was raised, or its reward currency stopped being priceable. The screen shows the count and the five worst cases.

The dashboard reports a single reward currency only when every condition behind the paid rewards agrees on one. Run conditions paying in different currencies and the payload comes back with a null currency, and the totals are shown as bare numbers — because adding 20 USDT to 20 EUR and printing a symbol would be a lie. If you want symbols on this screen, standardise your conditions on one reward currency.

Referrals

The operational screen: every referral relationship on the platform, with its referrer, referred user and status.

Approving and rejecting

Only relevant when Require Approval is on. A PENDING referral earns nothing and holds no position.

Approving sets the status to ACTIVE and places the referral in the tree — creating a binary or unilevel node, running the cycle check, and using spillover if the sponsor's slots are full. From that moment the referred user's activity earns commission.

Rejecting sets the status to REJECTED and takes the referral back out of the tree: the node is detached, the parent's freed child slot is cleared, and any children the node had are re-parented to its parent so a rejection cannot orphan a live sub-tree.

Nothing is back-paid. Activity by a referred user while their referral was PENDING produced no reward and will not produce one after you approve. If you are going to run an approval queue, work it daily — every hour a referral sits pending is commission your affiliate believes they are earning and is not.

The status change is recorded even if the tree update fails; a placement problem is logged and warned about rather than reverting the decision. If you approve a referral and it does not appear in the tree, check the backend log for a placement error before assuming the approval did not save.

Creating a referral by hand

Pick a referrer and a referred user. Two rules apply: they cannot be the same person, and the referred user must not already be somebody's referral — referredId is unique across the whole table, and a soft-deleted row still occupies the slot.

This is the only way to record a relationship that did not come through a link. Under BINARY or UNILEVEL the tree node is created immediately, regardless of the approval setting.

Deleting

Soft by default: the row gets a deletedAt and stops being counted, but its unique referredId remains taken, so you cannot then create a different referral for the same user. Deleting is for cleaning up mistakes, not for re-assigning sponsors — sponsors cannot be re-assigned.

There is a bulk delete on the same permission (delete.affiliate.referral).

Conditions

The commission rulebook. Covered in full in Commission conditions; the operational points are:

Each row shows the other active conditions that collect on the same activity, the ledger types they share, and the effective percentage rate a referrer really earns once all of them have paid. That number is the one to check before a promotion.
Each row also shows whether it is paid by the live EVENT trigger or by the hourly CRON evaluator.
Enabling a condition that competes with an active one is refused until you confirm the overlap. Disabling is never blocked.
Conditions cannot be deleted — only disabled.
minAmount is ignored on create. Save the condition, then edit it to set the minimum, or it starts at zero and pays on every qualifying transaction however small.

Rewards

Every commission ever created, claimed or not, with its condition and referrer.

Four actions, and it is important to know which of them touch money. None of them do. All four are bookkeeping on the reward table.

Action	Effect
Create	Adds an unclaimed reward against a referrer, hung off a condition that determines the payout currency and wallet
Edit	Changes the amount and the claimed flag
Mark claimed	Sets `isClaimed = true` and nothing else
Delete	Soft-deletes the row

No wallet is credited, no transaction is written, no platform loss is recorded. The reward simply disappears from the member's claimable list.

Use it only to reconcile a reward you settled some other way. To actually pay somebody, either let them claim it themselves, or credit their wallet through the admin wallet tools and then mark the reward claimed so the two records agree.

Creating a reward by hand is the supported way to run a bonus no condition covers — a launch incentive, a leaderboard prize, a goodwill adjustment. Pick the referrer, pick a condition whose currency and wallet type you want the payout to use, and enter the amount. The member claims it through the normal flow, with the payout threshold and the withdraw_affiliate KYC gate applying as usual.

Deleting a reward is soft, and the row keeps its unique sourceId. That means the hourly evaluator will not recreate a reward you deleted for the same period — deleting is genuinely a decision, not a refresh.

Where else affiliate data shows up

The admin user detail screen (/admin/crm/user/<id>) carries an affiliate referrals tab, so you can see a specific member's referral relationships without filtering the whole table.

The hourly job's activity is visible in Admin → System → Cron under the mlm category, as Process MLM Referral Conditions. Its log is the most useful diagnostic in the product: it names every reward it creates, every condition it skips and why, and every currency it could not price. Read it before you conclude that a rule is broken.

A weekly routine

Clear the approval queue if Require Approval is on. Pending referrals earn nothing and the loss is permanent.
Check outstanding liability. The unclaimed reward total on the dashboard is money you owe that appears in no profit report. If it only ever grows, your payout threshold is probably too high for your reward sizes.
Look at stalled affiliates. Several at once almost always means a condition changed, not that several members lost interest.
Read the last cron run. Warnings about unpriceable currencies or referred users holding no wallets are the two failure modes that produce a completely silent, completely broken programme.
Re-check effective rates on the conditions screen after any change. It is the only place that shows what a transaction actually costs you once every overlapping rule has paid.