Data Cloud і Agentforce: що це таке і навіщо вам це знати

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Якщо ви хоч раз відкривали Salesforce-вакансію за останній рік, то, скоріш за все, бачили ці два слова — Data Cloud (or Data Cloud 360) і Agentforce.

Вони є на кожній Dreamforce-презентації, у кожному офіційному блозі, і звучать так, ніби без них Salesforce вже не Salesforce.

Але якщо запитати більшість Salesforce-розробників, що це таке і що саме роблять ці фічі — відповідь найчастіше розмита: «Нуууу......, Data Cloud — це типу CDP, а Agentforce — це AI агенти, ну там чатбот такий, щось типу Ейнштейн ботів».
Я думаю, такі відповіді не тому, що люди не розбираються або не хочуть розібратися, можливо, проблема в тому, що офіційна документація і маркетингові демки Salesforce говорять про все і ні про що одночасно.

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

Data Cloud: уніфікація даних як фундамент

Data Cloud — не просто «ще одне сховище даних». Це data platform всередині Salesforce ecosystem, яка дозволяє підключати дані з різних джерел, моделювати їх через Data Model Objects, уніфікувати профілі клієнтів і використовувати ці дані в CRM, сегментації, аналітиці, автоматизаціях та Agentforce.

Ключове слово тут якраз — уніфікація. Не просто злити рекорди (або ж таблиці) разом в 1, а зрозуміти, що John Smith з CRM, [email protected] з Ons платформи і Jonatan з e-commerce є однією людиною. Саме для цього існує Identity Resolution в Data Cloud.

Ще одна важлива концепція — Zero Copy. Data Cloud може підключатися до зовнішніх Data Warehouse (Snowflake, BigQuery, Databricks, etc.) і читати дані звідти без фізичного переміщення. Дані залишаються там, де вони є, а Salesforce просто їх бачить і може використовувати. Можливо, виникло питання: «Чому не можна просто їх кверити, коли нам потрібно буде? І ніякого клауду тут не потрібно». В цілому можна просто зробити callout до Snowflake і читати, що потрібно. Але є речі, які тоді доведеться вирішувати самому: по-перше, Salesforce не знатиме, що customer_id=48291 зі Snowflake і Contact з CRM — це та сама людина, і буде дублювати їх. По-друге, ніякого контролю над тим, хто що бачить, маскування PII, audit trail і т. д. Все це треба будувати окремо. Data Cloud дає для цього нативні механізми платформи, але їх все одно треба правильно налаштувати.

Кейс 1: Клієнт у трьох системах

Типова ситуація для mid-market і enterprise: CRM у Salesforce, e-commerce на окремій платформі, маркетингові розсилки в HubSpot або Marketo. Клієнт існує в кожній із систем окремо — з різними ID, інколи з різними email-адресами. Data Cloud підключається до кожного джерела через Data Streams, нормалізує дані до Data Model Objects і запускає Identity Resolution. Результат — Unified Individual: профіль, який повʼязує записи з різних джерел. Але важливо: потрібно налаштувати match rules і reconciliation rules, і саме вони визначають, які записи обʼєднуються та які значення полів мають пріоритет.

Практична цінність: агент в системі і agentforce агент бачать не тільки CRM-історію, а й останні замовлення з e-commerce і email-активність клієнта. На одному екрані ви можете бачити повну картину про клієнта.

Кейс 2: Prediction

На одному з проєктів була задача — передбачити, коли конкретний клієнт буде потребувати якийсь продукт (сировина) і знову робитиме замовлення, щоб сейли могли проактивно виходити на зв’язок у потрібний момент, а не чекати інбаунд. Тут ідеально вписалася Prediction Model. Ми взяли історичні дані по покупках — дати, обсяги, типи продуктів, територію, etc. — і побудували prediction model через Einstein Studio, який живе всередині Data Cloud. Модель навчалася на патернах: якщо клієнт купував щоквартально з поступово зростаючим обсягом — система присвоювала ймовірність наступної покупки та приблизну дату.

