Canvas is an exciting new feature for integrating new or existing Web apps into Salesforce. I sat down with Jay Hurst, the PM for Canvas, and we talked about what the feature is, what problems it solves and how it works.

D: Thanks for meeting with me today.

J: No problem. I’m always happy to get a chance to talk about Canvas.


D: Before we dive into the details, can you explain what Canvas is?

J: Sure can, thanks, Dianne. Canvas is a framework that allows you to take your existing Web-based applications and expose them inside of Salesforce. The way it works is that inside Salesforce you define the Canvas app and its metadata such as the endpoint URL, icon logos, and other app-specific information. Once that’s created, we open up a window inside the Salesforce UI and load your app UI inside it. The UI integration is the base layer of the framework.

D: I see. So that’s the basic scenario?

J: Right. But with the Canvas SDK, we also allow you the ability to integrate with the Salesforce data layer through our existing APIs. That means your application not only has the ability to display inside Salesforce, but it can also act on Salesforce data itself. The idea is to give you an easy solution to take all the existing apps in your world and surface them inside Salesforce, to allow those apps and Salesforce to talk to each other, and ultimately, give your end users a seamless end-to-end experience where they can have all the resources they need at their fingertips. It’s great for end users because it means they can avoid the context switching from one app to another and focus on the important aspects of their jobs.

D: Awesome. And this is all done without Apex or Visualforce or any other platform technologies?

J: I like to think of Canvas as not exclusive of those technologies, but rather it gives you the ability to leverage those technologies with your applications. A good example of that is in our Spring ’13 release we give you the ability to take a canvas app and actually load it onto a Visualforce page. So that means anywhere you can put a Visualforce page you can now also have a canvas app. This gives you the ability to modify the Salesforce UI as you would through Visualforce, but then also bring in your external Web applications.

I don’t want to give the impression that this replaces any existing technologies that we have out there. We still love Visualforce, we still love Apex, but this is just another tool in your development tool chest. Instead of forcing your developers to learn Visualforce and Apex to rebuild an existing application, with Canvas, you can use any language that you choose to create the source Web app.

D: That’s a compelling benefit.

J: Absolutely. If your developers are .NET developers or Java developers, they can continue to use familiar tools to build Web apps, and then you can just surface those apps at the UI layer. It’s really just a tool to enable your developers to become more productive.

D: Now, there may be some developers that don’t know what a canvas app is. Where does that term come from? In other words, what is a canvas app, for those that don’t know?

J: We want developers to think of canvas as an area inside Salesforce that you can paint on, where you can draw your own UI. With Canvas, you would first define your app URL, for example, Then you can take that very UI and put it in the canvas area inside Salesforce. We ask for the HTML that your app would display and just display it right within Salesforce.

D: Very cool. That means that a customer could make Salesforce a one-stop shop for their users where they could access all the apps they need to get their job done?

J: Definitely. From my side as product manager for Canvas, I’d love to have customers and partners think of this as the way you can turn Salesforce into your command center. All your end users want is to be able to get their job done as quickly as possible so they can sell more or close more cases or whatever it is they need to do.


D: Excellent. So what are some real-world situations where customers are using this feature and seeing the benefits from it?

J: We’re in a pilot phase right now, so there’s a lot of experimentation and proof of concepts being done, but I have seen some good examples recently. Most of what I’ve seen is customers leveraging existing apps.

D: That makes sense.

J: For example, a customer may have an existing task management system where their users log all of their calls. While they are in the process of migrating over to Salesforce, their users continue to use the existing task management system. So instead of forcing their users to learn a new tool and lose productivity, they can leverage the task management system from within Salesforce. Their users can still create tasks and continue to use the same business process within the current system, but yet they’re working within Salesforce. At the same time, it starts to build the connection with end users that Salesforce is the CRM product and what you want your users to work in.

In addition to making development easier, canvas apps enable to you to increase your adoption by enabling users to reside within Salesforce on a more regular basis.

D: This feature is also very relevant for partners, isn’t it?

Yes, so that’s an example of how a customer is using Canvas. From the partner side, it becomes a little more interesting in some respects. Our current ISV partner strategy is really powerful. Our ISV partners have the ability to create very rich applications on the platform, list them on the AppExchange and then monetize their apps by selling them to our joint customers. So Customer A could develop an app that Customer B could then install in their organization.

