What's the point of canvas vs. connected apps, and what should I be thinking about when choosing between them?


We're in the process of building out a couple tools that will be integrated with our Salesforce instance and I'm weighing the pros and cons of canvas vs. connected apps (as well as Visualforce, but that's another question), and for the life of me I can't figure out what differences there are between the two that would matter from an architect perspective.

So far it seems that, both provide a way to get an access token, can be run on any servers, can use any development language. So what's the deal?

3 Answers 3


Canvas App

Canvas apps are designed to the part of the user interface. Either the app is designed to appear to be native to salesforce.com, like a Visualforce page, or is intended to be accessed through salesforce.com, such as legacy cloud apps. Authentication for a canvas app is server-initiated and controlled by profiles and permission settings. The app cannot be accessed outside salesforce.com unless it provides an alternative login mechanism. The session lifespan is only as long as the user is logged in to the user interface. The app has full access to the user's data, just as any normal API-style application. The app must be cloud-based. Access is automatically granted.

Connected App

Connected apps are designed to be run independently of the user interface. Either the app is hosted on an external website that interfaces with salesforce.com, or is a desktop or mobile app that runs on a client. Authenication for a connected app is client-initiated and must be done per-client. Connected apps are usually accessed outside salesforce.com, although this is not a stringent requirement. The session lifespan may be indefinite until revoked by the user or an administrator. the app has limited access to the user's data (referred to as the scope), which may be as minimal as identity confirmation only up to full access. The app may be run on a server or client. Access must be manually granted.


Canvas apps excel at providing services that are accessed through the user interface of salesforce.com. For example, a service that provides salesforce.com users the ability to send mass emails could be implemented as a canvas app. The app doesn't need to be run when the user is not log in, and doesn't have any meaningful context outside salesforce.com. The app doesn't request a username, password, or security token, because the authentication is initiated by the server. From the user's perspective, the integration is seamless, and they may not even be aware that they are running an application on a third-party server. This design model is identical to API-enabled programs that are accessed through a web tab by providing a session ID; this mechanism is meant to replace that model of logging in. It has better security because the administrator can control access per-profile, while the old model only permitted either all-or-none access to any API via the "API Enabled" permission. Note that the API must still be enabled, but even when enabled, if a user doesn't have access to the app, they won't be able to access it.

Connected apps, on the other hand, are intended to be accessed outside of salesforce.com. While there are still profile- and permission set-level controls, an initial authorization still has to occur. Depending on the app, the user may need to provide a username, password, and security token, although the "web flow" can still be used to obtain a token. Unlike a canvas app, this app now has access to the system for as long as the access token remains valid. This could be days, weeks, months, years, forever. Each individual client has its own authorization token, and this token can be revoked as necessary. For example, an instant messaging system that leverages salesforce.com's Chatter would be a connected app. If the device is lost or stolen, the authentication token can be revoked, removing that client's ability to use the system. Since the username, password, and token are not stored by the client, there is no way the device could access salesforce.com data once the authenication token is revoked. Login is not seamless, though, so one wouldn't ordinarily want to simply place a connected app in a web tab, since the user would have to grant access.


Generally speaking, there are a few pertinent questions that will decide which mode of access you want to use:

  • Should the app appear in the UI? (yes: canvas, no: connnected)
  • Does the app need long-lived access to the system? (yes: connected, no: canvas)
  • Does the app run on a client? (yes: connected, no: connected/canvas)
  • Should the apps access be limited by scope? (yes: connected, no: connected/canvas)
  • Can the app be lost or otherwise physically compromised? (yes: connected, no: canvas)
  • Does the app provide functionality outside salesforce? (yes: connected, no: canvas)

Common Examples

These examples are just like other popular APIs out there, such as Facebook or so-called "social APIs".

  • A news website that lets you Chatter about articles: connected
  • A mass emailer app that lets you email from a variety of mailing lists: connected
  • A website that lets you log in to your account through salesforce.com: connected
  • A desktop data loader application: connected
  • A blog that Chatters about new articles and comments: connected
  • A custom calendar that appears in salesforce.com and pulls data from other sources: canvas
  • A mass emailer that can only be used with salesforce.com: canvas
  • A legacy application an enterprise uses that needs to be exposed through salesforce.com's UI: canvas
  • A data cleansing tool that runs inside salesforce.com: canvas
  • A bug tracker app that appears inside the salesforce.com UI: canvas


A canvas app is an "embedded app," similar to older applications that accepted a session ID in order to use, classically like a S-Control tab, but with better permission control.

A connected app is an "API app," similar to older applications that used a username and password to obtain a session ID in order to use, but can be revoked from the system, have a longer session lifespan than a session ID, and have fine-tuned controls to limit access as necessary.

  • 10
    If only I could award the bounty twice. Thanks @sfdcfox for this excellent contribution to the community :) Commented Aug 21, 2013 at 1:04
  • 17
    Excellent answer; just a couple of minor points: (1) canvas apps are a subset of connected apps and (2) access to connected apps is under the control of the admin - default is 'all users may self-authorize', but you can set it to 'admin approved users are pre-authorized', and authorized a number of profiles/permission sets - those users won't see an authorization page when accessing the app.
    – metadaddy
    Commented Aug 21, 2013 at 16:51

Practically, canvas apps are accessible inside salesforce and can be build using any language of your choice. By this, I mean we can interact with salesforce from a external application, but within salesfore and with an interactive UI. Canvas don't work in offline mode as they have an UI, but connected apps can access data from salesforce even if user is offline and performs various operations on behalf of the user. Connected apps are used in integration which can control salesforce organization on behalf of it. They are just authorizing gateway for app administrator to app user.

  • 5
    Summary: canvas apps run inside a salesforce.com context as a tab, connected apps run outside salesforce.com but use salesforce.com as the authentication mechanism or data source (depending on what permissions are requested/granted).
    – sfdcfox
    Commented Aug 15, 2013 at 18:14
  • @sfdcfox canvas apps are just in an iframe, is that really any different than running outside the salesforce context? i.e. why not just run a connected app from within a tab ... Commented Aug 15, 2013 at 20:03
  • 2
    The difference is seamless integration. The canvas app will be logged in automatically (assuming the user has access), while the connected app will have to have extra logic for authorization. Look at both source code examples and you'll see the difference.
    – sfdcfox
    Commented Aug 15, 2013 at 21:07

I want to explain this in a different way. Some of the difference between the two is lying within the settings for canvas app as below. As soon as you click that little checkbox called 'Canvas' within connected app, all of canvas app framework features activated automatically, and some can be configured through below settings.

enter image description here

BTW, canvas app is also a kind of connected app. You can consider canvas app as connected app with some enhanced features to make it work seamlessly with external apps within Salesforce UI. Some of these additional features are:

  1. As you can see, canvas app settings has 'Access Method' option which simplifies the way your connected app is getting authenticated and authorized. This is important when you want to have your canvas app do authentication and authorization behind the scene without having user know about it.
  2. Canvas app framework provides Lightweight and easy-to-use JavaScript libraries.
  3. Canvas app framework natively provides 'Context Services' which tells more about the logged-in user, what org are they in, how much area does the canvas provide to display etc.
  4. It natively allows cross-domain API calls.
  5. It is based on lightweight JSON eventing framework which allows your apps to publish and subscribe to events. (the events are sent through Canvas API).

So, in summary, above said additional features on top of connected app makes a canvas app.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .