Salesforce: Currency converted fields in Report

This is only applicable for org. has Multiple Currencies enabled.

Converted fields available in the reporting: 

• for all currency fields, including formula field that return in currency type.
• for both standard and custom report type

The converted fields only available in the reporting, but not in the page layout as extra fields, and also not in API access.

When creating a report, the default converted currency fields are based on the user's personal currency, this can be changed by editing the report and select a different currency, users run the report will see in the selected currency when the report saved. This is applicable in both Classic and Lightning environments.

You can use the currency fields as a bucket, but it would be in the original record currency, and cannot use the converted fields for a bucket in the report.

The workaround is to use Row-Level formula, then bucket with Row-Level formula field, e.g.

IF (ISBLANK(AMOUNT.CONVERT), "BLANK",
  IF (AMOUNT.CONVERT=0, "ZERO", 
  IF (AND(AMOUNT.CONVERT>0,AMOUNT.CONVERT<10000),"SMALL","BIG")
    )
)

If the above report show is shown in EUR, so the 10000 defined in the Row-Level formula would be in EUR 10,000. 

 

Reference:

• Salesforce: Query Multi-Currency Field
• Salesforce: Dated Exchange Rates versus Conversion Rate
• Salesforce converted currency in report

Salesforce: Send List Email

To continue our previous blog Send and Log Email from Salesforce, in this blog, we will share how to send mass emails from a ListView. Why I specifically mentioned ListView? because ListView is simple yet powerful feature in Salesforce, your user can create their own list view easily (define columns and filters), and by combining this to mass email, it would be very productive. Imagine that your rep needs to mass email only to Contact with a certain value, such as Lead Source is "webinar", they can easily create a list view for this.

Salesforce by default provides a button called Sent List Email, and the admin needs to check user permission and make sure it is enabled for your users. 

Permission
Users need to have "Allow sending of List Emails" permission, otherwise, they will not see this button, if you are enabling this permission, it will also enable 3 other permissions related to this permission: Send Email, Edit Task, and Mass Email.

Enable Button
Admin needs to make sure that "Sent List Email" is enabled, go to the Lead or Contact object, then edit the Search layout. As of Winter '21 release, this option is still under "Search Layouts for Salesforce Classic"

Email Limits
In the previous blog Send and Log Email from Salesforce, we mentioned when sending email from Salesforce, we can use email templates, merge fields, attach files, signature, and so on, the same feature is available when sending mass email from "Sent List Email". 

The difference is, you will see a limit tell you on how many emails can be sent, and this limit is for the whole user in the org., not for the individual user. As per this article, we can send 5,000 external emails per day based on GMT.

Save as Draft
Another difference when using "Sent List Email", offers "Save as Draft", when composing your email, but unable to send it yet because of something else, instead of discard that email, you can save it as a draft. You will not see this when sending email from a record. See the button before Send in the above screenshot.

How to access email save as draft? Open the "List Emails" tab (from 9-dots if you do not see it), open the email composed, then click Edit. 

You will see the status of the email sent, name, owner, and etc.

Notification Email
After all of the emails sent, you will get an email notification from Salesforce

Email icon
Another difference of email sent via "Sent List Email" is the icon of email under Activities, instead of the standard envelope icon, the icon for email sent with "Sent List Email" is multiple envelopes.

As per this blog EmailMessage object, emails will be stored under EmailMessage object with prefix 02s, however, email sent via "Sent List Email" will be stored in a different object called ListEmail with the prefix of 0XB.

Send Later
The Winter '21 release offers an additional feature for email sent via "Sent List Email", users can select the email to be sent later, set a perfect date and time when the email will be sent.

Reference:

• Send a List Email in Lightning Experience
• General email limits
• Salesforce: EmailMessage object
• ListEmail

Send and Log Email from Salesforce

Email is a very basic thing in our daily work, we can send emails from Google or Outlook, then manually log the email to a record Salesforce for the future reference.

Email logged to Salesforce will appear as under the activities component. If we logged it against Contact, it will appear in the Account too, this is because of the special parent-child relationship between Account and Contact.

Salesforce also offers the capability to send emails directly from the platform, and the emails sent will be automatically logged to the Contact or Lead.

If you notice that email sent from the Salesforce will be tracked; if the recipient opens the email, we will see when it opened. While email sent from Outlook and manually logged to Salesforce will have no such tracking information in Salesforce.

Salesforce offers the below features when sending an email:

• rich-text format
• image
• link
• quick text
• attach file
• merge field from Salesforce
• template
• preview
• popout to dock view
• signature (from user Settings >> Email >> My Email Settings), check out this and this article to add image and link to your email signature

One thing to note when sending from Salesforce using standard configuration, if the recipient uses Gmail, they will see the email is sent via Salesforce.

