Побудувала наскрізний процес заявок на володіння компанією — користувач заявляє права на компанію, адміністратор ухвалює рішення, а схвалення переписує граф авторизації, який визначає, кому що дозволено редагувати.

Ситуація. Каталог, наповнений із публічних джерел, має структурну проблему: компанії потрапили туди не самі. Рано чи пізно приходить хтось із такої компанії й хоче виправити її запис — а між цією людиною й цим записом немає жодного зв’язку, є лише твердження, що зв’язок існує. Надати права надто легко — і сторінку компанії редагуватиме конкурент. Надто повільно — і в каталозі лишаються помилки.

Завдання. Потрібен був шлях від «це моя компанія» до справжніх повноважень над записом — з рішенням людини посередині та слідом, що лишається після нього.

Дія. Механізм заявок на володіння побудовано від початку до кінця — 108 комітів в обох застосунках. Користувач подає заявку з доказами; вона потрапляє в чергу в бек‑офісі; адміністратор розглядає її та схвалює або відхиляє, пояснюючи причину, і це пояснення отримує заявник. Найцікавіше — що саме робить схвалення: це не прапорець у рядку. Схвалення переписує граф авторизації, тож обліковий запис отримує реальний зв’язок з організацією — той самий зв’язок, до якого вже звертається кожна перевірка прав на платформі. Бар’єр — саме рішення людини, а не гілка в коді, і жодна функція не мусила нічого знати про заявки, щоб його дотримуватися.

Результат. Компанії можуть узяти власні записи під контроль і виправити їх, і нікому не доводиться вручну редагувати базу даних, а за кожним наданням повноважень стоять ім’я того, хто його схвалив, і зазначена причина. Розгляд людиною — вузьке місце, і так задумано: автоматична перевірка доменного імені була б швидшою — і помилялася б саме тоді, коли це найважливіше.