Introducion
The growing need to automate email communications, sourced in Salesforce, leads to a point where, in the same organization, these submissions can be made in the context of different processes, with different message models and distinct recipient structures.
In this sense, it becomes crucial to find a solution that is versatile enough to address this multiplicity of hypotheses, especially in cases where they coexist. While there are a few ways to automate sending emails in Salesforce using no-code solutions, none of them offer as many options as sending via Apex.
The purpose of this article is to show some of the potentialities of Apex's Outbound Email module, as well as mentioning some methods that can be used for the construction, definition and sending of email messages.
Message construction
Message construction starts with instantiation of an email object which will record all parameterizations and will be sent at the end of the process:
The Subject and Body of the Message, the latter with the possibility of having text and HTML versions, can be defined using the following methods:
Alternatively, and to cover the most common scenarios, there is also the possibility of using a template available in Salesforce, whether standard or custom. To this end, can be used the renderStoredEmailTemplate method of the class Messaging.
Alternatively, the following methods may also be used:
In any of the approaches, the following parameters should be passed as input:
- templateId – Template Id defined in Salesforce;
- targetObjectId – typically is the Id of a Lead or Contact record, being used to fill fields in the template;
- whatId – is typically the Registration Id of an Account or an Opportunity, being used to fill fields in the template.
Definition of recipients
With regard to the definition of recipients, the three commonly used types are available (To, Cc and Bcc) and can be defined using the following methods, who receive strings lists as input:
Sender
By default, the sender of the email is the user who invokes the method that will send the email. In this sense, in the From field, the name and email address associated with it will be used.
However, it is possible to change this behavior, through the parameterization and use of Organization-Wide Email Addresses, where names and email addresses are defined that can be used as senders.
In this way it is possible to make available a set of emails that can be used as senders, using the method setOrgWideEmailAddressId, who will receive as input the desired Email Address Id (object OrgWideEmailAddress).
If the purpose is only to set the name indicated on the sender, this can also be done.
In cases where the sender is to be placed in Bcc the following method should be used:
Additional parameterizations
To set the email address used when recipients reply to the message the following method should be used:
If the user sending the email has set an email signature in Salesforce, it will be included by default in the message. To prevent this from happening, if necessary, invoke the method setUseSignature, passing false as input.
After sending the email, will be registered an Activity associated with the registration referring to the targetObjectId, if it has been defined. If this is not the desired behavior, the following method should be invoked with the false input:
Message sending
To send the message, it will be necessary to invoke the method Messaging.sendEmail, which receives as input a list of the type Messaging.SingleEmailMessage, allowing the sending of several emails simultaneously, and optionally a boolean that allows defining whether the process should be aborted if an error occurs in sending an email (true) or whether to process the sending of the remaining (false).
As output, the Messaging.sendEmail method, receives the result submission process for eventual analysis.
Conclusion
Considering the methods and functionalities referred to in this short article, easily identify some that are not available in no-code solutions, making the Apex Outbound Email module an option to consider whenever it is necessary to implement something where complexity justifies it.
Through a few lines of code, a class can be developed which includes a method for processing emails that, being exposed, can be invoked in any context. Additionally, this component can be combined with the use of Custom Metadata where you can, among other things, set a map of combinations which, for example, identify the template to be used in each circumstance. In this way, it is possible to build a very complete and scalable solution for cases where automatic sending of emails has a significant weight in the operation and is characterized by specificities that are not covered, entirely, by using Flows.
References
- Salesforce Developer: Outbound Email
- Salesforce Developer: SingleEmailMessage Methods
- Salesforce Developer: Email Class
- Salesforce Developer: Messaging Class
#Salesforce #wordIT #outboundemail #emailleadgeneration #Salesforcepartner