Some excellent Salesforce Q&A that may be useful to you. Take a look and please post comments if you have any follow-up questions of your own!

Q: Does Cloud Scheduler sync with Outlook and/or Gmail?

A: The Cloud Scheduler doesn’t sync with Outlook and/or Gmail per se. But if you use the Cloud Scheduler to setup a meeting and “Confirm” it such that a Salesforce Event is created, then any setup you have that integrates Salesforce Events with other Calendar tools such as Outlook or Gmail, the Event would be detected and synched.

Q: We have a problem where a Chatter Group is posted to, and a Group Member has email notification on. When this member also has Out of Office on in their email settings, a Post/reply is sent back to Chatter automatically. What is the recommended solution to this Chatter clutter?

A: This workaround involves custom development…. If the whole company has an agreed upon Out Of Office format (perhaps some common text in the subject line,) you can build Triggers on the Feed Item and Feed Comment objects that look for entries formatted as such and prevent the entry from appearing in Chatter.

Q: If doing Joined Report where Contact is selected as one of the report types, can you add the list to a Campaign?

A: No. The Standard Report Types that include the Contact object will present a special “Add to Campaign” button that makes creation of Campaign Members more efficient. Upon Click of this button, the Contacts that are presented in the report are automatically added to a Campaign (of your specification at the time of the button click) as Campaign Members. However, when you run a Joined Report that includes Contact as a report type, the “Add to Campaign” button is not available.

Workarounds:

1. Often the reason for going to a Joined Report is because of a requirement to combine certain objects’ data into the same report. Sometimes you can take advantage of Formula fields and/or Rollup Summary Formulas to accomplish some of these same goals.
2. If you need to filter out Contacts based on child data, consider using a Tabular report with Cross-Filters. This allows the Report Type to be based on Contact (which gives you the “Add to Campaign” button) but also allows you to remove records from the results set based upon filters applied to a child object of Contact.

Q: How do you suggest we handle Out of Office on Salesforce? Do sales reps leverage through Sharing settings? Is there a better option?

A: That is the most common practice. To specify a User in your Sharing Rule (as opposed to a Role), create two Public Groups first – one for the person who owns the records, and one for the person who needs temporary access.

Keep in mind that it is not recommended to give Sales Reps permission to make Sharing Settings changes – this should be a coveted permission for Admins only. Tip: You can setup a process for users to easily submit requests of this nature to your Admin. You can customize a Case record type for internal use, and setup Case Assignment Rules to route the Cases to the appropriate person in your organization.

Let’s review some more of the features you can request for enablement via Salesforce Customer Support.

You “Open a Case” via the Salesforce Help & Training Portal, signoff on the conditions and/or consequences of the feature enablement, and voilà…you have a new feature enabled in your Salesforce org!

See the full list documented by Salesforce and the editions in which they are available[1].

Create Date, Last Modified Date field open for initial data import

Let’s say you are migrating data from a previous CRM system into Salesforce.  Upon research, you will find that you cannot insert or update values in the Create Date or Last Modified Date fields in Salesforce.  Without the ability to map source data columns to these fields, these Salesforce date stamps will reflect the day/time you loaded the data, as opposed to when the data was originally created in your source system.  If you make the right “case” to Salesforce (no pun intended,) you will be able to map to these fields when you are setting up the mapping via the Data Loader.

Restricting Search on Fields with Field Level Security

A little known fact is that a hidden field configured via field level security is included the Salesforce search functionality.  For example, when a user performs a search with the term “paperless”, if the Billing Type field is not visible to the user because of the configured field level security settings, any rows with Billing Type = “paperless” will return in the search.  Submit a feature enablement request to Salesforce in order to restrict this behavior.

Product Prices, increase the decimal places to 8 places

Products and Opportunity Products (a.k.a. Line Items) typically reflect two decimal places in the price fields: Standard Price, List Price, and Sales Price.

Some businesses require additional decimal places.  Salesforce allows you to request enablement of additional decimal places – you can specify up to 8 places to the right of the decimal point.

Remove Price and Quantity fields from Opportunity Product Page Layouts

Some businesses require use of Opportunity Products, but choose not to use the standard Price and/or Quantity fields.  When removing these fields from the page layout (standard or multi-line) you would see an error message noting that these cannot be removed.

However, upon submitting a feature request to Salesforce for the ability to remove these fields, you would be able to successfully remove them from the layout(s).

[1] Some items previously requiring request are now available as settings that can be changed without explicit request from Salesforce. Data Export Service, Single-Sign On and Sandboxes are a few examples.

You are probably already aware that features such as Multi-Currency, Person Accounts and Territory Management must be enabled via request to Salesforce Customer Support.  You “Open a Case” via the Salesforce Help & Training Portal, signoff on the conditions and/or consequences of the feature enablement, and voilà…you have a new feature enabled in your Salesforce org!

That said, I would venture to guess that you are not aware of just how many features you can request!  The list is L-O-N-G.

Some of these items are ready-to-use; just ask Salesforce to enable them and you’re off and running.  This level of flexibility helps to provide Salesforce Users with additional “out-of-box” functionality leaving Salesforce Admins with more time to work on enhancements that do require configuration or custom development. (Example: 10 MB Attachments)

Other types of features open doors to capabilities of Salesforce that can be leveraged in configuration or custom development.  (Example: Email Relaying)

Whether you hit the ground running with a new ready-to-use feature, or enable a feature that allows you to build something faster and better, the bottom line is that functionality becomes easier to implement, which is a win-win for Admins and users alike.

Let’s review some of the less known features you can request for enablement.

See the full list documented by Salesforce and the editions in which they are available[1].

Login Access Policy: Administrators Can Login as Any User

Grant Login Access is an extremely useful feature whereby a User can permit their Administrator to login as them, thereby permitting security issue troubleshooting, etc.  Via request to Salesforce Support, the ability to turn on Grant Login Access across the board can be turned on by the System Admin – a tremendous time saver!

10 MB Attachment Limitation

Salesforce “Attachments” permit a maximum file size of 5 MB.

If you frequently hit this limit with files in the 5-10 MB range, you can request that Salesforce increase the limit to 10MB!

Email Relaying

Standard Salesforce email functionality routes outbound emails from Salesforce through the Salesforce SMTP servers.  Often companies (for compliance and/or deliverability purposes) wish to route emails sent from Salesforce through their own servers.  Activation of Email Relaying will expose an administrative settings screen that will allow you to enter the necessary parameters pertaining to your company’s preferences and email environment in order to send out Salesforce emails via your company’s infrastructure.

[1] Some items previously requiring request are now available as settings that can be changed without explicit request from Salesforce.  Data Export Service, Single-Sign On and Sandboxes are a few examples.

In my last posting, I outlined some basics regarding the use and setup of basic Joined Reports.  In this article, I will focus on some of their more complex capabilities and considerations.  Specifically, we will review the following two techniques:

• Creation of a Sales Rep Scorecard Report that combines Opportunity and Activity data into one report
• How to add a Cross Block Formula field to your report which allows you to build a formula field using a combination of fields across report blocks

Let’s get started with our Sales Rep Scorecard Report.

The report is useful in comparing key metric performance across various members of the sales team.  In the first 2 blocks, we present some Opportunity metrics.  Separate blocks are needed because the filter criteria for each block are different: CQ Wins looks at wins only; YTD Win Rate looks at all Closed Opportunities, won or lost.  In the last block we tally Activities in order to look at MTD Completed Meetings.

The key to building this report successfully is to select the correct Report Type for each of the Report Blocks.  Specifically, the grouping field for this Scorecard needs to be the name of the Sales Rep.  For Opportunities this would be the Opportunity Owner.  For Activities this would be the Assigned To.  For Joined Reports that have different report types in the blocks, the grouping field must be selected from the set of Common Fields.  These are the set fields that are in common across the report types used in the report.

If you setup your report blocks with standard report types based upon Opportunity and Activity, the Common Fields are going to be those from the Account.  The field on the Account that would most typically reflect the name of a Sales Rep would be the Account Owner.

Let’s consider the impact of using the Account Owner as the grouping field:

• Account Owner gets “credit” for all Oppties on their Account, regardless of Oppty Owner
• Account Owner gets “credit” for all Meetings with their Account, regardless of Assigned To

These impacts will skew the validity of the Scorecard, since the intent of a Scorecard is to reflect what a Sales Rep did, not what we can infer that they did based on ownership of the Account.

That leaves us with the question, what report types can we select for our blocks that will allow us to group by Opportunity Owner and Activity Assigned To?

In this scenario, the goal is to drive the report based upon User information, so that the Full Name of the User can be selected from the Common Fields.

The approach, therefore, is to configure new custom report types: Users with Opportunities and Users with Activities.

In the process of setting up these new custom Report Types, the System Admin will be prompted to specify what User lookup field from the Opportunity and Activity objects should be used as the join criteria.  This is where the Opportunity Owner would be selected for the Users with Opportunities report type, and Assigned To would be selected for the Users with Activities report type.

Once your report types are setup, you would then begin the creation of your report and the blocks therein.  After all blocks have been added, you will see the Common Fields are based upon the User object, and you can select the Full Name as your grouping field.

And when you click the Run Report button, here’s the final product:

Now, in order to demonstrate the concept of the Cross Block Formula, let’s add another report block that shows the total Amount in the Rep’s Pipeline set to close for the next 90 days.  This will be block 4, and is based upon Users with Opportunities, however the filter criteria looks at Open Opportunities (Closed = False).

To get an approximation of what portion of their pipeline the rep might win based on their historical win rate, let’s build a report formula that multiplies the pipeline Amount to the Win Rate from block 2.  Therefore, we need a Cross Block Formula so that we can leverage the filter criteria in block 2 for the Win Rate portion, and the filter criteria in block 4 for the Amount portion.

The formula builder for Cross Block formulas allows us to choose which block’s fields to use for each component of the formula.  Keep in mind that the “Win Rate” report summary formula from block 2 will not be available for choosing – only fields from the object configuration appear in the picklist.  Instead, just re-enter the formula criteria again (Opportunity.Won/Opportunity.Closed.)

Once built, the Cross Block Formula would have the following setup:

And when you click the Run Report button, here’s the final product!!

The Spring ’12 release of Salesforce bore tremendous benefit in reporting functionality with the launch of Enterprise Analytics. Available to Developer, Enterprise and Unlimited Edition customers at no additional charge, the Enterprise Analytics module provides enhanced features within the Report Builder permitting users to take Salesforce reporting to a whole new level. The 3 primary features included in Enterprise Analytics are:

• Joined Reports
• Buckets
• Cross Filters

Even though all 3 are extremely useful and it is more than likely I will address all of these and more in the near term, this post focuses on the basics of Joined Reports.

What is a Joined Report?

A Joined Report gives you the ability to build one report with multiple sections or “Blocks” based on differing filter criteria and/or source data objects. For example,

Quarterly Opportunity Wins Analysis:

Opportunity Wins $$ and Win Rate for QTD for each Opportunity Owner

Traditional reporting techniques made this report a challenge because Custom formula fields configured on the Opportunity were required to show a tally of Won Opportunity $$ and Win Rate metrics in the same report. Here’s why …

• The Won Opportunity $$ can be achieved via a filter on Status = Closed Won
• The Win Rate requires a filter on all Closed Opportunities (Won or Lost) for the denominator of the Win Rate formula
• These two filter requirements conflict with each other
• There are workarounds to this by adding formula fields to the Opportunity object that can then be used in report metrics, but wouldn’t we rather build our report without asking our System Admin to create formula fields?

Leveraging the Joined Report type allows us to create a separate “Block” for each piece of this report:

• Block 1 = Opportunity Wins $$ QTD
• Block 2 = Win Rate QTD

In this example, both blocks are based upon the same report type (Opportunity) but they have different filter criteria. Follow the instructions in the sections below and you can create this sample report in your own environment. In an upcoming post, we will explore more advanced types of joined reports that leverage different Report Types for each block… so STAY TUNED!!

Getting Started:

1. Click the New Report button from the Reports tab
2. Select the Report Type you want to use for Block 1 of your report. In our case, this is just “Opportunity”. Then click the “Create” button in the bottom right corner of the screen.
3. Change the Type to Joined Report (see final considerations below for tips on how to enable this feature)

Building Block 1 (Opportunity Wins $$ QTD):

The first Block is always automatically added for you, but you need to make some modifications:

