Salesforce archival strategy

Salesforce archival strategy

Какую стратегию для архивирования старых записей вы используете?
На орге у клиента заканчивается свободное место для обьектов. Нужно это как-то решать))
Удалить безвозвратно много записей не получится.
Я вижу такие варианты:
1) Создать новый обьект и слить в одну запись несколько записей (10 или 100 или 1000), а оригинал удалить.
2) Выгрузить записи во внешнюю БД и отображать в СФ через external object
3) Использовать Big Object. Продублировать ненужные записи в big object, а оригинальные удалить.
Какие варианты я упустил? Поделитесь своим опытом решения подобных проблем.

Либо Big Object
Либо ownbackup.com – но там гораздо больше чем backup.

есть разные решения:
зависит от бюджета клиента, есть ли в использовании какието продукты on prem,
Hадо ли чтоб был доступ из SF (поиск, UI) или достаточно только чтоб данные были сохранены для Audit проверки или если надо найти данные, без того есть прямой доступ из Salesforce

Варианты:
1. Купить storage (временное решение)
2. BigObject (зависит от того сколько объектов над архивировать, цена кажется пер BigObject)
3. Heroku + Heroku Connect
4. OwnBackup (они добавили это где то год назад) - Оптимальный вариант если если есть бюджет и надо запустить быстро и без усилий
5. Сделать свой Custom Archive - ETL переписывать данные в локальную ДБ и стирать из Salesforce

Eric
1. Купить storage (временное решение)
В Salesforce? Дороговато будет.
Eric
Heroku Connect
Не для архивации данных (можно, конечно, выпендрится, и триггером/джобом выбирать новые данные и экспортировать в файлы на, том же, Amazon–е...
Eric
OwnBackup
Очень навороченное решение, много возможностей.
Eric
свой Custom Archive
Зависит от объёма данных и сложности схемы. В OwnBackup всё это уже решено.

Если не нужен постоянный доступ к устаревшим данным, то проще выгружать пачками в виде JSON во внешнее хранилище. К примеру так делают большенство сервисов для логирования. Актуальные данные доступны для поиска и обработки скажем в пределах последнего месяца, а устаревшие уже в виде zip-архивов.
Если нужен какой-то процессинг по всем данным, то я бы колхозил что-то свое на внешнем сервере (DB + API) сливал туда устаревшие данные и предоставлял API для работы с ними а на SF прокладку для работы с этим API.
Как показывает практика свое решение хоть и дольше но гибче (можно дорабатывать и развивать) и дешевле в долгой перспективе. Но если клиент разовый и маленький то лучше предложить готовое решение из существующих на рынке и скинуть с себя ответственность за эту тему.

Eric
4. OwnBackup (они добавили это где то год назад) - Оптимальный вариант если если есть бюджет и надо запустить быстро и без усилий

Про OwnBackup не слышал. Спасибо за наводку! Пригодится

Хорошая тема

Dmitry Shnyrev
Как показывает практика свое решение хоть и дольше но гибче (можно дорабатывать и развивать) и дешевле в долгой перспективе.

смотря что за данные там, если что-то "персональное", то лучше не связываться, а сразу предлагать решения "из коробки", от греха подальше...

Interesting information? Help us, post link to social media..