To understand how email is stored in Salesforce, check out this blog EmailMessage object.

Note: this blog is written without Inbox and EAC configured. 

Reference:

• Learn how to add a link to your email signature
• Add an image to an email signature in Salesforce
• Salesforce: EmailMessage object

Einstein Analytics: Deploying Conditional Formatting

When you deploy the Einstein Analytics dashboards contain conditional formatting using ANT or Change Set or simply copy and paste the dashboard JSON, conditional formatting will not follow, you need to manually configure the conditional formatting again in the target environment manually.

This is because conditional formatting in the dashboard is stored under dashboard XMD, so if you deploy the dashboard XMD, then conditional formatting will be deployed.

In this blog, I will use Workbench to deploy this.

1. Create package.xml file

<?xml version="1.0" encoding="UTF-8"?>

<Package xmlns="http://soap.sforce.com/2006/04/metadata">

    <types>

        <members>Test_Conditional_Formatting</members>

        <name>WaveXmd</name>

    </types>

    <version>48.0</version>

</Package>

Test_Conditional_Formatting in above sample is the dashboard API name, you can check dashboard API name from Workbench too https://workbench.developerforce.com/restExplorer.php?url=/services/data/v48.0/wave/dashboards&autoExec=1

2. Retrieve dashboard XMD file

From workbench login to source org. > migration > retrieve, select package.xml prepared in step (1) >  click Next button > click Retrieve button > download zip file

3. Deploy Zip file

Make sure the dashboard has been created/deployed in the target org. From workbench login to target org. > migration > deploy > select zip file from step (2) > click Next button > click Deploy button 

Now open the dashboard in target org and the conditional formatting has been applied.

Salesforce Lookup Filter

Lookup is a very simple feature in Salesforce, but also powerful, with just a few clicks you can relate an object to another object easily as a parent-child relationship.

However, in some business needs, the system should NOT look up ALL parent records, here is the scenario between Account (parent) and Case (child):

• Case External --> Account Type = Customer
• Case Internal --> Account Type = any

External and Internal is Case record type, and Type is the standard Account field. Of course, we can use validation rule to block Case creation for record type = External, but validation rule does not offer the best experience, as users will not easily know if an Account is a Customer or not.

Good that Salesforce offers Lookup Filter criteria and even better you can define the logic. For the above requirement, here my lookup filters. 

Make sure to enable the lookup filter.

Reference:

• Lookup Filters Best Practices
• Lookup Filter Examples

Salesforce: Sharing Rules via Public Group & Role

Sharing records using Public Groups may or may not rollup via role hierarchies, this is determined by the object setup in Organization-Wide Defaults and also Public Groups setup.

By default, Salesforce standard objects will grant access via hierarchies, meaning users with higher role hierarchy will be able to view or edit records where the records are viewable or editable by any users below that user in the role hierarchy.

While for custom objects, you can configure the  "Grant Access Using Hierarchies" under Organization-Wide Defaults for that object.

In the Public Group setting, you also can configure to enable "Grant Access Using Hierarchies". Let us see a few scenarios as below:

1. Sharing to Public Group for objects enabled for "Grant Access Using Hierarchies"

1A. Public Group is "Grant Access Using Hierarchies" enabled

This will share records to users with higher role hierarchy.

reason for the user in Public Group

reason for the user with higher role hierarchy

Group Staff 2 only has 1 user which is Song Lee, when I expand the list, it will show all users able to access the record. From the screenshot below, Jack Bob is the record owner, while Maria Ann and Platform User 1 are users with roles higher than Song Lee's in the role hierarchy.

1B. Public Group is not "Grant Access Using Hierarchies" enabled

Let us use the same object as above, but share it to a different group which is without enabled "Grant Access Using Hierarchies". This will NOT share records to users with higher role hierarchy. 

** This is applicable for standard objects too

2. Sharing to Public Group for objects NOT enabled for "Grant Access Using Hierarchies"

2A. Public Group is "Grant Access Using Hierarchies" enabled

In this testing, we are using a custom object not enabled for "Grant Access Using Hierarchies", then we create a sharing rule to share with the same group with Grant Access Using Hierarchies as in (1B).

The result, this share will NOT grant access to the users in the higher role hierarchy.

2B. Public Group is not "Grant Access Using Hierarchies" enabled

The result of this sharing is exactly the same with (2A), where he users in the higher role hierarchy are NOT shared.

3. Sharing to Roles for objects enabled for "Grant Access Using Hierarchies"

The result is similar to (1A), users in the higher role hierarchy will get access.

4. Sharing to Roles for objects NOT enabled for "Grant Access Using Hierarchies"

The result is similar to (2A), users in the higher role hierarchy NOT will get access.

Reference: Controlling Access Using Hierarchies