What are Sandbox templates?

Sandboxes contain copies of your organization’s configuration and (optionally) data. Use sandboxes for training or to test, configure, and deploy changes to a production organization. Full sandboxes are particularly useful for development teams to coordinate testing and deployment to production organizations.

Previously, when you created a Full sandbox, all of your organization’s data was copied to the sandbox. Now, Sandbox templates let you pick-and-choose specific objects and data to copy to a Full sandbox, save your preferences, and then reuse the template for new Full sandboxes.

Why Use Templates?

Sandbox templates:

• Give you the ability to keep sensitive data from a Full sandbox.
• Control the size of a Full sandbox. Smaller sandboxes are created and refreshed more quickly than large ones.
• Maintain multiple, reusable templates for different use-cases and development teams.

Sandboxes are now easier to use, too…

The Summer ’13 release also includes an enhanced Sandbox user interface.

The new pages:

• Tell you how many of each sandbox license you have (and how many are in use).
• Provide more information about each type of sandbox to help you decide which one to use.
• Walk you through the steps to create a new sandbox.
• Include Sandbox Templates and Sandbox History tabs with detailed information to help you manage your templates and sandboxes.

Want to see this in action?

You can view a video demo in the Summer ’13 Release Training page.

In the Force.com section, click “Play Now” and view the Sandbox topic of the video.

Related Resources

For other information about Sandboxes, check out the DeveloperForce Tools and Toolkits page, the Sandbox Overview in the Salesforce online help, and the Development Lifecycle Guide.

This training contains high-level information about what’s new in the release. It appears in a fancy UI that contains a module for each feature and lets you select which modules you want to watch. Watching all the platform modules will take you about 40 minutes.

The highlights include:

• Setup UI – Watch a demo of how to enable it and see one-click access to Setup in action.

• Apex – Learn about this grab bag of new Apex features including general availability of Chatter in Apex, test method changes, and limits consolidation.

• Force.com Canvas – Now generally available, learn more about the feature and how you can use it to integrate your Web apps (written in any language) into Salesforce.

• Developer Console – Get the scoop on a passel of UI enhancements that make the Developer Console more flexible and easier to use – new menu bar, code autocomplete, and other features that give you more real estate for working with code.

• Formulas – Find out how to use owner lookup fields and checkbox formula fields.

• Identity Management – See what’s new in identity management including the new login page, single sign-on updates, and new APIs.

• Permission Sets – Learn what’s new in permission sets like how to use them to assign record types.

• Sandbox Templates – Get more control over sandbox creation and enable reuse with new sandbox templates.

• Schema Builder – See what’s new in the tool that lets you see your custom objects and relationships graphically.

• Site.com – Get up to speed on new features such as the Site Administrator role, the ability to create reusable widgets, IP restrictions, availability in sandboxes, and support for communities.

These are just some of the many new platform features in this release. See the release notes for more info.

As I write this, it’s my favorite time of the release. I’ve written all of my documentation and release notes for Summer ’13, and I’m waiting to see what our customers will do with all of the new features. And there are a lot of new features–the release notes top 275 pages, a new high!

One of the things I spent a lot of time on doesn’t rate even a sentence in the release notes. How can that be? The topics were for existing functionality. On the Doc Team we call this “legacy doc work.” It’s immensely satisfying to do, even if, since only the doc is new, there’s no trace of it in the release notes.

The improvements I worked on are substantial expansions and clarifications to the Visualforce Developer’s Guide material covering global variables, in particular the following:

• $Setup — Somehow this global, which gives you access to custom settings, had escaped being documented entirely! I can’t take credit for fixing that; Eric Wilson, the Product Owner for Visualforce, wrote the new documentation for it, which I edited and expanded a bit.
• $Action — Existing information about available $Action values was pulled into the Visualforce Developer’s Guide, to make the entry for $Action more complete. There’s also new sample code that shows how to conditionally enable or hide links to those actions–for example, not showing a New button if the user can’t create new records–to create slick, intuitive pages for your users.
• $Component — The behavior, use, and best practices for using $Component were researched, and the new documentation for it should be more complete and clear. In particular, the requirements for using $Component to reference nested Visualforce components from your non-Visualforce code (usually JavaScript) should be much easier to understand and use.
• $ObjectType — This is the big one. The documentation for $ObjectType has been a source of frustration for me when writing sample code, and I simply couldn’t find enough information about how to use this powerful tool for introspecting sObjects in an organization. The additions in the Summer ’13 version of the Visualforce Developer’s Guide expand the material 500% or more. If trying to use $ObjectType has frustrated you in the past, I hope you’ll give the Visualforce Developer’s Guide another chance to help you out.

The documentation for the rest of the global variables was also reviewed and edited. And in addition to content changes, I reworked the structure, so that it should be easier to find the specific documentation you’re looking for, in the table of contents, index, via “see also” links, and so on.

We don’t often have the luxury of going back and expanding existing doc, because the engineers keep us so busy writing about all of their new features. Our global variables became a pet project, or maybe an obsession, and getting it into this release makes me really happy. I hope it’ll make it easier for you to use these very useful tools in your Visualforce applications.

D: Jay, thanks for meeting with me.

J: No problem.

D: So today we’re going to talk about versioning of the Force.com Canvas SDK. What’s that all about?

J: Well, I thought I’d cover three main points: why we did it, what we did and the migration path for developers.

D: Sounds great.

J: I’ll start with why we did it. As you know, Winter ’13 was the first release of the feature in pilot including the SDK on GitHub. As we were working on the feature for the following release, Spring  ’13, we realized that we were going to have to add new functionality and change some functionality. So one of the side effects of those changes was that the SDK would break compatibility.

We looked at what the other teams in Salesforce–like the API team and the Chatter team–were doing around versioning and how they support backwards compatibility. As a result, we felt this was the best thing to do now and long-term for our customers and partners that are using Force.com Canvas.

In a nutshell, we’re versioning each release of the Force.com Canvas SDK such that when we go from Winter release to Spring release or Spring release to Summer release, our customers’ code isn’t going to break. Essentially, versioning allows us to support backward compatibility.

D: So that explains the “why.”

J: Right. Now, for what we did. At the mechanical layer, we implemented versioning by adding version information to the signed request. For Spring ’13, the version is 27.0 which aligns with our API versions.

Here’s an example of the version information in the signed request:
"version":
{
"api": "27.0",
"season": "SPRING"
}
As a developer, when you make a call back through the Force.com Canvas SDK into Salesforce, you provide the version of the SDK that you’re using. Then on the Salesforce side, we can see ‘Oh, they’re using version 27.0.’ We then know what the SDK expects in the JSON being returned and can send back the correct information.

D: It’s great that the versions match the version of all the other APIs.

J: Exactly. So version 27.0 came out in Spring ’13. When we move to Summer ’13, everything will go to version 28.0, and so on.

D: Finally, you were going to talk about migration?

J: Now when we start to think about how to migrate existing canvas apps, it can be a little bit tricky depending on what your canvas app does. The process varies for each customer depending on how they’re using the Force.com Canvas SDK.

If you have a simple Web app exposed as a canvas app, and it doesn’t use the SDK–a clock app, for example–then your app won’t break. That said, we still recommend that you upgrade and upgrading will be pretty straightforward. If you’re not using the authentication piece and you’re not making AJAX calls back and forth, then it’s not too difficult to upgrade.

Similarly, if you’re just using canvas as a means to get the authentication information for Salesforce and perform server to server side calls, your app may still function.  So, if you use the signed request to pull out the OAuth token and then you’re using that token to make a SOAP API call from your server to the Salesforce server, your canvas app may still work.

Really, it’s only if you’re making cross-domain calls using our XHR bridge, that’s when you’re going to have to make some changes.

D: That’s good to know. So, if someone’s being testing out Force.com Canvas in the pilot version, and they don’t have a complex integration, then upgrading won’t be too difficult.

J: Right. The structure of the signed request JSON that we send back has changed, so they should upgrade. And you can see the structure of the signed request in the Force.com Canvas Developer’s Guide.

We’ve moved a few things around, for example, the OAuth token used to be at the root level, but now it’s inside of the Client object, added version information, things like that. So we recommend that everyone upgrade to the latest and greatest.

Just to clarify, when I say “break,” it’s not that your canvas apps are now unsecure or you’re going to lose data or anything like that. But since we moved things around in the signed request JSON and relocated fields in the Client object, your canvas app may not work as it did previously.

D: Can you give an example of one of those changes?

Sure. So, for example, in code prior to Spring ’13, when making a call in, in the AJAX call, you’d set the token to be equal to your OAuth token. There was a key/value pair with the key name being “token” and the value being your scoped access token. In the new version, instead of having the token key, we have something called a client key. The Client is actually an object that contains other information in addition to the token.

D: Great, thanks. Developers can get the latest version 27.0 of the SDK on GitHub, right?

J: Exactly, it’s on GitHub at https://github.com/forcedotcom/SalesforceCanvasFrameworkSDK. If you need the previous version, the readme.md explains how to check it out.