Now with Canvas, we start to leverage our partners’ off-platform content. So if a partner has an existing product and they want to leverage that within Salesforce, rather than having to re-code it from scratch to bring it into Salesforce, they can use Canvas. They can use a hybrid approach where some of the content, like a custom object, is native to Salesforce and some of the content is off-platform. This is a big win because now our partners no longer have to completely redesign their apps from the ground up. We allow them to take advantage of their IP and what their brilliant developers have already built.


D: Interesting. And like you said, you’re not just exposing an existing application in the UI, but you can also start integrating your apps with Salesforce by bringing Salesforce data into your app and also going the other direction and saving data to Salesforce.

J: Exactly, and this is a question I get a lot: “Where’s the new technology? I’ve always been able to do this inside Salesforce by putting an iFrame inside a Visualforce page. Where’s the differentiation between this and Canvas?”

D: Yeah, good question!

J: If you’ve built such a solution in Salesforce, it works and there’s nothing wrong with it. But with the Canvas framework, we’ve done a couple of things that standardize development and make it easier for your developers. The first part is the connected apps framework. Connected apps are a way to allow third-party apps inside your system without giving them the full access rights of the end user using the app. Currently, if you build a Visualforce page and do this, you end up sending your user session ID to the third-party app.

Now, this works great, but the problem is that this session ID has full access as the user, which may or may not be what you want. A lot our larger enterprise customers don’t want to give third-party applications the “keys to the kingdom” so to speak. With the connected apps framework–which canvas apps leverage–developers have the ability to only request the scopes of access needed. For instance, if your app needs to use the Chatter API, you can specify that level of access. Or if your app needs to call the standard REST or SOAP APIs, you could specify that level access. This makes administrators much more comfortable installing those apps. Plus, it’s a much better way to lock down access to Salesforce.

The second part we offer is an XHR bridge. One of the big problems with iFrames and mashup UIs is what’s called the “same origin policy.” This is a Web standard that says if you have content from one domain being displayed in a frame from another domain, the app can’t take over and make calls directly to the parent frame. This is to protect the end user because if this was allowed, an app in an iFrame could take over a user session and gain access to information that it shouldn’t be able to access. In a nutshell, this policy prevents an iFrame from communicating with its parent container.

To work around this, in Visualforce, for example, what developers do is make server to server calls. The third-party app has the user session ID, and if it needs to make an API call, it makes it from the third-party app server to the Salesforce server. The Salesforce server then responds back to the third-party app server which then passes the info to the third-party app. So it’s a longer round trip.

D: Yeah, there’s a lot of chattiness there.

J: Right. With Canvas, there’s an XHR bridge. So the canvas SDK takes the request from the app inside iFrame and posts it to a listener. The listener then makes the request on your behalf. Let’s say you wanted to update an account record from your Web app. The iFrame would communicate with the SDK and pass it the account info to update. The XHR bridge then passes that request to Salesforce, the account is updated, and then the response is sent from Salesforce back to the Web app. This is all done in the browser. So it saves that full round-trip request, and makes it easier and quicker.

The third part is that we have some preferential placement inside of Salesforce. Your canvas app can be exposed on the Chatter tab and on Visualforce pages. In the future, we’d like to have even more places where your canvas apps can be exposed. Visualforce is powerful, and anywhere you can have a Visualforce page, you can now have a canvas app. But up until now, you haven’t been able to break into the Chatter tab.


D: That’s a great summary of all the benefits of Canvas. So for developers that are looking into how to integrate their existing Web apps, what are some considerations? Is it a complex process?

J: I like to think of it as being as complex as you want it to be [laughs]. With this framework, you can do a simple surfacing of your Web app where you simply display your app within Salesforce. For example, you might have a great weather app that you want your users to have access to. In that case, you may not need the communication between your Web app and Salesforce. That’s extremely simple. You wouldn’t have to make any changes to your app-you could simply create the canvas app, give it the URL of the Web app, save it and you’re done.

On the other hand, if you have an application like SAP, for example, it would be a more complex scenario. You’d have to leverage the SAP framework to build the UI that you want to display in Salesforce. Then you would use the Canvas SDK from within that framework and build the logic to, say, retrieve an SAP order and then save it as an opportunity in Salesforce. You can really handle any size integration with Canvas whether it’s a simple informational app or a very complex app.

