Поділитися через


Злиття даних

Можна об’єднати два записи, щоб об’єднати дані, або видалити повтори. Після виконання злиття ознайомтеся з розділом Дотримання безпеки, щоб переконатися, що такі зміни відповідають вимогам безпеки. Можна злити таблиці «Бізнес-партнер», «Контактна особа» та «Потенційний клієнт».

Виконайте такі дії для злиття даних.

  1. Виберіть записи, які потрібно злити (наприклад, записи бізнес-партнерів), а потім натисніть кнопку Злиття.

    Виберіть і об’єднайте облікові записи.

  2. Виберіть основний запис, а потім виберіть поля для злиття в основному записі та натисніть кнопку OK.

    Виберіть записи, які потрібно об’єднати.

    Нотатка

    Основний запис успадкує всі дочірні записи залежного запису. Залежний запис буде деактивовано.

Додаткові відомості див. в розділі Об’єднайте повторювані записи для бізнес-партнерів, контактних осіб і потенційних клієнтів.

Дотримання безпеки

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

Сценарії

Приклад настройок, що використовуються в сценаріях

У наведених нижче сценаріях використовуються такі приклади настройок.

  • Таблиця облікових записів: використовується для демонстрації злиття записів.

  • Користувач перший: зразок користувача.

  • Користувач другий: зразок користувача.

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

    роль безпеки привілеїв облікового запису.

  • Тестовий обліковий запис перший: головний обліковий запис для об’єднання. Користувача 1 призначено для цього бізнес-партнера.

  • Тестовий рахунок другий: підпорядкований рахунок, який об’єднується в. Користувача 2 призначено для цього бізнес-партнера.

Сценарій #1: злиття записів, за які відповідають користувачі

Сценарій

  • Користувач 1 відповідає за тестового бізнес-партнера 1
  • Користувач 2 відповідає за тестового бізнес-партнера 2
  • Тестовий бізнес-партнер 1 (основний бізнес-партнер) був об’єднаний з тестовим бізнес-партнером 2 (залежним бізнес-партнером)

Після злиття записів:

Користувач перший

  • Має доступ до:
    • об’єднаного запису головного бізнес-партнера – тестовий бізнес-партнер 1

Користувач другий

  • Має доступ до:
    • об’єднаного запису головного бізнес-партнера – тестовий бізнес-партнер 1
    • неактивного бізнес-партнера (лише для читання) – тестовий бізнес-партнер 2

    Доступ до облікових записів.

Сценарій #2: злиття записів, до яких надається спільний доступ користувачам

Сценарій

  • Користувач 1 надав спільний доступ до тестового бізнес-партнера 1 Користувачу 2
  • Користувач 2 надав спільний доступ до тестового бізнес-партнера 2 Користувачу 1
  • Тестовий бізнес-партнер 1 (основний бізнес-партнер) був об’єднаний з тестовим бізнес-партнером 2 (залежним бізнес-партнером)

Після злиття записів:

Користувач перший

  • Має доступ до:
    • об’єднаного запису головного бізнес-партнера – тестовий бізнес-партнер 1
    • неактивного бізнес-партнера (лише для читання) – тестовий бізнес-партнер 2

Користувач другий

  • Має доступ до:
    • об’єднаного запису головного бізнес-партнера – тестовий бізнес-партнер 1
    • неактивного бізнес-партнера (лише для читання) – тестовий бізнес-партнер 2

Сценарій #3: злиття записів, до яких надається спільний доступ учасникам робочої групи доступу

Сценарій

  • Користувач 1 є членом автоматично створеної групи доступу до бізнес-партнера
  • Користувач 2 є членом автоматично створеної групи доступу до бізнес-партнера
  • Тестовий бізнес-партнер 1 (основний бізнес-партнер) був об’єднаний з тестовим бізнес-партнером 2 (залежним бізнес-партнером)

Додаткові відомості про робочі групи доступу див. в розділі Відомості про робочі групи та шаблони робочої групи.

Після злиття записів:

Користувач перший

  • Має доступ до:
    • об’єднаного запису головного бізнес-партнера – тестовий бізнес-партнер 1

Користувач другий

  • Має доступ до:
    • об’єднаного запису головного бізнес-партнера – тестовий бізнес-партнер 1
    • неактивного бізнес-партнера (лише для читання) – тестовий бізнес-партнер 2

    Доступ до облікових записів.

  • Користувач 2 не додається як член робочої групи доступу до бізнес-партнера (вкладена сітка) на тестовому бізнес-партнері 1

    Підgrid у формі облікового запису.

Сценарій #4: злиття записів, за які відповідають робочі групи

Сценарій

  • Користувач 1 є учасником відповідальної робочої групи 1
  • Користувач 2 є учасником відповідальної робочої групи 2
  • Тестовий бізнес-партнер 1 (основний бізнес-партнер) був об’єднаний з тестовим бізнес-партнером 2 (залежним бізнес-партнером)

Додаткові відомості про відповідальні робочі групи див. в розділі Відомості про відповідальні робочі групи.

Після злиття записів:

Користувач перший

  • Має доступ до:
    • об’єднаного запису головного бізнес-партнера – тестовий бізнес-партнер 1

Користувач другий

  • Має доступ до:
    • об’єднаного запису головного бізнес-партнера – тестовий бізнес-партнер 1
    • Неактивний бізнес-партнера (лише для читання)—– тестовий бізнес-партнер 2

      Доступ до облікових записів.

  • Користувач 2 не додається до відповідальної робочої групи 1

    Члени команди власників.

Зміна поведінки злиття

За допомогою засобу OrgDBOrgSettings можна змінювати настройки бази даних, які регулюють поведінку параметрів за замовчуванням. За допомогою цього засобу можна змінити параметри доступу для записів основного або залежного бізнес-партнера. Для цього використовуються такі параметри:

  • GrantFullAccessForMergeToMasterOwner
  • GrantSharedAccessForMergeToSubordinateOwner

Для отримання додаткових відомостей див. розділ Настройки бази даних середовища.