Цей посібник покроково проведе вас через налаштування вимог до затвердження у вашій Організації — по одному робочому процесу за раз. Налаштовувати все управління одночасно не потрібно — система розроблена так, щоб ви могли переводити кожен робочий процес від швидкого одноосібного виконання до повноцінного багатостороннього затвердження у власному темпі.
Про те, як працюють політики та налаштування затвердження, читайте в розділі Політики, затвердження та управління. Про модель дозволів читайте в розділі Дозволи та робочі процеси.
Взаємодія між Execute та "Always require approval" дає два варіанти управління для кожного робочого процесу:
Перші три кроки є оборотними. Четвертий — блокування — це точка неповернення.
Власник починає з повними дозволами на всі робочі процеси. На цьому етапі Власник є єдиним Учасником і може виконувати будь-які дії без затвердження. Це очікуваний початковий стан.
Налаштуйте процес затвердження для конкретного робочого процесу, поки «Always require approval» залишається вимкненим. Власник зберігає Execute і може продовжувати роботу у звичайному режимі.
Після завершення цього кроку правила підтвердження визначено, а відповідні учасники мають необхідні дозволи, але нічого ще не застосовується примусово. Власник усе ще може виконувати дії через Execute і самостійно змінювати політики.
Увімкніть "Always require approval" для цільового робочого процесу. Це вимагає підтвердження для кожної дії, включно з діями Власника. Перевірте, що:
Оскільки політику ще не заблоковано, Ви можете відкотити зміни. Вимкніть "Always require approval", щоб відновити миттєве виконання та скоригувати конфігурацію перед повторною спробою.
Це безпечне вікно для експериментів. Управління діє для цільового робочого процесу, однак Власник зберігає одноосібний контроль над самою політикою і може відкотити зміни будь-коли.
Переконавшись у правильності налаштувань, заблокуйте політику. Це точка неповернення. Надалі:
Важливо! Перед блокуванням переконайтеся, що принаймні ще один активний учасник має дозвіл Approve у робочому процесі Manage Policies. Система вимагає наявності незалежного погоджувача для блокування.
Важливо! Блокування унеможливлює одноосібне послаблення управління цим робочим процесом. Майбутні зміни, включно з розблокуванням, потребують незалежного погоджувача у робочому процесі Manage Policies.
Усі інші робочі процеси залишаються без обовʼязкового погодження — Власник може використовувати Execute для будь-якого робочого процесу, політику якого не заблоковано. Поверніться до кроку 2 для наступного робочого процесу.
Ця послідовність є рекомендацією, а не вимогою. Ви можете безстроково використовувати будь-яке поєднання керованих і некерованих робочих процесів.
CFO хоче зберегти можливість негайно виконувати Виведення, водночас вимагаючи, щоб усі Виведення від Fund Managers проходили перевірку.
Налаштування дозволів:
Учасник | Показати | Ініціювати | Схвалити | Виконати |
|---|---|---|---|---|
CFO | Так | Так | Так | Так |
Fund Manager A | Так | Так | — | — |
Fund Manager B | Так | Так | — | — |
Налаштування політики:
CFO може ініціювати та негайно виконувати виведення за допомогою Execute. Fund Managers можуть ініціювати виведення, але кожен запит потрапляє до черги затверджень і потребує 1 затвердження від CFO.
Перехід до повного управління: Коли CFO вирішує, що всі виведення, включно з власними, мають проходити затвердження, надсилається запит на зміну політики (який сам потребує незалежного затвердження, оскільки політику заблоковано):
Після цієї зміни дозвіл Execute фінансового директора залишається призначеним, але не діє. Тепер політика потребує незалежного підтвердження для кожного запиту, включно із запитами фінансового директора.
Збереження призначеного Execute — навіть якщо він наразі не діє — зберігає обсяг доступу учасника в матриці дозволів. Це стане особливо корисним, коли буде доступна підтримка кількох облікових записів, де Execute також визначає, якими обліковими записами може керувати учасник.
Цей приклад показує повністю налаштований робочий процес Initiate Withdrawal і ілюструє, як дозволи та політика взаємодіють на практиці. Макет відображає матрицю дозволів, яка відображається в інтерфейсі продукту.
Учасник | Показати | Ініціювати | Схвалити | Виконати |
|---|---|---|---|---|
Organization Owner | Так | Так | Так | Так |
Alice | Так | Так | Так | — |
Bob | Так | — | Так | — |
Charlie | Так | Так | — | — |
Політика: Необхідні затвердження: 2 з 3 доступних підтверджувачів. Завжди потрібне затвердження: ON.
Власник має Execute, але оскільки «Always require approval» увімкнено, цей дозвіл не діє.
Кожен запит на виведення мають підтвердити 2 незалежні учасники. Особа, яка ініціює запит, виключається з пулу підтверджувачів для цього запиту.
Сценарій | Хто ініціює | Хто має погодити | Чому |
|---|---|---|---|
Власник виводить кошти | Власник | Alice і Bob | Після виключення Власника залишається лише 2 учасники з правом Approve. Обидва мають схвалити. |
Alice виводить кошти | Alice | Власник і Bob | Alice виключена. Решта схвалювачів — Власник і Bob. |
Charlie виводить кошти | Charlie | Будь-які 2 з: Власник, Alice, Bob | Charlie не має права Approve, тому всі 3 схвалювачі можуть розглянути запит. Достатньо будь-яких 2. |
Bob ініціює | — | — | Bob не має права Initiate. Він не може створити запит на виведення. Він може лише схвалювати. |