Salesforce Email With Attachments

Have you noticed that when you send an email from salesforce that you do not have the ability to send attachments from the record from which you sent the email? The Salesforce email system does have a nice "include attachments" function, and you can load attachments from the salesforce documents repository and from your local computer, but a serious limitation is the ability to include attachments from the record that you were viewing when you decided to send an email.

Let me give an example. Let's say you have a Contract record. You just produced the contract and saved it against the Contract record for that client. Now you want to send an email with that Contract document. You click "Send an Email" from the contract record. You can load a document from you computer or from the salesforce documents repository, but not from the originating contract record.

Click on Image to see Full Screenshot

Custom Development to the Rescue

So the way we've solved this problem for many clients is by writing a Salesforce.com Visualforce page to replace the existing email system. We've approached this from many different angles depending on the exact needs of the client - so the resulting systems have all taken different forms. But here is what I would consider the "ideal" solution.

Salesforce.com Visualforce Email System With Attachment Loader

The main part of the system will be a duplication of the existing email author. While we're duplicating that,  we would improve some of the features there to make lookups and associations a little more convenient, but for the most part, our new system would look much like the other one.

The most significant departure from the standard system would be the "Attach File" popup. It is here that our custom functionality would be most evident. In this popup we would start with asking the user from where would they like to load their attachments. The options would be:

> The originating object
> Any other record in the system (provide a lookup where the user can select the object first, then the record, then any attachments found on that record)
> Their own computer
> Documents in Salesforce documents folder
> Documents from Content. 

Once functioning like this, the email system would be at its most useful. While we haven't built this system to function in exactly this way yet for any client, we've done several close variations on it.

If you need this functionality, let's discuss your requirements. We can certainly develop a useful system using the power of Visualforce and Apex to get what you need accomplished. Custom development is a lot less expensive these days than in years past and you can have the system you need built to your exact specification for probably less than you think. (Well, some of you have pretty small amounts in your mind, so, besides those people, we may be able to surprise you).

If you would like to chat with me about a development project like this, or any other custom development idea that you have for your Salesforce.com system, please contact me at www.snapptraffic.com

Custom Portals in Salesforce.com

If you are considering using one of Salesforce.com's portals, either their customer portal or their partner portal - you may want to consider a "custom" portal rather than one of the Salesforce.com Standard portals.

(also see a more recent blog post with additional information on this topic)

So what's the difference?

Salesforce provides its clients with two portal options: the customer portal and the partner portal.

The Salesforce customer portal is generally geared toward providing you a way to allow your customer's to see information that relates only to their account with you; things like their Account and Contact information, maybe the contracts they have on file with you, their Assets, etc. The primary limitation of a customer portal is that the portal user can only view their own account information. Customer portals cost from about $4-$10 per user/per month, depending on how they are licensed (and that can be confusing!).

The Salesforce partner portal is provided so that you can allow companies that you work with to provide you leads and generally manage the sales process associated with those leads through conversion and the movement of an opportunity through your sales pipeline. Your partners can also manage cases associated with accounts that they're working with. The primary enhancement of the partner portal is that you can view data across many accounts (also leads, opportunities, etc). Partner portal licenses generally run about $35 per user/per month.

Both portal types can view custom objects, regardless of ownership.

The salesforce standard ("standard" meaning it is provided by salesforce) portals are easy to configure and deploy - that is their primary advantage. Their primary disadvantage is that you are somewhat "stuck" with how salesforce delivers the interface. You can modify colors and fonts, links, the objects displayed, and a few other factors, but in general, the portal looks like a salesforce portal.

So what is a Salesforce Custom Portal?

For many of our clients, they need a portal, and are willing to pay for the salesforce licenses to get access to the portal, but they want significantly altered functionality, and "look and feel" than what they get in the standard portals.

Salesforce.com provides us with the ability to completely override their portal experience and replace it with a custom user interface ("Custom" meaning that it is new and built just for you). We can take advantage of the portal licensing, portal security, portal encryption, and build it on top of the salesforce.com database, so that we can provide full access to salesforce.com data in a fully customized user experience.

