Step-by-step instructions
A manager can create a reliable promotion that applies only in the right locations, dates, hours, customer segment, and order conditions, then appears correctly in the Promotions list.
Use the interactive screenshot walkthrough first. Switch steps with the step dots, then read what to fill and why it matters.
Fields on this screen
Promotions list
How to fill: Start from the list and check current offers before creating another row.
Why: This prevents duplicate or conflicting promotions.
Add
How to fill: Click Add to create a promotion in the current company context.
Why: The new rule receives an ID and opens the Promotion form.
Available
How to fill: Enable only when the rule is ready to work.
Why: Available promotions can affect real orders.
Customer interface visibility
How to fill: Keep enabled only when customers should see the offer.
Why: Some discounts are internal POS rules and should not be advertised.
Name
How to fill: Type the short promotion name in the active interface language.
Why: Names are used in lists, customer screens, selectors, and support.
Photos
How to fill: Upload a square 1:1 promotion image.
Why: This is the main image customers see in cards.
Background photo
How to fill: Upload a wide 7:2 cover image.
Why: The cover makes the promotion recognizable in larger layouts.
Background color
How to fill: Open the picker and choose a supporting card color.
Why: The color keeps the card readable and visually consistent.
Description
How to fill: Type the customer-facing explanation in the active language.
Why: Description explains the value, condition, and expected action.
Start and end dates
How to fill: Open both date pickers and confirm the active period.
Why: Promotions should not start early or remain active after expiry.
Locations
How to fill: Open the selector and choose only establishments where the offer is valid.
Why: Customers should not receive offers that a branch cannot honor.
Promo code
How to fill: Type a short code without spaces.
Why: Promo codes connect marketing and order attribution.
Bonus accumulation
How to fill: Enable only if promo items should still earn bonuses.
Why: This changes loyalty cost and margin.
Automatic application
How to fill: Enable if the discount should be added automatically when conditions match.
Why: This reduces staff work and customer friction.
With other promotions
How to fill: Enable only when stacking discounts is allowed.
Why: Stacking rules must be intentional.
Promotion hours
How to fill: Fill the daily start and finish time when the offer is time-limited.
Why: Lunch and happy-hour promotions depend on local time.
Promotion days
How to fill: Select the weekdays when the rule should work.
Why: Day selection prevents misuse outside the campaign schedule.
Uses per order
How to fill: Open the list and choose the maximum applications per order.
Why: This prevents repeated use of one promotion.
Order conditions
How to fill: Open the condition list and choose what the order must contain.
Why: Conditions make the promotion precise.
Participants
How to fill: Open the participant list and choose the eligible customer audience.
Why: Audience scope prevents the wrong customers from receiving the rule.
Product condition
How to fill: Open product selection when the promotion depends on a specific item.
Why: The rule must point to real products when product-based.
Quantity and amount
How to fill: Type numbers when the promotion depends on quantity or order amount.
Why: Numeric thresholds make the rule testable.
Promotion result
How to fill: Open the result list and choose how the promotion changes the order.
Why: The result is the actual business effect of the promotion.
Promotion applies
How to fill: For bonus outcomes, choose immediate or future-purchase behavior.
Why: This sets the customer's expectation for benefit timing.
Save
How to fill: Save only after media, text, dates, locations, code, rules, audience, schedule, and result are checked.
Why: Saved data becomes the source for orders, receipts, reports, customer screens, and AI agents.
Verify
How to fill: Return to the list and search or inspect the saved row.
Why: Verification confirms that the promotion exists and loads from Supabase.
Common mistakes
- Enabling Available before conditions, dates, and result are reviewed.
- Publishing a customer-facing promotion without clear photo and description.
- Leaving an end date unreviewed for a temporary offer.
- Selecting every location when only one branch honors the offer.
- Combining promo code, automatic application, and stacking without checking margin.
- Skipping days and hours for lunch, happy hour, and seasonal offers.
- Selecting a client group without verifying that customers are assigned to it.
- Not verifying the row in the Promotions list after saving.
AI Agent Field Reference for implementation
This block is intentionally below the human instructions. It explains storage names and downstream dependencies for automation, support, and future AI agents.
| Field | Stored as | Purpose | Why it matters |
|---|---|---|---|
| Promotion ID | discounts.id | Unique promotion identifier. | Lists, edit actions, order discounts, logs, support, and imports need a stable ID. |
| Company | discounts.company_id | Company workspace that owns the promotion. | Prevents discounts and promo codes from leaking between companies. |
| Available | discounts.available | Whether the promotion rule is active. | Orders check this before applying the discount. |
| Name | discounts.name[] | Localized promotion name. | Managers, customers, selectors, search, support, and AI explanations need a readable name. |
| Type | discounts.type | Promotion result type such as percent, fixed price, bonus, fixed amount, or whole-order discount. | This controls how the order total or bonus balance changes. |
| Locations | discounts.establishment[] | Establishment IDs where the promotion applies. | Location scoping prevents customers from seeing or using offers a branch cannot fulfill. |
| Discount flag | discounts.discount_bool | Additional discount behavior flag. | Legacy and current logic can use it to distinguish promotion behavior. |
| Photos | discounts.photos[] | Square promotion media objects. | Customer-facing cards and promotion screens need a clear visual asset. |
| Background photo | discounts.background_photo | Wide promotion cover media. | The cover gives the promotion a recognizable visual header. |
| Color | discounts.color | Background or accent color. | The card stays readable and branded even when the media is not enough. |
| Promo code | discounts.promocode | Code typed by a customer or employee. | Connects marketing, ordering, receipts, and reporting. |
| Start date | discounts.date_start | When the promotion begins. | Prevents early use before launch. |
| End date | discounts.date_finish | When the promotion expires. | Prevents old offers from staying active. |
| Automatic application | discounts.auto | Whether the promotion can apply automatically. | POS and checkout can add the discount when conditions match. |
| Description | discounts.description[] | Localized promotion explanation. | Customers and staff need to understand the condition and value. |
| Customer visibility | discounts.available_in_app | Whether the promotion appears in customer interfaces. | Internal-only discounts can remain hidden from public screens. |
| Client groups | discounts.group_clients[] | Customer group IDs eligible for the promotion. | Enables VIP, new-customer, wholesale, or loyalty-segment offers. |
| Order conditions enabled | discounts.usloviya_zakaza | Whether product/order conditions are required. | Without conditions, a promotion can apply more broadly than intended. |
| Promotion hours | discounts.time_start_finish[] | Daily start and finish time. | Lunch, happy hour, and evening offers need time windows. |
| Promotion days | discounts.days[] | Weekdays when the rule applies. | Prevents a weekday offer from working on the wrong days. |
| Participants | discounts.who_give | Who can use the promotion. | Controls whether all customers, guests, logged-in users, or groups are eligible. |
| Dependencies | discounts.dependencies[] | Product, quantity, comparison, and amount conditions. | Turns written promotion rules into machine-checkable order logic. |
| Fixed-price products | discounts.price_fiks[] | Products that receive fixed result prices. | Required when the promotion changes a product to a fixed price. |
| Result quantity | discounts.quantity_result | Quantity for product, bonus, or result rules. | Needed for gift, bonus, and quantity-based outcomes. |
| Result price | discounts.result_price | Fixed price used by fixed-price promotions. | Lets the promotion sell an item at a controlled price. |
| Fixed amount | discounts.fiks_amount | Money amount discounted from the order. | Used for fixed-value discounts such as $5 off. |
| Discount percent | discounts.discount | Percentage discount value. | Used for percent promotions and whole-order discounts. |
| Immediate application | discounts.immediately | Whether the result applies now or on a future purchase. | Customers and staff need to know when the benefit is usable. |
| Bonus type | discounts.type_bonus | Bonus result subtype. | Distinguishes bonus amount, percent, and quantity behavior. |
| Once per order | discounts.timeinorderone | Limits the promotion to one use in an order. | Protects margin and prevents repeated application of the same rule. |
| With other promotions | discounts.withotherpromotions | Whether this promotion can combine with other promotions. | Prevents conflicting discounts and uncontrolled margin loss. |
| Created at | discounts.created_at | Timestamp when the promotion was created. | Useful for audits and troubleshooting. |
| Updated at | discounts.updated_at | Timestamp when the promotion was last changed. | Support and AI agents can see whether promotion data is fresh. |
| Reload marker | company.loadpromotion | Company timestamp used to reload promotion data. | Native or bulk changes need this marker so the app refreshes promotion state. |
Related guides
Use these guides to connect this section to adjacent SABSUS workflows.