D: Awesome. Thanks for explaining this!

J: No problem, Dianne. We are definitely excited to see what our customers and partners build using Force.com Canvas.

Force.com Canvas is an exciting new feature for integrating new or existing Web apps into Salesforce. I sat down with Jay Hurst, the PM for Force.com 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 Force.com Canvas.

THE 10,000-FOOT VIEW

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

J: Sure can, thanks, Dianne. Force.com 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 Force.com 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 Force.com 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 Force.com 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 Force.com Canvas, you would first define your app URL, for example, www.test.com/canvas.jsp. 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 Force.com 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.

FORCE.COM CANVAS IN THE REAL WORLD

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 Force.com 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 Force.com 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 Force.com 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 Force.com 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.

THE TECHNICAL DETAILS

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 Force.com 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 Force.com 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 Force.com 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.

DEVLOPER CONSIDERATIONS

D: That’s a great summary of all the benefits of Force.com 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 Force.com 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 Force.com Canvas whether it’s a simple informational app or a very complex app.

One of the biggest challenges with Force.com 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 Force.com 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 Force.com Canvas?

J: With the Spring ’13 release, every new Developer Edition organization has Force.com 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 Force.com 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.

HOW TO GET STARTED

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 Force.com 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 Force.com 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 Salesforce.com ecosystem, it is a great way to get up and running quickly.

D: So they’ve got options!

J: Indeed. And with Force.com 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 Force.com Canvas.

WE WANT YOUR FEEDBACK

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 jhurst@salesforce.com.

Also, I’m very interested in seeing the projects that our customers and partners come up with. So as you’re developing with Force.com 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.

Great, you say, sign me up.

You bet, we say. It’s not as easy as flipping a switch, though. You’ll need to do a little behind-the-scenes work to configure state and country picklists so that they work in your organization.

First, you’ll need to configure the picklists in the Metadata API, then you’ll scan your organization to see where text-based state and country data is used.

Next you’ll convert existing data and fix existing customizations so they work with the new, standardized values, and then, finally, you can enable the lists for your users.

The State and Country Picklists page in the Data Management area of Setup is your home base for preparing your organization to use the picklists. The process is outlined and most of the steps can be executed right there. You can also click Help for this Page to get complete documentation for the feature.

The most opaque step for administrators is probably the first one—configuring the picklists in the Metadata API. Using the Force.com IDE, you’ll need to edit the AddressSettings metadata component, which is new in Metadata API 27.0. AddressSettings allows you to control (1) what picklist values appear in the Salesforce UI and (2) how to map existing, text-based state and country values to new picklist values, so you can convert those old values to new values using the address conversion tool in Setup. The AddressSettings component has four fields for each state and country you enable, and it will look something like this abbreviated example when you’ve configured them:

<?xml version="1.0" encoding="UTF-8"?>
<AddressSettings xmlns="http://soap.sforce.com/2006/04/metadata">
<countriesAndStates>
<countries>
<active>true</active>
<integrationValue>United States</integrationValue>
<isoCode>US</isoCode>
<label>United States</label>
<states>
<active>true</active>
<integrationValue>Alaska</integrationValue>
<isoCode>AK</isoCode>
<label>Alaska</label>
</states>
</countries>

<countries>
<active>true</active>
<integrationValue>Canada</integrationValue>
<isoCode>CA</isoCode>
<label>Canada</label>
<states>
<active>true</active>
<integrationValue>Alberta</integrationValue>
<isoCode>AB</isoCode>
<label>Alberta</label>
</states>
</countries>
</countriesAndStates>
</AddressSettings>

For more information on state and country picklists, including the limitations of the beta release, see the Spring ’13 Release Notes or State and Country Picklists—Beta on the Salesforce Help and Training portal. For information on using the Metadata API, see the Metadata API Developer’s Guide, and for information on the AddressSettings component, specifically, see AddressSettings. To give us feedback on state and country picklists, go to IdeaExchange.

The Force.com Tooling API Developer’s Guide describes new SOAP and REST interfaces that allow you to build custom development tools for Force.com applications. Using Tooling API, you can:

• Add features and functionality to your existing Force.com development tools.
• Build dynamic modules for Force.com development into your enterprise integration tools.
• Build specialized development tools for a specific application or service.

You can find all the preview developer docs on the Documentation page under “Preview: Reference Documentation, PREVIEW Spring ’13 (Version 27.0)”.

To see the preview release notes, click here (PDF).

Stay tuned for more announcements, and don’t forget to register for the Spring ’13 Release Developer Preview webinar on January 30, 2013 to get an overview of the key features you shouldn’t miss.