It's a WordPress custom post type, gf_coupon, with attributes stored in wp_postmeta. SleekView reads the post and pivots the meta keys (type, amount, usage limit, expiry) into columns automatically.

Yes. Updates go through WordPress' post and postmeta APIs (update_post_meta), which fires the standard updated_postmeta hooks. Any add-on watching for changes (caching, audit logs) sees the update normally.

When a coupon applies at submission, the code and discount amount land in gf_entry_meta on the redeeming entry. SleekView joins entries with their coupon meta to build the redemption table, so it's always live, not a sync.

Yes. The redemption view joins gf_entry with the coupon-related meta keys; form_id is one column. Filter to a specific code and you see exactly which form took it across the site.

Enforcement is the add-on's job at submission time. SleekView's usage column reflects current count and lets you spot when a code is near its limit, but the actual enforcement at form submission stays where it belongs.

Yes. Select rows, set the new expiration, write. The update routes through post-meta APIs row by row so caches and hooks fire per coupon. Conflict detection covers cases where another admin edits a code mid-bulk.

Gravity Forms Coupons stores a form_ids meta key with the list of allowed forms. SleekView exposes it as a column; filter "applies to form 12" to find every code valid on that form, useful when migrating or retiring a form.

Indirectly. The coupon adjusts the entry total, which payment add-ons read at submission. SleekView shows the discount as a column alongside payment status from gf_entry_meta, but the actual payment flow stays inside Gravity.