Керування командою

Chaindoc дозволяє впорядкувати роботу команди за допомогою ролей, дозволів та спільних робочих просторів. Тут розказано, як запрошувати учасників, налаштовувати контроль доступу, створювати процеси затвердження та працювати із зовнішніми партнерами.

Кожна дія записується в журналі аудиту — ви завжди знаєте, хто і коли що зробив. Якщо щойно починаєте, спочатку перегляньте посібник із швидкого старту.

Як організовані команди

Ієрархія виглядає так: Організація > Департаменти > Команди > Проєкти. Більшості компаній не потрібні всі чотири рівні. Почніть із команд і додайте департаменти, лише якщо ваша організація достатньо велика.

• Організація — ваш основний об'єкт (одна на компанію)
• Департаменти — групування команд за функціями: Legal, HR, Sales тощо
• Команди — невеликі групи, які працюють разом із документами
• Проєкти — тимчасові групи для конкретних ініціатив, автоматично архівуються після завершення

Команди можуть бути приватними (бачать лише учасники), публічними (видимі всій організації) або міжфункціональними (учасники з різних департаментів). Можна створювати клієнтські команди із зовнішніми співробітниками.

Ролі та дозволи

Chaindoc має шість вбудованих ролей. Кожна визначає, що людина може бачити та робити в організації.

Вбудовані ролі

• Owner — повний контроль: білінг, керування користувачами, видалення акаунту. Завжди є лише один.
• Admin — керує користувачами, командами, системними налаштуваннями та інтеграціями. Може все, крім видалення акаунту.
• Manager — керує командою чи департаментом. Створює команди, керує учасниками, затверджує документи.
• Member — стандартна роль. Може створювати документи, надсилати запити на підпис та переглядати командні документи.
• Guest — для зовнішніх людей (клієнти, постачальники). Може лише переглядати та підписувати призначені документи. Без додаткової вартості ліцензії.
• Auditor — доступ лише для читання до всього. Може переглядати всі документи та журнали аудиту, генерувати звіти. Корисно для команд із дотримання норм.

Користувацькі ролі

Якщо вбудовані ролі не підходять — створіть власні. Ви обираєте, які дозволи включити (перегляд, створення, редагування, видалення, затвердження) і застосовуєте їх до конкретних департаментів чи типів документів. Наприклад, можна створити роль «HR Reviewer», яка має доступ лише до контрактів співробітників.

Користувацькі ролі також можуть мати термін дії — зручно для тимчасових призначень.

Додавання та керування користувачами

Запрошення учасників

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

• Email-запрошення з персональним привітальним повідомленням
• Масовий імпорт через CSV для онбордингу всього департаменту
• Автоматичне додавання через SSO (Azure AD, Google Workspace, Okta, OneLogin)
• Авто-приєднання за доменом: будь-хто з @yourcompany.com може подати запит на доступ
• Створення через API для програмного керування користувачами

Життєвий цикл користувача

Користувачі проходять через стани, коли приєднуються й зрештою залишають організацію. Головне: коли хтось йде, негайно деактивуйте його акаунт і передайте власність на документи. Журнал аудиту залишається незмінним навіть після деактивації.

• Onboarding — запрошення надіслано, автоматичний лист із посібником налаштування
• Active — повний доступ до призначених ресурсів
• Suspended — тимчасове призупинення (розслідування, тривала відпустка)
• Deactivated — постійне видалення, документи передано іншому користувачу
• Дані журналу аудиту зберігаються після деактивації для дотримання норм

Спільні робочі простори

Кожна команда отримує спільний робочий простір із папками, шаблонами та тегами. Учасники автоматично мають доступ до всього в робочому просторі. Не потрібно ділитися окремими документами один за одним.

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

Процеси затвердження

Направляйте документи через ланцюжок затвердження перед відправкою на підпис. Це корисно для контрактів, які потребують перегляду менеджером, чи правових документів із вимогою погодження відділом комплаєнсу.

