EDD Points and Rewards stores the current balance as a _edd_points entry in edd_customermeta, keyed by the customer's id in edd_customers. SleekView joins those automatically so the customer email and current balance appear in the same row without a custom query.

Yes, the plugin records every points transaction (earned on order, redeemed at checkout, manual adjustment) with a customer id, value, type, and timestamp. SleekView surfaces this ledger as its own table, sortable by date and filterable by type, joined to the originating order where one exists.

Yes. Inline-edits to the balance column route through the plugin's award or deduct function, which creates the corresponding ledger entry and fires any award hooks. Bulk adjustments iterate per row through the same code path so side effects match the default admin's behaviour.

If you've configured points to award on renewal orders, those renewal awards show up in the ledger like any other earn entry, joined to the renewal order. SleekView reads edd_orders regardless of whether the order is initial or recurring, so a recurring-revenue loyalty workspace works the same as a one-time-order one.

Build a view filtered by last earn or redeem timestamp older than your threshold, joined with the current balance. A common saved view is balance greater than zero and last activity older than 180 days, which surfaces customers who earned points but never redeemed.

Yes. Loyalty programs create a deferred-revenue liability on the books, so finance teams export the monthly ledger to track that liability. SleekView's CSV export carries the current filter and column set, so a monthly export is one click after the view is saved.

Award rules (points per dollar, signup bonus, referral bonus) are stored as options. SleekView focuses on the transactional data: balances and ledger entries. Rules are still configured through the plugin's own settings since they're write-once admin config rather than a workflow surface.

The balance column relies on edd_customermeta with an indexed customer_id and meta_key lookup, which is fast. Ledger queries hit a timestamp index for date-range filters. Aggregate columns (lifetime points earned, redeemed) are heavier so keep them off triage views and on detail views.