Регистрация  |  Вход

Как много емейлов можно отправить через один вызов Messaging.sendEmail(List<Messaging.SingleEmailMessage>)?

Речь идет о том, чтобы за один run context отправить 1-2-3 тысячи емейлов.

изучаю емейл лимиты. Вижу 5000 емейлов в день на орг, вижу лимит не более 10 вызовов Messaging.sendEmail() за один run context.

Но как много емейлов можно отправить через один вызов Messaging.sendEmail(List<Messaging.SingleEmailMessage>)? не могу найти ясного ответа... а это важный момент

также еще всплыли любопытные вопросы:

- а сколько емейл адресов можно заложить в toRecipients при создании Messaging.SingleEmailMessage?

- если я закладываю в один Messaging.SingleEmailMessage 10 получателей, после отправки это будет засчитано как один отправленный емейл или десять ?

спасибо

Речь идет о том, чтобы за один run context отправить 1-2-3 тысячи емейлов.

изучаю емейл лимиты. Вижу 5000 емейлов в день на орг, вижу лимит не более 10 вызовов Messaging.sendEmail() за один run context.

Но как много емейлов можно отправить через один вызов Messaging.sendEmail(List<Messaging.SingleEmailMessage>)? не могу найти ясного ответа... а это важный момент

также еще всплыли любопытные вопросы:

- а сколько емейл адресов можно заложить в toRecipients при создании Messaging.SingleEmailMessage?

- если я закладываю в один Messaging.SingleEmailMessage 10 получателей, после отправки это будет засчитано как один отправленный емейл или десять :)  ?

спасибо

Смотря какие это адреса, если внешние адреса на них лимит который ты указал. Он еще может зависеть от количества купленных лицензий.

Смотря какие это адреса, если внешние адреса на них лимит который ты указал. Он еще может зависеть от количества купленных лицензий.

Den Brown
Messaging.SingleEmailMessage

По лимитам не подскажу, но если нужно реально спамить (слать много емейлов) то лучше посмотреть в сторону сервисов типа MailGun
B еще как вариант с точки зрения безопасности в To/CC (не знаю как на счет BCC) ставить ограниченное (в идеале 1) кол-во получателей. Были интересные примеры из жизни когда новогодние поздравления делали одним письмом и в TO вставляли ВСЕХ работников компании. Малочь, а таким образом отлично раскрывается структура компании и сливаются спам базы. В твоем случае рискуешь слить email всех контактов или кого ты там решил спамить. Поэтому только N отдельных emails на N адресатов.

[quote="Den Brown"]Messaging.SingleEmailMessage[/quote]
По лимитам не подскажу, но если нужно реально спамить (слать много емейлов) то лучше посмотреть в сторону сервисов типа [url=https://www.mailgun.com/]MailGun[/url]
B еще как вариант с точки зрения безопасности в To/CC (не знаю как на счет BCC) ставить ограниченное (в идеале 1) кол-во получателей. Были интересные примеры из жизни когда новогодние поздравления делали одним письмом и в TO вставляли ВСЕХ работников компании. Малочь, а таким образом отлично раскрывается структура компании и сливаются спам базы. В твоем случае рискуешь слить email всех контактов или кого ты там решил спамить. Поэтому только N отдельных emails на N адресатов.

OK,

потестил SF emailing limits немного, вот результаты:

(1) Messaging.sendEmail(List<Messaging.SingleEmailMessage>) может отправить 400, и 500, и 2500 емелов за раз, и вероятно любое количество в пределах оставшегося дневного общего лимита на SingleEmail.
Время работы кода при отправке 2500 сообщений составило около минуты, это при простейших, пустых емейлах, а если в реальности там используются емейлы на основе Темплейтов, то время будет больше, и есть вероятность стукнуть таймаут или хипсайз лимит. Вероятно, лучше такую задачу "отстреливать" в асинхронный будущий процесс

(2) в поле email.setToAddresses() можно положить до 98 (большее я не тестировал) адресов

(3) все адреса в Messaging.SingleEmailMessage.setToAddresses работают против дневного лимита как отдельно отправленный емейл. То есть нет смысла набивать в SingleEmailMessage.setToAddresses адреса в надежде, что один SingleEmailMessage объект будет засчитал как один отправленный емейл в плане лимитов. Кроме того, как указал Дмитрий, нужно очень обдуманно добавлять адресса на один SingleEmailMessage, понимая, что все они будут видимы для каждого получателя емейла отправленного этим объектом. Тем не менее все же есть некоторый смысл создавать такие "общие" емейлы, когда это позволительно, так как это сокращает кол-во созданный объектов и т.д.

(4) также, читал, что якобы если использовать поле email.setTargetObjectId() при создания SingleEmailMessage (обычно это делается при использовании Темплета) этот емейл не будет засчитан против дневного лимитов. Это не правда, он засчитывается. Возможно это правило работает только для внутренних емейлов и/или со специфичными типами объектов, чьи АйДи используются в setTargetObjectId

не стал изучать MassEmailMessage, возможно в нем есть какие то преимущества

также не изучил как именно число купленных лицензий отражается на дневном общем лимите на SingleEmail, так как обычный 5000 лимит пока устраивает

OK,

потестил SF emailing limits немного, вот результаты:

(1) Messaging.sendEmail(List<Messaging.SingleEmailMessage>) может отправить 400, и 500, и 2500 емелов за раз, и вероятно любое количество в пределах оставшегося дневного общего лимита на SingleEmail.
Время работы кода при отправке 2500 сообщений составило около минуты, это при простейших, пустых емейлах, а если в реальности там используются емейлы на основе Темплейтов, то время будет больше, и есть вероятность стукнуть таймаут или хипсайз лимит. Вероятно, лучше такую задачу "отстреливать" в асинхронный будущий процесс

(2) в поле email.setToAddresses() можно положить до 98 (большее я не тестировал) адресов

(3) все адреса в Messaging.SingleEmailMessage.setToAddresses работают против дневного лимита как отдельно отправленный емейл. То есть нет смысла набивать в SingleEmailMessage.setToAddresses адреса в надежде, что один SingleEmailMessage объект будет засчитал как один отправленный емейл в плане лимитов. Кроме того, как указал Дмитрий, нужно очень обдуманно добавлять адресса на один SingleEmailMessage, понимая, что все они будут видимы для каждого получателя емейла отправленного этим объектом. Тем не менее все же есть некоторый смысл создавать такие "общие" емейлы, когда это позволительно, так как это сокращает кол-во созданный объектов и т.д.

(4) также, читал, что якобы если использовать поле email.setTargetObjectId() при создания SingleEmailMessage (обычно это делается при использовании Темплета) этот емейл не будет засчитан против дневного лимитов. Это не правда, он засчитывается. Возможно это правило работает только для внутренних емейлов и/или со специфичными типами объектов, чьи АйДи используются в setTargetObjectId

не стал изучать MassEmailMessage, возможно в нем есть какие то преимущества

также не изучил как именно число купленных лицензий отражается на дневном общем лимите на SingleEmail, так как обычный 5000 лимит пока устраивает

 

При использовании Workflow Rule with Email Alert, лимит намного больше:

The daily limit for emails sent through email alerts is 1,000 per standard Salesforce license per org
(except for free Developer Edition), where the daily workflow email limit is 15.

The overall org limit is 2,000,000.

This limit applies to emails sent through email alerts in workflow rules, approval processes, flows, processes, or the REST API.

При использовании Workflow Rule with Email Alert, лимит намного больше:

The daily limit for emails sent through email alerts is 1,000 per standard Salesforce license per org 
(except for free Developer Edition), where the daily workflow email limit is 15. 

The overall org limit is [b]2,000,000[/b]. 

This limit applies to emails sent through email alerts in workflow rules, approval processes, flows, processes, or the REST API.

Eric
При использовании Workflow Rule with Email Alert, лимит намного больше:

вот это тоже очень хорошо знать, здесь видно какую роль играют лицензии.

понятно, что апекс емейлинг используется когда с помощью Workflow Rule with Email Alert не решить задачу, например емейлы находятся далеко от записи вызывающей Workflow Rule, да еще их выбрать нужно с условием

[quote="Eric"]При использовании Workflow Rule with Email Alert, лимит намного больше:[/quote]

вот это тоже очень хорошо знать, здесь видно какую роль играют лицензии.

понятно, что апекс емейлинг используется когда с помощью Workflow Rule with Email Alert не решить задачу, например емейлы находятся далеко от записи вызывающей Workflow Rule, да еще их выбрать нужно с условием

Ну можно же по какой-то галка на записи посылать мыло, если нет кучи всяких агрегаций.

Ну можно же по какой-то галка на записи посылать мыло, если нет кучи всяких агрегаций.

Den Brown
также, читал, что якобы если использовать поле email.setTargetObjectId() при создания SingleEmailMessage (обычно это делается при использовании Темплета) этот емейл не будет засчитан против дневного лимитов. Это не правда, он засчитывается. Возможно это правило работает только для внутренних емейлов и/или со специфичными типами объектов, чьи АйДи используются в setTargetObjectId

Это относится к Id юзеров, т.к. за них платят деньги, покупая лицензии. При отправке на тот же контакт лимиты будут считаться.

setTargetObjectId(targetObjectId)
Required if using a template, optional otherwise. The ID of the contact, lead, or user to which the email will be sent. The ID you specify sets the context and ensures that merge fields in the template contain the correct data.

[quote="Den Brown"]также, читал, что якобы если использовать поле email.setTargetObjectId() при создания SingleEmailMessage (обычно это делается при использовании Темплета) этот емейл не будет засчитан против дневного лимитов. Это не правда, он засчитывается. Возможно это правило работает только для внутренних емейлов и/или со специфичными типами объектов, чьи АйДи используются в setTargetObjectId[/quote]

Это относится к Id юзеров, т.к. за них платят деньги, покупая лицензии. При отправке на тот же контакт лимиты будут считаться.

[quote]
setTargetObjectId(targetObjectId)
Required if using a template, optional otherwise. The ID of the contact, lead, or user to which the email will be sent. The ID you specify sets the context and ensures that merge fields in the template contain the correct data.
[/quote]

Developer
Это относится к Id юзеров, т.к. за них платят деньги, покупая лицензии. При отправке на тот же контакт лимиты будут считаться.

резонно

Gres
Ну можно же по какой-то галка на записи посылать мыло, если нет кучи всяких агрегаций.

событие отправки емейл происходит на одном объекте, а емейл адрес лежит на пару уровней выше (поднимаемся до Account) и потом на уровень ниже объекте (Contact). В теории можно все это реалиpоваnь с помощью WorkFlow Rule&Actions: с начального объекта чекнуть флаг на его родителе, оттуда на следущем уровне, оттуда флаг вытягивается на дочерние записи с помошью формулы и WorkFlow Rule проверят условие и вызывает отправку емейла.

Но в таких случаях всегда возникает вопрос: лучше решить все это с помощью одного тригера или с помощью 10 WorkFlow Rule&Actions и 5 новых полей? Тригер выглядит предпочтительнее

Другое дело, что сейчас выяснилось, что WorkFlow емейлинг имеет значительно большие лимиты чем Апекс емейлинг, а это может иметь значение

[quote="Developer"]Это относится к Id юзеров, т.к. за них платят деньги, покупая лицензии. При отправке на тот же контакт лимиты будут считаться.[/quote]
резонно

[quote="Gres"]Ну можно же по какой-то галка на записи посылать мыло, если нет кучи всяких агрегаций.[/quote]

событие отправки емейл происходит на одном объекте, а емейл адрес лежит на пару уровней выше (поднимаемся до Account) и потом на уровень ниже объекте (Contact). В теории можно все это реалиpоваnь с помощью WorkFlow Rule&Actions: с начального объекта чекнуть флаг на его родителе, оттуда на следущем уровне, оттуда флаг вытягивается на дочерние записи с помошью формулы и WorkFlow Rule проверят условие и вызывает отправку емейла.

Но в таких случаях всегда возникает вопрос: лучше решить все это с помощью одного тригера или с помощью 10 WorkFlow Rule&Actions и 5 новых полей? Тригер выглядит предпочтительнее

Другое дело, что сейчас выяснилось, что WorkFlow емейлинг имеет значительно большие лимиты чем Апекс емейлинг, а это может иметь значение