Но суть в том что на следующий день, этот официант будет работать уже не в 1 зале, а во 2

И ему должен приходить пуш только со 2 зала

Подписки официантов на топики по залам и слать пуш к топику

ну делайте так.

Тут не в реализации дело, а в ваших бизнес процессах и бэке.

Это вообще не для этого чата вопрос.
Это реализация на стороне BE

А на следующий день официанта отписывать от одного топика и подписывать на другой

Да, это должно быть завязано на аутентификации.

А ротация, графики, список сотрудников, залы, кто-где это у вас на стороне бэка все.
Он и шлет.

От клиента (флатера) требуется только передать свой идентификатор пользователя или JWT и подписаться на нужный топик

Но прежде чем бэк донимать - составьте бизнес требования и соберите аналитику по тому, как это должно работать.
Энивэй, пуши шлет бэкэнд.
Клиент только подписывается по определенному идентификатору.

Если, конечно, вы не хотите сделать так, чтоб клиент (официант) сам мог выбрать с какого зала ему получать уведомления.

И шо?

а не проще телефоны привязать к залам?

и будет пофигу какой официант где првязан, пришел на работы на 3 зал берешь телефон с 3 номерком

изи

посоны кто работал с auto_route

context.router.navigateAll принимает только List<RouteMatch>

как мне передавать туда роуты?

Не согласен, может они на личных телефонах работают. Мне кажется следующая схема лучше подойдет: когда официант открывает смену он просто должен указать на каком зале работает. Можно через qr. Эта инфа хранится в сессии до закрытия смены

Ну вы сча просто гадаете)
Всеж тут энивэй будет плясать от принятых бизнес процессов в компании)
А исходя из бизнесс процессов будет проектироваться бэк.
Фронт уже на сдачу.

Согласен, я работал овсянкой, у нас были  айподы с ркипером, они также работали. Бизнес процессы в общепите не сильно отличаются

овсянка это who

оффициант?

Да

Бармен - буфетчица

женщина - не посудомойка