Либо Big Object
Либо ownbackup.com – но там гораздо больше чем backup.
Salesforce archival strategy
Какую стратегию для архивирования старых записей вы используете?
На орге у клиента заканчивается свободное место для обьектов. Нужно это как-то решать))
Удалить безвозвратно много записей не получится.
Я вижу такие варианты:
1) Создать новый обьект и слить в одну запись несколько записей (10 или 100 или 1000), а оригинал удалить.
2) Выгрузить записи во внешнюю БД и отображать в СФ через external object
3) Использовать Big Object. Продублировать ненужные записи в big object, а оригинальные удалить.
Какие варианты я упустил? Поделитесь своим опытом решения подобных проблем.
Re: Salesforce archival strategy
Re: Salesforce archival strategy
есть разные решения:
зависит от бюджета клиента, есть ли в использовании какието продукты on prem,
Hадо ли чтоб был доступ из SF (поиск, UI) или достаточно только чтоб данные были сохранены для Audit проверки или если надо найти данные, без того есть прямой доступ из Salesforce
Варианты:
1. Купить storage (временное решение)
2. BigObject (зависит от того сколько объектов над архивировать, цена кажется пер BigObject)
3. Heroku + Heroku Connect
4. OwnBackup (они добавили это где то год назад) - Оптимальный вариант если если есть бюджет и надо запустить быстро и без усилий
5. Сделать свой Custom Archive - ETL переписывать данные в локальную ДБ и стирать из Salesforce
Re: Salesforce archival strategy
В Salesforce? Дороговато будет.
Не для архивации данных (можно, конечно, выпендрится, и триггером/джобом выбирать новые данные и экспортировать в файлы на, том же, Amazon–е...
Очень навороченное решение, много возможностей.
Зависит от объёма данных и сложности схемы. В OwnBackup всё это уже решено.
Re: Salesforce archival strategy
Если не нужен постоянный доступ к устаревшим данным, то проще выгружать пачками в виде JSON во внешнее хранилище. К примеру так делают большенство сервисов для логирования. Актуальные данные доступны для поиска и обработки скажем в пределах последнего месяца, а устаревшие уже в виде zip-архивов.
Если нужен какой-то процессинг по всем данным, то я бы колхозил что-то свое на внешнем сервере (DB + API) сливал туда устаревшие данные и предоставлял API для работы с ними а на SF прокладку для работы с этим API.
Как показывает практика свое решение хоть и дольше но гибче (можно дорабатывать и развивать) и дешевле в долгой перспективе. Но если клиент разовый и маленький то лучше предложить готовое решение из существующих на рынке и скинуть с себя ответственность за эту тему.
Re: Salesforce archival strategy
Про OwnBackup не слышал. Спасибо за наводку! Пригодится 
Re: Salesforce archival strategy
Хорошая тема
смотря что за данные там, если что-то "персональное", то лучше не связываться, а сразу предлагать решения "из коробки", от греха подальше...
