IOSOR База знань
Хто може надсилати, approve або експортувати
Розділіть send, approve й export, щоб finance CSV на кінець місяця не міг запустити production SMS. Прив’яжіть Live-промоушен до runway і compliance-гейтів.
Три дієслова визначають ризик prepaid messaging: send, approve й export. Send сабмітить live SMS і дебетує wallet.
IOSOR чекає явного поділу. Export — у finance і product reporting. Approve — у власників launch і compliance, які дивляться runway green.
Зіставте три дієслова трьом власникам
Зробіть односторінкову матрицю: людина або група → Send / Approve / Export. Надавайте перевагу різним місцям навіть у маленькій команді. Якщо одна людина тимчасово носить два капелюхи, задокументуйте dual role і дату sunset — ніколи не винаходьте постійне god-місце.
Send покриває production submit API, console blast-інструменти й automation identity, які можуть вийти з pilot lane. Approve покриває go-live кампанії, промоушен template і будь-яку кнопку, що переводить draft у Live.
Finance export не повинен успадковувати send
Month-end export о 02:00 — робота finance. Місце, яке завантажує ledger, не повинно також тримати production send. Якщо finance потрібно перевірити spend по коридору, дайте export і read-only status views — не blast-консоль.
Перевіряйте split після кожної зміни ролі: увійдіть як export-місце й підтвердіть, що Send прихований або denied. Якщо UI досі показує Send, матриця — слайд, а не контроль. Коли партнери вимагають «одного admin на все», відповідайте prepaid-чесністю: export, який може send, — шлях, яким quiet hours і STOP обходять випадково. Розділіть дієслова або відкладіть Live.
Approve лишається перед runway і compliance
Approve — не ввічливий checkbox. Він прив’язаний до day-1 runway green і production compliance gates. Людина, яка approve’ить кампанію в Live, має бачити свіжість webhook heartbeat, готовність messaging і compliance-статус — не лише marketing-календар. Не дозволяйте власникам export approve’ити Live-фліпи «бо в них уже admin». Approve без evidence runway створює тікети, які не закриє funded wallet. Якщо runway червоний, approve має відмовляти навіть при зеленому wallet.
Убийте shared super-admin до першого Live
Один пароль на finance, eng і ops згортає три дієслова. Перейдіть на іменні місця до першого production send. В automation identity, які send’ять, має бути human owner поруч із Send — не «shared bot». Партнерські white-label адміни йдуть за тим самим правилом: tenant export-ролі лишаються поза send-шляхом, щоб surface gates і compliance-мова лишалися чесними.
Пов’язані шляхи
Почніть з IOSOR
Відкрийте консоль керування доступом IOSOR та розділіть права між рольовими акаунтами для відправки, затвердження та експорту. Перевірте, щоб фінансовий профіль мав доступ лише до завантаження звітів і перегляду метрик, без можливості виклику продакшн API відправки. Замініть усі спільні облікові записи super-admin на персональні до моменту запуску системи у Live.
Підсумок IOSOR
Цей матеріал довів, що суворе розмежування трьох основних дій запобігає незапланованому запуску масових SMS під час звичайного вивантаження фінансових реєстрів. Надання окремих ролей для Send, Approve та Export створює надійний бар'єр безпеки та забезпечує повну прозорість дій у системі.
Не залишайте універсальних супер-адміністраторів для кількох департаментів та не надавайте фінансовим обліковим записам права виклику розсилок. Завжди закріплюйте кожну автоматизовану роль і шлюз затвердження за конкретною відповідальною людиною.
Чи був матеріал корисним?
Пов’язані гіди
- Хто може надсилати vs гігієна ротації API-ключів
Ролі людей вирішують, хто може send. Ротація API-ключів і cutover sandbox лишаються в Developers — не змішуйте видачу місць із lifecycle секретів.
- Роль export не повинна вміти send
Least privilege на prepaid: доступ до audit і GDPR export — не місце campaign send. Тримайте report-ролі read-only на live messaging-шляху.