• Багатоступінчасті ланцюжки затвердження (наприклад, менеджер > legal > VP)
• Послідовне або паралельне затвердження на кожному кроці
• Умовна маршрутизація за вартістю чи типом документа
• Автоматична ескалація, якщо хтось не затвердить у термін
• Делегування: затверджувачі можуть призначити заміну на час відсутності
• Повна історія затвердження в журналі аудиту

Ланцюжки затвердження можна зберігати як шаблони й повторно використовувати. Більшість команд налаштовують 2-3 шаблони для типових сценаріїв (стандартний контракт, угода високої вартості, трудова угода).

Робота із зовнішніми сторонами

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

Для постійних клієнтських відносин можна створити брендовані портали: виділений простір, де клієнти завантажують файли, підписують документи та спілкуються з вашою командою. Доступні white-label опції для приховування брендингу Chaindoc.

Активність гостей відстежується в журналі аудиту так само, як і внутрішніх користувачів. Можна встановити обмеження за часом, яке закінчується автоматично.

Аутентифікація та безпека

Можна вимагати MFA для всіх користувачів (рекомендується) або зробити це необов'язковим. Повний перелік опцій безпеки дивіться в посібнику з безпеки.

• SSO через SAML 2.0 (Azure AD, Google Workspace, Okta, OneLogin)
• Multi-factor authentication: додаток-аутентифікатор, SMS, апаратні ключі (FIDO2)
• Обмеження за IP-адресою та географією
• Політики тайм-ауту сесій (налаштовуються за ролями)
• Віддалене завершення сесій та обмеження одночасних сесій
• Сповіщення про підозрілу активність входу

Якщо використовуєте LDAP чи Active Directory, Chaindoc синхронізується з вашим каталогом — додавання та видалення користувачів відбувається автоматично.

Аналітика та звітність

Інформаційна панель команди показує документи, створені користувачем, середній час до завершення підписання, вузькі місця затвердження та використання сховища за командами. Звіти можна експортувати або запланувати надсилання керівникам команд щотижня.

Для комплаєнсу є готові звіти для аудиту доступу, змін дозволів, невдалих спроб аутентифікації та дотримання політик зберігання. Усі ці дані також доступні через API, якщо потрібно передати їх в іншу систему.

Кращі практики

Кілька порад, які заощадять головний біль із зростанням команди:

• Визначте ролі та дозволи перед запрошенням. Ретроактивні зміни дозволів — це біль.
• Налаштуйте SSO якомога раніше. Додавання пізніше означає, що всім доведеться перепідключати акаунти.
• Примусово увімкніть MFA з першого дня. Набагато складніше ввімкнути після того, як люди звикли без нього.
• Переглядайте доступ щоквартально. Люди змінюють ролі, а дозволи мають тенденцію накопичуватися.
• Негайно деактивуйте колишніх співробітників. Не залишайте акаунти без діла.
• Використовуйте шаблони затвердження для найпоширеніших типів документів — командам не доведеться будувати ланцюжки з нуля.

Усунення несправностей

Користувач не може отримати доступ до командних документів

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

Запрошення не отримано

Перевірте папку спаму. Якщо це корпоративна пошта, їхня IT-команда може фільтрувати листи про підписання. Перевірте адресу та надішліть повторно. Можна також надіслати пряме посилання.

Помилка входу через SSO

Перевірте конфігурацію SAML: entity ID, ACS URL та сертифікат мають точно співпадати. Уточніть у адміністратора вашого постачальника ідентифікації. Найпоширеніша проблема — прострочений сертифікат на стороні IdP.

Що робити далі

• Документи — організація файлів, папок та дозволів
• Підписи — типи підписів та процеси підписання
• API документація — програмне керування командами та користувачами
• Webhooks — отримання сповіщень про події команд та документів
• Безпека — шифрування, контроль доступу та комплаєнс