Модель показала R^2 = 0.79, основними предикторами виявились частота покупок і середній обсяг замовлення.

Результатом моделі було прогнозне значення — приблизна кількість днів до моменту, коли клієнту знову знадобиться товар. Далі цей результат можна було зберігати як атрибут, використовувати в сегментації, показувати сейлам (вони отримували список «клієнтів з найвищою ймовірністю покупки цього місяця» автоматично) у CRM або передавати як контекст для Agentforce

Важливий нюанс: якість prediction напряму залежить від якості, глибини даних та ваших навичок в аналізі даних. Якщо клієнт має 2 транзакції в системі підряд — модель нічого корисного не видасть. Це не рокет саєнс, це проста статистика.

Кейс 3: Zero Copy з Data Warehouse

Якщо у компанії є Snowflake або BigQuery з роками аналітичних даних — переносити це все в Salesforce ніхто не хоче. Це дорого, дуже дорого, повільно і ризиковано через ймовірність великої кількості дублікатів. Zero Copy вирішує це: Data Cloud підключається до Snowflake через Federated Query і дані стають доступними для сегментації та agenforce агентів без копіювання.

Для бізнесу це означає, що можна взяти 5 років транзакційної аналітики і відразу задіяти їх в AI-фічах Salesforce без ETL-пекла. А технічно це просто Data Stream, потім мапінг даних до своєї моделі, і вони стають частиною Unified Profile.

Agentforce: агенти як нові автоматизації

Важливо одразу розмежувати: агент у розумінні Salesforce — це не просто чатбот з відповідями по скрипту і не ще один Flow.

Чатбот — це if/else за ключовими словами, а Flow — жорстка послідовність кроків.
Агент — це LLM (Atlas Reasoning Engine під капотом), який отримує мету, самостійно планує кроки, викликає потрібні інструменти і приймає рішення в процесі. Він може зупинитися, перепитати, обрати інший шлях залежно від контексту.

Архітектурно агент складається з Topics (умовний контейнер, який вміщує всі інструкції і Actions якоїсь задачі), Actions (що він може робити і що для цього використовувати (Flows, Apex, API callouts)) і Instructions (як себе вести). Все конфігурується в білдері (Agent Builder) без коду, хоча під капотом можна підключати будь-яку кастомну логіку.

Кейс 1: Автоматичне створення квот з інбаунд email

Це один із найбільш практичних кейсів, який я реалізував. Задача: клієнти надсилали email з запитом на комерційну пропозицію. Раніше сейл вручну читав email, шукав клієнта в системі, створював Ліда,Opportunity і Quote з відповідними продуктами. Монотонна робота, яка займала 15-20 хвилин на кожен запит.

Рішення: Email-to-Case роутив інбаунд листи на агента. Агент читав body листа, витягував назви продуктів і обсяги, шукав відповідного Contact і Account через Action-запит , перевіряв, чи існує відкритий Lead або Opportunity для цього клієнта. Якщо ні — створював Lead або Opportunity залежно від статусу клієнта. Після — створював Quote з Quote Line Items на основі того, що запросив клієнт в email. (я використовував Apex екшини, але це можна і Flow-вами)

Важливо те, що agentforce агент не просто витягував дані — він приймав рішення. Якщо клієнт запитував продукт, якого немає в каталозі, — агент позначав це як «requires human review» і передавав сейлзу з контекстом. Якщо дані були неоднозначні — перепитував. Повна автономія тільки для чітких випадків.

Результат: 80%+ запитів оброблялися без участі людини. Сейл бачив готову квоту і просто підтверджував або коригував.

Кейс 2: FAQ агент з fallback на веб-пошук

Задача: оператори сервісної команди часто отримували питання, на які відповідей в CRM не було — технічні специфікації, регуляторні вимоги, нюанси продуктів.

Agentforce агент працював за двоступеневою логікою. Спочатку шукав відповідь в Salesforce Knowledge Articles — це основне джерело. Якщо Knowledge не давав релевантної відповіді, fallback action викликав prompt template, який був grounded через web retriever і повертав відповідь із джерелами.