You'll notice in this screenshot that the login page is unique to the needs of the client, is completely different than the standard salesforce portal login page, has the look and feel of the client's main website, and still provides standard login page functions.

Once logged in, you'll notice that this portal, again retains the look and feel of the client website, yet has exactly the functionality that they wanted to provide their clients. Its data is fed by their salesforce.com database so both internal user and external portal users are working with the same data set.

Hybrid Portals - a mix of Custom and Standard

There are times when the standard portal is okay for your needs in some respects, but not others. In those cases we use the standard portal, but override any of the standard pages and replace them with our own functionality.

Here are a few examples of that:

a second example:

In these examples we used Salesforce visualforce functionality to build and display the functions that we needed rather than standard salesforce portal pages.

The Power of Salesforce.com Visualforce and Apex Programming

A beautiful thing about salesforce.com and Visualforce is the fact that we can write code to accomplish whatever is needed. Using Visualforce (and the Apex programming language), we can build pages that do exactly what a client needs. They can interface with the underlying database to retrieve salesforce.com data, operate on it, present, save it, etc - in any way that supports the portal user. I point this out in the context of the portal, but Visualforce can be used inside of a standard salesforce system as well, even when not using the portal.

So in the above example, we used Visualforce to provide a list of orders, pages to overview those orders, and pages to allow for the entry and review of orders - in exactly the way desired by our client that they designed to best meet the needs of their clients.

Building your Own Portal?

If your company is thinking about building a customer or partner portal and you would like to gain some insights into the process and inquire about your options. Give us a call or visit our website. We can build your portal or simply help you make a better "portal option" decision.

You can reach us through www.snapptraffic.com

Reports for Salesforce.com Partner Portal Users

Want to drive yourself crazy? Try figuring out why your Salesforce Partner Portal Users can't view reports. It won't be the obvious things.

- You'll try looking at the report folder permissions, ensuring that partner portal users are selected. Okay, that was easy, but it didn't work.
- Next you'll confirm which profile your partner portal users are on and go look at that profile to ensure that they have general user permission to view reports. Alright, got that set - still "Insufficient Privileges"
- You check the salesforce partner portal settings and ensure that they have the report tab turned on. Yeah, yeah, yeah, it was - still no reports.
- And finally you ensure that the sharing model doesn't prevent them from seeing the data in the report. No joy.

Then what else could you possibly check? What else is there to check? Certainly nothing obvious.

Well that is where I found myself recently, having checked everything I could think of. I searched Google for Salesforce Partner Portal Reports and after looking through about 20 links, came across an exchange on the salesforce.com forums where a user realized what the issue was and mentioned it.

As it turns out, salesforce.com is "expecting" you to be in a private sharing model with regard to your partner portal users and their use of reports. Meaning, they built things thinking that is how you would be using the system. Therefore, even if you are in an open sharing model, all the way down to your partner portal users, if they run a report that includes records that they do not own, they will receive an "Insufficient Privileges" error.

According to the sharing model, they should have no problem viewing these records, but since they don't own the records and have not had the records explicitly shared with them through a sharing rule - they get that error.

I don't quite get why, maybe someone who understands this more thoroughly can explain, but in a nutshell, in order to grant partner portal users permission to view reports, you must:

1) make the sharing model PRIVATE, then
2) use a sharing rule to grant them visibility over the records in the object that is being reported on.

I know, go figure. Didn't make sense to me. But it worked.

If you need help on any salesforce.com issue, feel free to contact me at www.snapptraffic.com. Our consulting services at Snapptraffic Consulting are geared towards helping the salesforce.com customer get the most out of their system. From troubleshooting to full scale implementation and development - we can help.

The Salesforce 18 Digit ID

As a Salesforce.com consultant, I've run into this 18 digit vs. 15 digit ID issue many times when working in Salesforce.com. Here is why:

