[Universal Promos]

[01/20/2026]

Problem Statement

Currently, our promos are limited to a specific item at a specific venue. A universal promo would be another promo group that encompasses multiple/all restaurants that have that menu item. Instead of having the restaurant listed on the promo, their would be a link to ‘participating locations’ which displays the locations on a map and scroll view.

Current technical road blocks

  • Live bet creation
    • A live bet record expects one restaurant id on creation
    • It also expects a single menu item id for the bet menu item that is created
  • User Accepts Promo
    • live bet goes from pending status to accepted status
    • on premise prize offer is created with restaurant id (expects one)
    • on premise prize offer item is created with bet menu item
    • bet shows to user on profile page, need to make sure FE gets correct restaurant information
  • Bet resolves
    • create finished bet from live bet data, including restaurant id
    • finished bet record also uses bet menu items to create bet stakes
  • Coupon switches to active
    • still no definitive menu item / restaurant item
    • need to look at cases where coupon goes from pending to cancelled and active to expired
  • Coupon restaurant set
    • can now set restaurant id and menu item id to be inline with restaurant selection
  • Should funciton the same as current promo bets after this

Schemas and external API calls involved in this workflow all expect a restaurant id throughout.

We need a solution that abstracts these menu items and restaurants or allows them to be NULL until an option is selected

Proposed Solution

Current option I am thinking about OPTION 1 - minimal changes of the current code

  1. use a universal promo mapping table
    1. restaurant id : (negative to indicate “virtual”)
    2. menu item id: (negative to indicate “virtual”)
    3. display restaurant name (“participating venues”)
    4. display menu item name (“beer”)
    5. available restaurants: [restaurant_id_1, restaurant_id_2, ect]
    6. available menu items: {“restaurant_id: menu_item_id}
  2. When displaying/getting restaurant information or menu item information as listed above, if there is a negative id, make a function call that queries the universal promo mapping table instead of a db look up.
    1. This would point toward a virtualRestaurant Class that can return a different name / restaurant list / ect based on the universal promo mapping table
    2. This is where the heavy lifting for this implementation is since there are numerous places that look up restaurant information / menu item information
  3. Dev panel creation would look the same for manual restaurant selection and selecting all restaurants that carry the item
  4. We’d have to update finished bets id if the prize is redeemed. Update the coupons restaurant id and prize items menu item id
  5. Potentially need another state for these items between activated and redeemed OPTION 2 ? Please use a different option if it makes more sense. This is where my mind went yesterday/today.

    Architectural & Technical Details

Next Steps

Action Items

Open Questions

Approvals

You need architectural approval from Trace Carrasco & product approval from Filip Pacyna / Troy Lenihan

  • Trace Carrasco
  • Louis Albanez
  • Mason Kelber