Щоб структурувати відповідь агента, і робити її більш user friendly, використав Custom Lightning Type в Agentforce Actions — визначаєш поля які агент повинен повернути, і він відповідає за цією структурою, а не просто вільним текстом. Парсили це через Apex.

Результат: оператор отримував структуровану відповідь з джерелом, незалежно від того чи вона прийшла з Knowledge чи з веб.

Кейс 3: CV parsing

Задача: рекрутери вручну переносили дані з CV в Salesforce — ім’я, контакти, досвід, посада. Монотонно і з помилками.

Рішення: простий інтерфейс з input placeholder, куди юзер перетягував CV. Далі agentforce агент парсив документ, витягував релевантні поля і автоматично створював рекорд в Salesforce з відповідними заповненими полями.

Ніякого ручного введення — юзер перетягнув файл, отримав готовий запис.

(Стара демка)

Як вони працюють разом — і коли це реально потрібно

Agentforce може працювати без Data Cloud — і для багатьох кейсів цього достатньо. Звичайний Prompt + Flow + Apex callout закриває більшість потреб. Не треба одразу тягнути Data Cloud якщо задача не вимагає уніфікації даних або ML-predictions.

Але є клас задач де без Data Cloud агент працює в темряві. Найкращий приклад це персоналізований сервісний агент. Якщо він бачить тільки CRM-дані, він не знає що цей клієнт вчора зробив замовлення на e-commerce, що він з’явився в переліку «ризик відтоку» за prediction моделлю, що його email-активність впала за останній місяць. Data Cloud вирішує це: агент отримує доступ до Unified Profile і використовує всі уніфіковані дані як контекст. Технічно — RAG (Retrieval Augmented Generation), і тому коли агент не «знає» відповідь, він шукає релевантні дані і будує відповідь на їх основі.

Простий спосіб думати про це: Data Cloud — це пам’ять агента. Без нього агент розумний, але «звʼязаний», а з — знає все, що компанія знає про клієнта.

Де вже норм використовувати, а де ще не варто

Agentforce для автоматизації конкретних, добре окреслених процесів — вже production-ready. Кейс з email-to-quote працює, економить час, агент стабільно справляється з більшістю запитів. Якщо є чіткий процес, чіткі дані і чітке розуміння, коли агент повинен ескалювати — беріть і робіть.

Agentforce для складних, багатокрокових завдань з великою кількістю контексту — тут треба бути обережним. CTO Agentforce відкрито говорила: чим більше інструкцій і дій в одному контексті, тим вища ймовірність непередбачуваної поведінки. Моя практична рекомендація — писати не більше 8 інструкцій на Topic, бо це реальне обмеження, яке впливає на архітектурні рішення.

Сам Data Cloud є продуктом з великим потенціалом, але він ще «росте». Особисто провів не один вечір у Salesforce Support через баги на їхній стороні, навіть зараз, коли вже стільки часу пройшло від його релізу. Identity Resolution може поводитися несподівано на нестандартних даних. Деякі коннектори ще обмежені у функціональності.

Ціна — окреме питання. Data Cloud ліцензується окремо і коштує серйозних грошей. Перед тим як продавати це бізнесу рахуйте ROI конкретно, не абстрактно. «Уніфікований профіль клієнта» звучить добре, але що саме це дасть вашому бізнесу і за скільки?

Data Cloud і Agentforce — це не черговий ребрендинг існуючих фіч. Це дійсно новий рівень того, що можна зробити на платформі Salesforce. Але як і будь-яка технологія, вони вимагають розуміння: коли це підходить, а коли це overkill.

Якщо ви Salesforce-розробник — варто починати з Agentforce. Developer Edition тепер включає обидва продукти безкоштовно, є sample app Coral Cloud з реальними прикладами. Це найшвидший спосіб зрозуміти, що до чого.

Якщо у вас є свій досвід з цими продуктами або питання — пишіть у коментарях. Ця тема ще активно розвивається, і колективний досвід спільноти тут важливіший за будь-яку офіційну документацію.