When working with data in salesforce.com there will be times when you need the 18 digit ID of a given record. This will most likely happen because you have two tables in Excel and you need to do a lookup from one table to the other using an ID.

Say for example you need a list of contacts at accounts where you have open opportunities. If not using Contact Roles, which is the case for many companies, in order to produce this list you have to make yourself a report of Accounts & Contacts and a report of Accounts & Opportunities - both brought into excel as separate sheets. If both reports have the Account ID on it, you would think you can simply do a vlookup from one excel sheet to the other to find matching accounts.

You can do this lookup, but you might be stumped to find out that many "hits" occur that weren't legitimate. Meaning, you "matched" an account that wasn't really a match.

The reason is that a Salesforce ID is a 15 digit CASE SENSITIVE string of characters. The excel vlookup function though ISN'T CASE SENSITIVE! Therefore, an ID that looks like this in SF:

0016000000MRatd

might match this id:

0016000000MRAtd

or this one:

0016000000MRaTd

or this one:

0016000000mRatd

and so on...

And I've been amazed to find out how many false hits occur. "What are the odds?", you might say to yourself. Higher than you think!

Salesforce.com gets around this by creating an 18 digit version of the ID. The last 3 digits of the 18 digit ID are all capital letters and each of those 3 is a checksum for the other digits in the 15 digit ID. The 16th digit is a checksum of the first 5 characters, the 17th checks the second 5, and the 18th checks the last 5. It's a good technique for ensuring an exact match.

In order to do a vlookup on IDs in excel, you MUST use the 18 digit IDs. The question is: how do you get the 18 digit ID?