One of the biggest challenges with Canvas isn’t the integration layer, because in most cases, your team already knows that side of it and they know what they want to connect with Salesforce. The more difficult part is the fit-and-finish UI piece. As part of the SDK, we give you some CSS recommendations to help you match the look and feel of your Web app to that of Salesforce. Ideally, this makes it as seamless as possible to the end user. This means your developers may need to make some UI changes to your app.

If your Web app is bright green and red and you just stick that right inside the Salesforce blue and white theme, it would be somewhat jarring to the end user. And it would highlight the fact that it’s content from a different system. You can use the SDK and the CSS files that we provide to give your users a seamless UI experience.

D: On that note, it’s good to highlight some of the challenges partners and developers might face so that they’re prepared when they start looking at the scope of integrating their Web apps. Are there any other things you think developers should start thinking about as they start investigating this?

J: As you start to think about moving your Web apps into Salesforce using Canvas, you want to start thinking about how tightly coupled you want the information to be between your Web app and the Salesforce organization.

In some cases, you don’t want any coupling at all and you want to do queries back and forth, and there’s nothing wrong with that. But as you start to develop links between your data and the Salesforce data, it’s really important to map that out. You want to understand which objects and fields on your app side map to which objects and fields on the Salesforce side. You want to consider whether you’ll need to create some new custom objects to hold this information. Like any development project, the more time you spend on design, the easier the development is.

D: Absolutely. Measure twice and cut once. What’s a good way for developers to get started using Canvas?

J: With the Spring ’13 release, every new Developer Edition organization has Canvas automatically enabled. If you have an existing Developer Edition organization that doesn’t have the feature enabled, just go ahead and file a support ticket and we can enable the feature. If you have an existing Enterprise or Unlimited Edition organization or a sandbox organization that you like to use to test out Canvas, do the same thing–file a support ticket and we can get that enabled.

There is one consideration related to the connected apps framework, which as we mentioned previously, canvas apps use. If you have existing remote access applications inside your organization, they’ll need to be migrated to the new connected apps framework, which may require some code changes. If you have existing remote access applications, let the support team know when you file the ticket and we can work with you on the best way to enable the feature.


D: If a developer wants to quickly start looking at canvas apps, isn’t there a quick start feature?

J: Right, we have a couple of good resources to help developers get started. The first is your Canvas Developer’s Guide.

D: That’s right, there’s a super-simple quick start that developer’s can use to get an idea of how the feature works.

J: There’s also an excellent page on Developerforce that’s our portal to all the Canvas resources.

We’ve also created a really interesting quick start with our Heroku platform. If you’re not familiar with Heroku, they have what’s called a polyglot platform, which means you can run different languages on this platform in the cloud. With Heroku, you can create a Java application, host it on Heroku and have an app up and running very quickly. But you can also create apps in Ruby, PHP, Python, and so on. Since Heroku is a part of the ecosystem, it is a great way to get up and running quickly.

D: So they’ve got options!

J: Indeed. And with Canvas, we have a Heroku quick start right within the Salesforce application. In the Canvas App Previewer, you just click the Heroku Quick Start button, fill out a few fields, and then it will spin up either a Java or Ruby app. It’s a simple “hello world” app that displays some information for the current user.

D: It sounds like this quick start encapsulates the whole canvas app process.

J: Exactly. The process only takes about 30 seconds if you have a Heroku account, and you’ll have a Heroku application up and running that displays inside of Salesforce. It’s a very easy and quick way to get started. It creates the app on the Heroku side and also creates the canvas app on the Salesforce side that actually exposes that Heroku app.

It’s a “hello world” app, so it’s very simple. But it shows you examples of how the app handles passing context so that your Web app can get information about who the Salesforce user is. It also shows you how to do calls back through our XHR bridge by posting from the app to the current user’s Chatter feed. So it’s really a good first step into the world of Canvas.


D: Great! Thanks so much for taking the time to talk with us and paint a picture of what this feature is and how customers can use it. Any final thoughts you’d like to share?

J: I encourage customers to start testing the feature and getting their feet wet to see how it might work in their organizations. I want to let everyone know that we’re still in pilot, and I’d love to hear where there are gaps in the functionality or features that would be helpful. If customers have any feedback, they can contact me directly at

Also, I’m very interested in seeing the projects that our customers and partners come up with. So as you’re developing with Canvas, keep me in the loop and let me know what you’re building and how you’re leveraging the ability to communicate with Salesforce.

D: OK, that’s an open call for feedback!

J: Definitely.

D: Thanks, Jay.

J: No problem. Thanks, Dianne.

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS