Все чаще и чаще сталкиваюсь с лимитом Compiled formula size: 5,000 characters
из-за него приходится перебивать АПИ имена полей на более короткие (когда это возможно) или вообще отказываться от формулы.
был бы лимит на количество операторов в формуле, это было бы как то понятно, а тут просто на физический размер написания формулы. Ну зачем им было людям проблемы создавать на ровном месте...
PS: вообще-то я ошибся, сокращение длины названия поля никак не помогает, придется идти другим путем
PSS: пришлось сокращать количество условий в формуле
вот такая формула получилась:
IF(Field > 40 || Field <= 0,'',
IF(Field > 32, '1. Отлично',
IF(Field > 24, '2. Хорошо',
IF(Field > 16, '3. Пойдет',
IF(Field > 8, '4. Так себе',
IF(Field > 0, '5. Не годится',''))))))
хотя в начале я сделал диапазон значений для каждого вариант, что выглядело более читаемо, например так:
IF(Field <= 32 && Field > 24, '2. Хорошо',
Более того, если в формуле поля 1 используется формульное поле 2, - длина формулы поля 1 увеличивается на длину формулы поля 2
Может лучше сразу перейти на триггеры и заниматься сложной калькуляцией на инсерт/апдейт? И голова меньше болеть будет у тех кто придет потом и будет с этими трехэтажными формулами разбираться. А еще можно тестами покрыть логику в триггере и быть уверенным что все работает а не вроде работает.
Помню когда только только начинал работать с SF у нас на фирме был FORMULA-man который настолько отточил свои навыки в формула писании что просто жесть. А еще скрипт сделал для минификации формулы чтобы впихнуть пару лишних символов. Вот это было знатное извращение. Вспоминаю сейчас и в голове один вопрос - Нафуя!
ситуации разные бывают.
для несложного, не часто используемого приложения, в котором каждый год нужно немного менять логику, лучше заложить всю логику в формулы. В таком случае те кто на поддержке в Проде сами могут в логике разобраться и апдатировать. А если все "захардкодено", они к тебе каждый раз будут прибегать за добром советом, а вот это тебе не нужно, от слова "совсем".
я использую формулы, связываю их через простые поля- "мостики", в тригере только перетаскиваю данные из "на грани лимита" формульного поля в поле-мостик, а от него новая формула, с новыми лимитами, продолжает работу.
Как-то ты не правильно рассуждаешь! 
Во-первых НИКОГДА, НИКОГДА нельзя давать клиенту менять бизнес логику. Он поменял, сломал, а повесит на тебя. Понятно что можно будет легко отмазаться, но следующим вопросом будет "а какого хрена ты великий разработчик не предусмотрел что я смогу поменять и сломать логику и не сделал какие-нибудь проверки и защиту от дурака?" Источник правды для любого проекта должен быть один - git репозиторий. А если клиенты на проде будут что-то менять в формулах - удачное будущее будет у этого проекта. Хотя такие проекты и проектами назвать нельзя.
Во-вторых, клиента нужно сажать на иглу чтобы он каждый раз возвращался и возвращался к тебе и нес тебе деньги. Если ты делаешь проект и НЕ оговариваешь его приемку и поддержку, то это минимум странно. Неужели к тебе клиенты и через год ходят бесплатно за советом?
Имхо все просто. Делаешь проект без какой-либо возможности клиенту влезть в него и по возможности сделать это сложным для школьников. Сдаешь его в срок клиенту и предлагаешь за определенную плату поддержку проекта (это значит правишь баги и вносишь минимальные правки в рамках этой поддержки). Если клиент не хочет платить за поддержку фиксированную сумму, то любые вопросы, требования, наезды исключительно через ТЗ+оценку+оплату. Если проект хороший, перспективный то клиент по-любому будет и должен к тебе возвращаться и ПЛАТИТЬ.