For years I used an excel sheet I had written to calculate the checksum columns and return the 18 digit ID. (If you want that excel sheet, ask me for it and I'll send it to you) It worked fine, but was a drag to use. It finally occurred to me that there must be a formula I could create in a Salesforce custom formula field that would return the 18 digit ID. A quick google search revealed this formula. (Hat tip to Erik Mittmeyer who posted it on a developer board in Salesforce)

Id
& MID("ABCDEFGHIJKLMNOPQRSTUVWXYZ012345",(
    IF(FIND(MID(Id,1,1), "ABCDEFGHIJKLMNOPQRSTUVWXYZ")>0,1,0)
    +IF(FIND(MID(Id,2,1), "ABCDEFGHIJKLMNOPQRSTUVWXYZ")>0,2,0)
    +IF(FIND(MID(Id,3,1), "ABCDEFGHIJKLMNOPQRSTUVWXYZ")>0,4,0)
    +IF(FIND(MID(Id,4,1), "ABCDEFGHIJKLMNOPQRSTUVWXYZ")>0,8,0)
    +IF(FIND(MID(Id,5,1), "ABCDEFGHIJKLMNOPQRSTUVWXYZ")>0,16,0)
    )+1,1)
& MID("ABCDEFGHIJKLMNOPQRSTUVWXYZ012345",(
    IF(FIND(MID(Id,6,1), "ABCDEFGHIJKLMNOPQRSTUVWXYZ")>0,1,0)
    +IF(FIND(MID(Id,7,1), "ABCDEFGHIJKLMNOPQRSTUVWXYZ")>0,2,0)
    +IF(FIND(MID(Id,8,1), "ABCDEFGHIJKLMNOPQRSTUVWXYZ")>0,4,0)
    +IF(FIND(MID(Id,9,1), "ABCDEFGHIJKLMNOPQRSTUVWXYZ")>0,8,0)
    +IF(FIND(MID(Id,10,1), "ABCDEFGHIJKLMNOPQRSTUVWXYZ")>0,16,0)
    )+1,1)
& MID("ABCDEFGHIJKLMNOPQRSTUVWXYZ012345",(
    IF(FIND(MID(Id,11,1), "ABCDEFGHIJKLMNOPQRSTUVWXYZ")>0,1,0)
    +IF(FIND(MID(Id,12,1), "ABCDEFGHIJKLMNOPQRSTUVWXYZ")>0,2,0)
    +IF(FIND(MID(Id,13,1), "ABCDEFGHIJKLMNOPQRSTUVWXYZ")>0,4,0)
    +IF(FIND(MID(Id,14,1), "ABCDEFGHIJKLMNOPQRSTUVWXYZ")>0,8,0)
    +IF(FIND(MID(Id,15,1), "ABCDEFGHIJKLMNOPQRSTUVWXYZ")>0,16,0)
    )+1,1)

To put this formula to work, simply create a custom formula field that returns type text, place the code above in the formula field and voila, you've got an 18 digit ID that you can easily add to any report. Huge time saver.

If you need help implementing this or with any other salesforce.com issue you might face, feel free to contact me at www.snapptraffic.com. We can help you with any setup, customization, or development issue you might face in Salesforce.com.

Importing Person Accounts into Salesforce.com with the Data Loader

Here is a challenge you may face - importing account data into Person Accounts in Salesforce.com. If you are using the Data Loader that you downloaded from Salesforce.com or the Lexi Loader for the Mac, then use these techniques to upload your data into Salesforce and have the import process create Person Accounts for you.

The key to this process is telling the data loader what kind of Record Type you want for the account. In your import CSV, ensure that you have a column for "Record Type". Then you'll add the record type ID for Person Accounts in your system. This is a little tricky. Here is how you do it:

Navigate to the Person Account record type via the following path:

Setup/App Setup/Customize/Accounts/Person Accounts/Record Types

Then on the Person Account description page, look at the URL, the first ID found in the URL is the Person Account ID.  See the next image:

Just paste that ID into the Record Type column that you created in your CSV import file. Then when you upload your data into salesforce.com with the data loader you'll be able to create Person Accounts.

Another thing to remember. Don't import into the Account Name field (labeled Name). Instead, import into the LastName and FirstName field instead.

A couple of snags you might run into.

- First, Person Accounts must be enabled in your instance of Salesforce. This is something that you must have Salesforce.com Tech Support do for you.

- Second, the person to whom you are assigning the new account must be able to use Person Accounts. This is a profile setting. Navigate to the user profiles via the following path:

Setup/Administrative Setup/Manage Users/Profiles/Select desired profile

In the profile management page, find this link:

Click Edit. On the resulting page, ensure Person Accounts are selected.

If you have any trouble or need some help with importing, or Salesforce in general, feel free to contact us through our website - www.snapptraffic.com

Salesforce Portal Development

Do You Need A Portal for Your Salesforce.com System?

(also see a more recent blog post with additional information on this topic)

Salesforce.com comes out of the box pre-configured with Self-Service, Customer, and Partner Portals. Beyond that, Salesforce sells licenses for completely custom portals. Not only can Salesforce offer you portals for your customers and for your partners, but they also host websites on their system called "Salesforce.com Sites".

In addition to the portals, Salesforce Sites makes it possible for you to make information stored in your organization's instance of Salesforce.com publically visible on the internet. A common example is that of "Job Openings". A database in Salesforce.com of Job Openings for the company can be listed on the internet in a way that the general public can view them.

Authenticated Sites and Custom Portals

You may want to authenticate visitors to the site though. For example, if you want to permit someone to submit a resume against one of the listed Job Openings, you may want to authenticate them. This essentially becomes a "portal."

So while Salesforce.com offers portals that require no programming, but rather just "point & click" configuration, some applications don't fit that provided functionality. In the example "Job Openings Resume Submission System", it would probably be better suited to a custom portal built on a Salesforce.com Site.

Custom Websites Built on Salesforce.com Data

As more companies adopt Salesforce.com for their main business data management and CRM platform, they are finding that they want to build websites and portals based on the data in their system. Deciding on the correct approach can be daunting. There are customer portals, partner portals, self-service portals, publically visible Salesforce.com sites, and an entire range of custom portal solutions.

Learning about Salesforce Licensing and Salesforce.com Portal Options

You may know that you need to give your customers or partners access to your Salesforce data in some way, but unsure of the best portal option, or the best Salesforce.com licensing option. There is a BIG difference between the pricing models offered by Salesforce.com, some licenses are as much as $35/mo/user, others as inexpensive as a few pennies - some free. Picking the correct licensing option is critical.

In general, there are 4 general categories of Salesforce.com Portals:

1. Partner Portals
2. Customer Portals
3. Authenticated Sites
4. Salesforce.com Sites

 In each of these you are giving access to your salesforce.com data to people who are not users of your salesforce system. 


Salesforce Partner Portal: the idea behind a partner portal is that your partners who resell your products & services can login to a system tied to your salesforce.com organization where they can record their leads, keep track of their accounts and contacts, and advance the opportunities that they are pursuing on behalf of your company. It gives them a place to share their progress with you. Main functional distinction: it gives the users access to multiple accounts and contacts - its access extends ACROSS your organization - fully controlled of course by sharing rules and the role hierarchy.

The Salesforce.com Partner Portal is a SYSTEM within Salesforce. Meaning, it already exists, you simply buy licenses for it and configure it. You can do custom Salesforce.com development with APEX and visualforce pages to add functionality to it, but that is not required. You can simply configure it the way you want it and give your partners licenses. 


Licenses for Partner Portals cost about $35/user/mo - although you can probably work a deal with Salesforce depending on the number you are purchasing.


Salesforce Customer Portal: the idea here is that your customers can login to a system to see information that relates to them as a customer of your organization. A salesforce customer portal gives a user access to THEIR account data, so in distinction to the partner portal, it is not CROSS organizational. And like the Salesforce Partner Portal, it is a system in Salesforce that can simply be configured and deployed.

These licenses cost under $10/user/mo depending on the number and plan.


Although salesforce provides a customer portal system, you can override this system and deploy an entirely custom salesforce.com portal. We often use these licenses, but deploy a custom website instead. The customer portal license gives us the ability to authenticate and encrypt the session on the custom website (see note below about authentication and encryption).


Authenticated Sites: Salesforce provides this licensing option for the times when you will be displaying data from salesforce in an entirely custom way and only displaying information from accounts, contacts, and custom objects. Check with your account manager at Salesforce for the pricing. It can be confusing, there are many options.


Salesforce.com Sites: Salesforce offers a "guest-user" license that essentially makes it possible for a developer to produce a website displayed on a page hosted by salesforce that displays salesforce.com data to the general public. No licenses are needed - no additional expense except for the licenses you already purchase for your users.


A Note about Authentication and Encryption: to authenticate means to ensure that the correct person is viewing data within your system. Encryption means that the authenticated user is viewing that data securely - through an "encrypted" session in the browser, evidenced by the HTTPS in the address and usually a little padlock displayed somewhere in the browser. 


We can authenticate users on Salesforce.com Sites without buying a Salesforce License. You just store a username and password somewhere in salesforce and only present applicable information after those have been entered correctly. So you know you have the correct person viewing the system - BUT - it isn't encrypted this way - the information is being displayed in a non-secure session (HTTP, not HTTPS in the address bar). This is sufficient for many applications. 


However to encrypt a session, get the HTTPS and padlock displayed - you must have a salesforce.com license of some kind. You can't get into a secure session without a salesforce license. You can authenticate with no license, but you can't encrypt with no license.


Therefore - a Salesforce.com Sites page can be authenticated if it is needed and the developer writes the code to verify the user's identity. It will not be encrypted. But you can display any data from your salesforce.com system out to the general public using Sites. If you want to encrypt that data, then you'll need to get an Authenticated Sites or Customer Portal license for the people who will be using that system. 


Note: all the licensing and portal options above are available only in the Enterprise & Unlimited Editions of Salesforce.com. 

Need Help?

If you want help determining the right license type for your application or need help building your custom website or setting up your portal, feel free to contact us. Snapptraffic has a great team of developers and lots of expertise when it comes to building and deploying custom Salesforce.com sites and portals. You can reach us through our website at:


www.snapptraffic.com

Using a Salesforce.com Email Service - Email2Anything

We have created several email services over the last few months. I thought I would mention how this cool functionality in Salesforce.com can be put to work for you.

An email service is a system in Salesforce.com that gives you an email address to which you can send emails that you want handled by Salesforce.com in some way. The "handling" of the email is through custom APEX code that gets executed when an email is received at that address. You might need:

Email2Lead (Email to Lead)
Email2Contact (Email to Contact)
Email2Opportunity (Email to Opportunity)
Email2Anything! (Email to Anything else!)

If you want to send an email to Salesforce.com and have it handled in a special way. Then the email service is the way to make that happen.

Inbound Email Service Requests

We used an email service in the Snapptraffic instance of Salesforce to handle help requests that come to us from our clients. When a client sends an email to our help request email address with a description of a problem that they need solved, we have code that does a search for their email address (through all the Contact records) and upon finding it creates a new "Request" record, associates it with the contact record, sends a reply to the contact, and informs their account manager that a new request is waiting for them. It also creates activity records with the email details. One other cool thing we did was include an "Request ID" in the subject line of any emails so that our code could associate inbound emails with existing requests rather than create new ones.

(You may be wondering why we didn't just use cases which has a lot of this functionality already in place. My Snapptraffic reps are on Platform licenses of Salesforce rather than full Enterprise Licenses. Platform licenses are typically under $50/mo rather than $125/mo for Enterprise - but Platform licenses have access to Accounts, Contacts, and any custom objects, but not standard objects like Leads, Opportunities, Cases, etc - so I created a custom object to handle Requests and an email service to mimic the cases functionality)

Email2Lead - Emails from Lead Sources such as Brokers

Another common request that we've built for clients recently is variations on "Email-to-Lead" (Email2Lead, Email to Lead, whatever people want to call it). Salesforce.com has no provision for this, but an email service can easily be written to provide this capability.

The way we've implemented it is to allow the user to forward an email received from a new prospect into the email service and have the system create a new lead record based on that inbound message. We normally include "switches" in the email body whereby the user can provide some direction to the code to ask it to do certain things. For example, the user might want to populate fields on the Lead with data not discernible from the common email fields such as subject, to, from, etc - like possibly the Industry field. So we'll give the user the ability to add lines to the body like:

Industry: Communications

Our code will parse for these switches, then populate the lead fields accordingly. Some clients use many of these switches. The code then creates the lead record, sets all those fields, can auto-reply to the lead, and make any other necessary records (like activity records based on the email). One client uses a selectable "signature" with all of these switches embedded and they can quickly add the details they want before sending the email.

Email to Opportunity

One client wanted to be able to forward emails from existing clients and have the email service create a new opportunity. We used switches just like in the above example so that he could set any fields on the opportunity he desired by typing the name of that field and the value he wanted in it, like:

Amount: $25,000
Type: Existing Business

The email service finds the correct Contact record (based on the email address), then creates a new Opportunity for the Account to which that Contact is associated and sets the fields of the Opportunity according to the switches in the email. 

Handling Attachments

This is also another cool capability of the email service, taking any attachments and doing something intelligent with them. Want them attached to a new opportunity, the contact record, the existing account? Whatever it is, the code can do this.

Variations on "Email to Salesforce"

You've probably realized that Salesforce already has a standard email service called "Email to Salesforce" with some pre-defined functionality that works pretty well. It receives emails that you are sending to your clients from some other email system, like gmail, and finds the relevant lead or contact and attaches that email to their activity history. Many times this system is great right out of the box, but you may want something different. We can create a variation on "Email to Salesforce" and make it do whatever you can dream up.

Summary

So the Salesforce.com Email Service is a great tool for getting the emails you receive into Salesforce.com and handling them in a pre-defined, special way. Contact us at Snapptraffic.com if you want some assistance creating an email service specific to your business model.