1. Rename the block “Opportunity Wins $$ QTD”
2. Remove unwanted fields by dragging and dropping them into the Field Explorer pane on the left
3. Add the fields you want to display for Block 1 by dragging and dropping them into their desired location in the report preview pane
4. Add the necessary filters for Block 1. In this case, we need Opportunity Status = Closed Won and Close Date = Current CQ. We also need to change the “View” filter to “My Team’s Opportunities”
5. Apply a Sum on the Opportunity Amount to get the total for the Wins.
6. Save your Report!!!

When you’re done, Block 1 would look something like this:

Building Block 2 (Win Rate QTD):

1. Drag and Drop an Opportunity field you will use in Block 2 (doesn’t matter which one) into the whitespace of the preview pane to the right of Block 2. Perhaps the “Won” checkbox field?
2. Rename the Block “Win Rate QTD”
3. Show/hide the fields you want to display for Block 2 by dragging and dropping. For this one you might only want the Won checkbox and the Closed checkbox, or the Stage.
4. Add the necessary filters for Block 2. In this case, we need Opportunity Status = Closed and Close Date = Current Calendar Quarter. We also need to change the “View” filter to “My Team’s Opportunities”
5. Before we can add the Win Rate formula field to the Report, we need to setup a Grouping that is common across all Blocks. Drag the Opportunity Owner field from the Field Explorer’s Common Fields section to the Grouping bar.
6. We need to create a Report Summary Formula for the Win Rate. You must have a grouping in your report in order to do this! (see step 5.)
   1. Drag “Add Formula” option from the top of the Field Explorer to an empty slot in the Win Rate QTD block
   2. Win Rate = Won / Closed (Note: Won and Closed are a Boolean fields included in the standard Opportunity configuration. Whether or not a Stage is considered to be Closed or Won is based on your Stage configuration settings.
7. Save your Report!!

The report would now look something like this:

And when you click the Run Report button, here’s the final product!!

Final Considerations for Joined Reports:

• In order to have access to setup a Joined Report:
  • The Joined Report type must be enabled by your System Administrator
  • Your Profile must have the Report Builder permission
• You can add up to 5 blocks to a Joined Report
• At this time you cannot Export the data or launch the report in a Printable View.
• Joined reports cannot be the source report of an Analytic Snapshot or a Dashboard Component

In my next post, I will focus on Joined Reports that require different Report Types as well as unravel some advanced concepts and “gotchas”. Until then, good luck trying out these basics!

Topic: Create Trending Reports with Analytic Snapshots

A common misconception with Salesforce reporting is that you can’t produce trending reports based on Salesforce data. For example, let’s say you want to evaluate Agent Performance over time by taking a look into your historical Case data?

Are my agents closing cases faster over time?

What elements would be necessary to generate such a report? Ultimately, you need the ability to “freeze” the data on a regular interval. If you want week over week performance metrics, on a weekly basis you would need to calculate the average time to close for an Agent’s set of cases that were closed in the last 7 days and save that avg. time to close number, the Agent’s name, and the date the record was frozen.

The raw ‘trending’ data would look something like this:

And the report that you can generate using that data would look something like this:

And the chart that you can overlay on top of that data would look something like this:

You might be thinking that I am crazy to suggest that you manually export and import historical records on a weekly basis using the Data Loader or another type of tool.  Luckily, I don’t have to suggest that approach because Salesforce has provided a tool that can be used to freeze the data for you … (drumroll) … it’s the Analytic Snapshot! Once setup and scheduled, your data can be frozen into a custom object whose sole purpose is to store the trending data.  The overall setup of Analytic Snapshots involves 4 basic steps:

Step 1: Setup a Report to show the data to capture:

The Agent Performance report needs to show:

a)   The Agent’s name = Group the report by “Case Owner”

b)   Average Time to Close a Case = Apply the Average function on Case custom field, “Time to Close (hrs)”.  The custom field subtracts the Opened Date (a.k.a. CreatedDate) from the Closed Date and divides the result by 60.

The filter should look for Closed Cases with a Close Date in the Last 7 Days:

Step 2: Setup a Custom Object to store the report’s data:

The fields on the custom object should align with the fields from the report created in step 1.

Step 3: Configure the Analytic Snapshot by mapping your object’s fields to the report’s fields, and setting the schedule:

Step 4: Configure a Report and Dashboard Component to display your trending data

It’s as simple as that!  No code, data migration or integration required.  Happy data analysis!