Monday, January 2, 2017

Quick Tips: All about sending emails from Salesforce (with advanced features)

Emails are still a very essential part of our day to day communication. Be it an internal communication within the organization, or across organizations or between customers and organization, emails are one of the key communication mechanism (let's not debate on pros and cons here). Quite obviously, Salesforce provides various options to send emails to internal and external recipients. In this post I'm trying to cover all the essential points (briefly) involved in sending emails from Salesforce.

Defining Email Templates

First and most important aspect regarding emails is ability to create email templates within Salesforce. This is without doubt one of the most used aspect related to sending emails. Email templates help administrator create pre-defined email templates within Salesforce. This helps in providing business approved and verified templates to system and users. As a result, all outgoing communications are consistent. Also, any correction/ improvement incorporated is automatically available to all it's users. Furthermore, email templates have ability to embed merge fields (values which can be substituted by attributes of given record), for example, automatically populating customer's name and order number on outgoing email.

Salesforce allows creation of three types of email templates:-
  1. Text:- most basic of the options. As name states, it just contains plain text email content. 
  2. Custom (without letterhead):- allows administrators to create email templates using HTML to define beautiful and elegant email templates
  3. HTML (with letterhead):- this is similar to previous option. Administrators can define a letterhead (letterhead defines common email header and footer contents) and compose email template using rich text editor
  4. Visualforce:- most advanced version of email templates. This is created by developers using Visualforce to address most complex email template requirements (for example, generating different UI based on data attributes). It provides developers full control over the email template UI. It also enables developers to dynamically generate attachments (PDF, CSV etc.) along with the email. For e.g. if you want to automatically generate Invoice PDF and send to customer, Visualforce email templates can be really handy
More details email templates will be covered in separate post.

How to Send Emails?

Thankfully, Salesforce provides many ways to send emails from Salesforce and yes, one of them is via code. Interestingly, there are so many configuration based options for sending email that code is really required for specific requirements.

Send Email Manually

Most certainly, the first option is to be able to use an email template; if required, make modification; and then send the email. Emails can be sent from pretty much any standard/ custom object for which "Activities" is enabled.
Usage Scenario: Need to send ad-hoc email to customers

Send Email via Workflow/ Lightning Process builder 

Workflows and Lightning process builder processes are the swiss army knife of automation within Salesforce platform. Certainly, these can be setup to send emails using email templates.
Usage Scenario: Send an email to customer on their birthday or marriage anniversary; workflows/ process builders can be setup to automatically send emails for this scenario.

For more details on Email actions refer Email Alert actions.

Send Email via Flow

Flows provide developers capability to automate processes by create custom user interface along with custom business rules without code. It's definitely a very helpful approach as it helps in creation and maintenance of custom UI. As a possible flow action, developers can send email from a Flow.

For more details on sending emails from Flow read Flow Send Email element.

Send Email via Approval Process

Similar to previous option, Approval processes within Salesforce allows users to send email notification on different approval steps.
Usage Scenario: Send email to each approver upon assignment for approval or want to notify submitting user about acceptance/ rejection of the approval request.

Send Email via Case Escalation Rule

Case escalation rules help organizations escalate cases exceeding Service Level Agreement (SLA). Upon escalation, administrators can configure escalation rules to notify specific users.
Usage Scenario: Notify Customer Service Director upon escalation while assigning escalated case to supervisor.

Send Email for Report/ Dashboard

Sales and customer service managers mostly want to look at weekly/ monthly dashboards for their business needs. Often the expectation is to get the details automatically, without having to login into Salesforce. This can be achieved by scheduling reports/ dashboards (refresh dashboard and email) to be sent via emails.
Usage Scenario: Send Sales pipeline stats to Leadership on weekly basis

Send Email via Apex Code

Last and mighty, Salesforce allows developers to programmatically send emails to customers/ users or any external email ids as well. Being a programmatic approach, this provides maximum control to developers. Developers can control the recipients, email content, attachment etc.
Usage Scenario: Create a custom screen to pull data based on custom filters and email data to customers


There are more feature specific email settings, wherein Salesforce sends email to designated recipients (mostly internal) for example, assignment rules, contract expiration notifications, chatter etc.

Advanced features


Send Email using common mailbox a.k.a. Organization wide addresses

As a general customer service practice, organizations prefer to use common mailboxes to communicate with clients, for example, customerservice@abccorp.com or support@xyz.com. To achieve this, Salesforce allows creation of Organization wide email addresses, which can be used to send emails from Salesforce using common organization mailboxes.

For more details on creating Organization wide email addresses read Organization-Wide Addresses: Let Users Send Email from Salesforce Using a Common From Address

Send default content within footer of outgoing emails (Organization-Wide Email Footer)

Many organizations prefer to include some legal/ copyright content within all emails going out of organization (using official mailboxes). Generally, this is setup within email servers. However, when sending emails via Salesforce, email server settings do not apply.

In order to get the same features, Salesforce provides feature known as Email Footer (more than one can be created). This allows administrators to specify the common legal content within email footers and use them for outgoing emails. More than one organization wide email footer can be created.

Send email using external mail server (Email Relaying)

In this world full of spam emails, lot of organizations block incoming emails from unknown sources (including Salesforce). There can be situations where customers complain that they are not receiving emails (being sent from Salesforce). This is generally due to the fact that emails are being blocked by their mail server. Customer's mail server may have been setup to accept emails from your organization, but might be blocking emails from Salesforce. In such scenario, the solution is to setup Salesforce to send emails from your mail server, also known as, Email Relaying.
Email Relaying allows Salesforce to route all outgoing emails via your email server. This helps ensure:
  1. higher email deliverability and reduce email bounces
  2. keep backup copy of outgoing emails for legal/ compliance reasons
  3. incorporate additional content check
  4. run third-party email softwares (content filtering/ anti-virus) on outgoing emails

[Lightning Experience Only] With Summer '16, you can also setup your Salesforce org. to allow users to use external email providers (currently Gmail and MS Office 365 are supported). So, once enabled, users can provision Salesforce by logging in with their third party account (Gmail or MS Office 365) to be able to send emails from their external account.


Sign Outgoing emails with certificates (DMARC compliance)

With ever rising security issues on internet, it is becoming more and more difficult to rely on emails. For matters concerning privacy and confidential information, emails have become a very risky tool. It is equally problematic for email senders as they are equally unaware whether the emails sent by them are being trusted.

Thankfully, there are some standards to secure outgoing emails and ensure that recipients can validate the authenticity of emails. A few notable standards are:
Salesforce allows administrators to setup DKIM keys for outgoing emails. This process also allows outgoing emails to be DKIM and DMARC compliant.

To know more about setting DKIM keys read Create a DKIM key

Important points to remember

  1. Email limits restrict sending emails to 5,000 external email addresses (does not include lead/ contact/ person accounts/ users and emails sent manually) per day (refer Email limits)
  2. Daily limit for emails sent through email alerts is 1,000 per standard Salesforce license per org (except free Developer Edition and trial orgs)
  3. Overall org daily limit for sending emails is 2,000,000. This limit applies to emails sent through email alerts in workflow rules, approval processes, flows, processes, or the REST API.
  4. Unlimited emails can be sent to internal users
  5. Maximum number of recipients is limited to 
    1. TO - 100
    2. CC - 25
    3. BCC - 25

Thursday, December 22, 2016

Quick Tips: Some things about Salesforce Validation rules you may not know

What are validation rules?

While creating any application, one of the most crucial building block is clean and good data. We do get ability to define required fields on field and page layout level, but there can be complex scenarios where the business rule needs multiple fields to ascertain data quality. 

Salesforce provides a very helpful feature called "Validation rule" to ensure administrators/ developers can create custom validation rules on Salesforce objects. These validation rules help ensure that any record being created or updated qualifies to defined business rules. If not, then developers/ administrators can display required error message.

Validation rule constitutes of:-
  • Formula - formula to evaluate business rule. If formula evaluates to TRUE, validation error is thrown, else it's considered as validation success
  • Error message - error message to be displayed on validation failure
  • Location - Enables admin/ developer to define location to display validation error. In standard page layouts, it'll allow user to show error either at page top or beneath the selected field

Validation rules are invoked anytime a record is created/ updated via any process I.e. manually from UI, API etc.


When to use validation rules?

Validation rules are most useful to implement required business rules without using any code. All validation rules are configurable and can be modified/ disabled by admin/ developers whenever needed.

There can be many scenarios where business rules are to be defined, so that user gets appropriate data validation error messages. For example

  • A user cannot create a contact without email address where the contact's preferred contact method is Email
  • A user cannot assign case back to Queue

To know more about how to create validation rules refer help article 
Define Validation Rules
Examples of Validation Rules


When validation rules may not be applicable?

However, there can be scenarios wherein the business rule needs multiple records or child records to assess data validation. In such scenario, Apex triggers will be best avenue to implement business rules.

Scenarios where Validation rules are skipped


  1. If validation rules exist for activities and you create an activity during lead conversion, the lead converts but a task isn’t created
  2. Campaign hierarchies ignore validation rules
  3. If records are mass assigned via Mass Transfer tool, Change owner and Accept buttons
  4. During lead conversion validation rules are skipped if validation and triggers for lead conversion are not enabled
  5. When changing ownership on Accounts, Opportunity Validation Rules are also ignored when selecting to transfer Closed Opportunities and Opportunities not owned by the existing Account Owner
  6. If workflow rules and process scheduled actions modify the record, validation rules are skipped

Considerations


  1. Because updates to records based on workflow rules and also on process scheduled actions don’t trigger validation rules, workflow rules and some processes can invalidate previously valid fields
  2. Salesforce runs validation rules before creating a record via web to lead or web to case, if the any rule fails, the record is not created
  3. Validation rules apply to all fields of the record, irrespective of any page layout; that is, 


For more details refer:-

https://help.salesforce.com/articleView?id=fields_validation_considerations.htm&type=0&language=en_US&release=204.17

https://help.salesforce.com/articleView?id=000005079&type=1&language=en_US

Thursday, April 28, 2016

New Salesforce Book - Apex Design Patterns


 

I'm really excited to share that today my book (co-written with Jitendra Zaa) has been published. Here are some personal insights

A little history
This particular topic was always in my head and coming from .Net background and having worked with lots of design patterns in MS development world. I first successfully used Factory design pattern with Apex in 2009, when all my team was scratching their head and (cursing me badly) for "overtly complicating" the code architecture. They were happy with creating 20-30 different VF pages, which I emphasized needs to be designed with the help of 4-5 VF pages, VF components and factory method pattern. Well, we were able to complete the whole stuff in time and deliver it flawlessly. It was then and similar instances later that I realized that a larger faction of Salesforce developers (back then) had very less knowledge about design patterns and code architecture. There was a huge gap.

Over the years a lot of bloggers have shared so much valuable content that the gap has almost diminished now. It was during conversation between Jitendra and myself that we realized that we should address this area and try to share some more details.

About the Book (also included in book)
The first and obvious challenge we faced was the presence of lots of highly informative and relevant blogs and books out there addressing design patterns. Largely, the information is out there. But, we realized that most of the content is primarily Java centric and it is very hard for a non-seasoned Java programmer to understand the nomenclature of design patterns. Furthermore, most of the example scenarios are also very alien to Salesforce development.

So, we created content keeping Salesforce developers in mind. The content was supposed to be very easy to understand and the all scenarios were to be Salesforce related. We spent so many hours debating on minute things, to ensure that any reader reading this book will be able to grasp and hold on to the knowledge (it's the latter part which has been the biggest challenge with design patterns).

Writing Experience
Well, all I can say is that it was not easy. All these months (around 7-8) we were in constant pressure to stick to timelines. So, we divided some patterns amongst ourselves. Then came Dreamforce '15 and we got really occupied with it. After Dreamforce '15, we completed first draft of all chapters and shared. All this while we both were working in silos and interacting on need basis.

BAAM!! came the review, and let's just say it was not that bad (as I expected) and not that good either (I very well expected that). So, we sat down together and realized that we got to dedicate lot of quality time together on this, if we have to deliver this. So, we did. We spent lots of nights and weekends on phone calls (2-7 hrs in a day) and reviewed each and every sentence. It'll not be wrong to say that we almost re-wrote entire content again.

Lastly
At the end it was definitely a very tough journey. But, as they say "No Pain, No Gain". However, painful it was to write and review content at 3AM in morning, it given immense satisfaction to learn that I was able to contribute towards greater purpose of sharing knowledge amongst community.

Sincere thanks to Jitendra(co-author) for his dedication and support. Thanks to John(reviewer) for his impeccable reviews. I'm sure he would have recovered well after reviewing our first draft (pun intended).

I really hope that every reader will be able to understand and adapt to the usage of more and more design patterns or rather structured code architecture. Feel free to share your comments with Jitendra and myself.

Thursday, October 29, 2015

Quick Tips: Un-clutter Report type list (hide report types)

Frankly, this is a pretty nifty feature I have just observed (never paid attention) and I thought that most of you like me, would have never looked into it. So, hereby sharing it.

While implementing Salesforce, one of the key things we showcase to users is the ease with which users can create their own reports with point-and-click features. This is definitely a very important feature for end users as they get the power to create reports in minutes without having to wait for lengthy IT process.

Vanilla Salesforce provides lots of report types out of the box as per below screenshot.
Default report type list

However, it is quite common that client might not be using certain features of Salesforce and hence those report types are not being used at all. They just clutter the report type list unnecessarily.

Salesforce provides a quick way to hide unwanted report types. Just, check the checkbox above "Select Report Types to Hide" and you can hide/ unhide report types. For e.g. we want to hide all Contracts and Products related report types

Hide unhide report types
Voilla!! you have removed one more point of confusion for your users
Uncluttered report types

Wednesday, October 21, 2015

Quick Tips: Consider this before moving to Lightning experience



With Dreamforce '15, everyone got ample view of Lightning framework and its benefits or rather "WOW" aspects. I'm equally excited to see a paramount change in Salesforce UX layer which is was much needed.

With all the excitement and eagerness to understand and use Lightning we need to also understand the process to transition from Classic UI (current UI) to Lightning Experience, or it can be a rather painful and unsatisfactory experience.

Firstly, we need to understand that it's a complete overhaul of User Experience and not mere CSS change. So, the way users interact with application or developers develop the application or architect designs the applications, changes significantly.

Secondly, as of now Lightning Experience is not fully enabled for entire Salesforce and is to be done in phases which makes complete sense. You cannot expect users to learn new system overnight and hence a transition is much appreciated. Not to mention, this also gives users/ developers opportunity to share their feedback and reviews to Salesforce, to help Salesforce improve Lightning Experience even further. So, till the time transition to Lightning experience is completed, be ready to switch between Classic UI and Lightning Experience.

Thirdly, with Force.com and Visualforce, lots of organizations and developers have done really fantastic job in creating custom user interface within Salesforce. This however can be a challenge (depends on case to case basis), for organization to move from Classic UI to Lightning experience. In fact, at this point, it is advisable for all those organizations to continue using Visualforce and not transition to Lightning, unless they are creating a completely new module.

I've hereby compiled a small list of quick tips that need to be considered (subject to change in future releases):-

  1. Custom Javascript and URL buttons are not available - so in case you need any functionality you'll have to rely on workflows, process builder, triggers etc. to initate the logic based on some fields
  2. Auto-populating standard forms via url (querystring parameters) is not available
  3. Any visualforce pages developed previousbly which uses Salesforce CSS tags or heavily rely on javascript will need thorough testing
  4. Inline editing is not supported (may be supported in future releases)
  5. Custom tabs cannot be added to new left hand navigation bar (may be supported in future releases)
  6. Lightning Experience cannot be enabled for Orgs using Person accounts
  7. Visualforce pages using standard UI tags get rendered as Salesforce classic

Tuesday, July 14, 2015

Quick Tips : Salesforce : 10 ways to develop application without coding

Hi all, as evident from the topic, I'm hereby sharing a small list of configuration options available within Salesforce using which a non-programmer can also develop functionalities within salesforce. The best part of using these features is that you save time, save development/ testing effort, deploy and manage it easily.

Standard/ Custom Objects
Objects a.k.a. table (for database junkies) a.k.a. entity are used to store data within Salesforce. We can use out of the box objects for e.g. Account, Contact, opportunity, lead etc. (along with their powerful features) or create our own custom objects to store required information for e.g. invoice, purchase orders etc.

Custom fields
As with any entity, you need to store its attribute, similarly in salesforce an object can have fields. Out of the box objects have standard fields. Additionally, custom fields can be added to standard and custom fields. Following are few special types of fields that can be added to enrich product's functionality
  1. Formula fields:- these are automated fields which can calculate value at run-time and display it. For e.g. you want to calculate age of contact dynamically via his/her date of birth
  2. Relationship fields:- these are one of the most important types of fields. Relationship fields, as name implies, help you associate an object with other object. This further helps in screen designing, validations, automated workflows
Validation rules
Formula based rules to ensure that any data being entered within salesforce conforms to business rules. Validation rules can be very beneficial in ensuring that data within Salesforce is valid at all times and provides appropriate error messages to users when data doesn't conform to business rules.

Page layouts

Page layouts are the user interface of objects within Salesforce. Whether you want to add/ update/ view an entity you can customize its user interface by a simple yet powerful drag-drop interface.

Apps
A app is a collection of tabs (of custom objects, visualforce pages, other external urls) which are logically connected for business operations. In case of service cloud, we can configure apps for service cloud console and manage all settings from here for e.g. what options to display (knowledge management, live agent chat etc.), how to open tabs etc.

Listviews
Listviews can be simply explained as filtered lists of your records, to make sure you are looking at right data for e.g. My Accounts, Hot Leads, Top accounts etc. this helps in filtering view to show essential records only. Listviews can be created fairly easily and shared with other users.

Workflows and Approvals
Now, with all the above options, you can create objects, fields to store data and manage its user interface. But, what if you want to automate certain functions. This is where workflow and approvals help.

Workflows can help define specific actions for e.g. send email, update a field, create task or send message to external system whenever any record is updated/ created. Workflows can also be used to schedule an action for e.g. send an email after 5 days of case creation.

Approval processes help define a process wherein a request can be send to one or multiple reviewers for their approval. There can be multiple approval steps and actions (for e.g. send email, update a field, create task).

Lightning process builder
Process builder is comparatively new bullet in gun. It has advanced features to define process, rules and actions. It can also have a multi-step decision graph (something not possible in workflows). It can be understood as an advanced workflow mechanism.

Flow
At times, standard screens do not help when situation calls for a multiple screen scenario. In this case you can use Flows to create custom screens with ability to do CRUD operations (Create Read Update Delete) fairly easily.

Reports and Dashboards
Lastly, with all the functionalities in place, any business will want to report on their data. Salesforce provides standard reporting capabilities using which users can create reports and dashboards in minutes by mere drag and drop. It may not be as powerful as BI tool, but it is really effective and useful for transactional data. 

There are lot of cool things that can be done with combination of above options and create really powerful applications. So, start exploring all the different options available within above features to understand real power of configuration in Salesforce.

Popular Posts