For the relational tables (edd_orders, edd_customers, edd_order_items) yes — those landed in EDD 3.0. Older versions stored orders as edd_payment posts with payment data in postmeta, and SleekView would need a different mapping. Most stores have migrated to 3.0 by now since EDD's own admin assumes the new schema for any store updated past 3.0.

Yes. edd_order_items can either aggregate into a column (count plus product names concatenated) or expand as a related child table per row when you need full per-line-item detail. The aggregate column is fine for triage views; the expandable table is better for fulfilment when each line matters individually.

Yes — edd_order_addresses, edd_order_adjustments (taxes, discounts, fees), and edd_order_transactions are all exposed as joinable tables. Adjustments often hide important context: a discount code applied at checkout shows up here, not on the order row, so a discount-audit view typically joins adjustments to orders by order id.

Yes. SleekView writes through EDD's CRUD layer where supported, so status-change hooks (refunds revoking file access, license-key adjustments, completion notifications) fire as expected. Bulk operations iterate per row through the same CRUD path so side effects are identical to manual admin edits — no special bulk-mode that bypasses logic.

EDD Software Licensing stores license data in its own table (edd_licenses and related). SleekView can show those as a separate view or join license to order or customer for a license-management workspace. Site-activation tracking from Software Licensing also gets its own table that's exposable for activation audit views.

Yes. Build a view rooted on edd_customers with order count, total spent, refund count, and last-order date as aggregate columns. Useful for support (one row per customer with everything they bought), sales (find high-LTV customers for outreach), and marketing (segment by spend bucket without exporting to a CRM).

EDD Recurring Payments stores subscription data in edd_subscriptions with payment history linking back to orders. SleekView can show subscriptions as their own view (status, billing-cycle, expiration) or join them to customers for a unified subscriber-management workspace. Failed-renewal queues and upcoming-expiration filters become straightforward saved views.

Customer queries hit indexed columns (id, email, date_created) on edd_customers. Aggregate columns (lifetime spend, order count) are computed via subqueries that EDD already indexes for, but they're heavier than direct columns — keep them off triage views and on detail views to keep query plans fast. Pagination is keyset where the schema allows.