Salesforce 1 Platform.png

In this article, you’ll get a broad introduction to many of the key concepts and features you’ll need to understand before you begin designing and architecting apps that leverage the unique power of the cloud application development platform.

Orgs, Sandboxes, and Change Sets

The traditional application development lifecycle (ADLC) usually involves several on-premises systems.

  • A production system (database server, app server, etc.) to support the production application in use with end users.
  • One or more development systems to support developers as they build new application features.
  • One or more test systems to support the quality assurance (QA) team as they test new features.

Each system in this equation usually requires a team of administrators to install, configure, and maintain (patch/upgrade) complex system software—software that might also require a license and ongoing support contract. Sysadmins are also in charge of backing up databases, monitoring system performance, tuning, and configuring the production system for disaster recovery and failover. All these requirements are significant capital expenditures and typically slow down project development and deployment.

When your app uses, all the complicated, time-consuming, and costly problems related to server provisioning, configuration, and management don’t exist thanks to orgs, sandboxes, and change sets. A organization, or just org for short, can be thought of as a related set of systems that you use to build and deploy cloud apps. Every account automatically comes with a production org ready to go—but that’s not where you typically do your development. When you’re set to begin building your app, with a few clicks of your mouse, you can create a sandbox org, which is a structural (no data) or full clone of your production system that your team can use for development or testing. Once this work is complete and you want new app features to go live, you use a simple point-and-click user interface to build, push, and deploy change sets that move metadata from sandbox into production. Should you need to make a quick fix in production and push these changes back to a sandbox, you can do that, too. Best of all, there’s no waiting around for sysadmins to fit these otherwise blocking tasks into a busy schedule.


Keep in mind that is responsible for managing all orgs, not you. We handle all the heavy lifting of software installation, configuration, scaling, and performance optimization as well as data back up and disaster recovery. So with, you can allocate more of your team’s budget and human resources to adding value to your apps rather than to managing and solving IT headaches.

[ More Information about lifecycle management ]

Schema Objects

You’ve got your account, you’ve created a sandbox in a matter of minutes, and now you’re ready to get started building a schema to support your app. Here’s a quick introduction to some of the key terms and concepts related to schema objects that you’ll need to understand before you begin.

Objects (aka Tables) and Fields

Everyone who’s used a relational database knows that the primary database storage structure is a table, a data structure that has a set of fields (columns) with specific data types like text, date, and number. Apps manage table information by creating, reading, updating, and deleting records (rows).

With, the primary data structure is called an object, which, with a few additional features, is more or less the same concept as what you think of as a table.


  • Every object has several standard fields that automatically manages for each record, including an Id field that contains a primary key value, plus Owner, CreatedBy, and LastModifiedBy fields that contain the Ids of the users who own, created, and last modified the record, respectively.
  • Every object also has a Name field that the application manages to store a natural reference key for each record. For example, it’s probable that an app would refer to records in an Album object using the field Album Name, and records in an Account object using the field Account Number. Apps commonly reference natural keys like these as labels in lists and hyperlinks, so has internal optimizations for retrieving natural keys quickly and efficiently.
  • For custom fields, supports typical scalar data types that you might expect such as date, number, and text. But there are also rich data types such as checkbox, currency, email, phone, picklist, and url, with built-in functionality that saves your crew otherwise error-prone app development chores.
  • supports auto-number and formula field types that you can leverage to automatically populate data rather than building your own custom app logic.
  • Master-detail and look up relationship fields make it easy to associate two objects. There’s no need to declare primary and foreign keys, configure related indexes for join performance, etc.

[ More Information about database concepts ]

Declarative Logic

Most organizations have processes that are more efficient and reliable when you automate them. You can easily automate a significant percentage of your business processes without the burden of writing and maintaining code thanks to workflows. Using a simple UI, you can quickly configure conditional workflows that, when triggered by the creation or update of a record, update fields in your database or send outbound messages to other systems. In a nutshell, think of workflows as a declarative alternative to programmatic database triggers.

Qs12 rule.png

[ More Information about point-and-click app logic ]

Procedural Logic and Apex

If declarative workflows don’t meet your specific needs, then it’s time to turn to a programmatic approach using Apex,’s procedural language. Apex, very similar to Java, is akin to the procedural languages most database systems have to build stored procedures, database triggers, and unit tests that implement reliable, database-centralized, complex business logic. Here’s a quick look at some examples of how you can use Apex with

Apex class methods are named, database-side code blocks that centralize common logic that one or more apps need to execute. (You might think of Apex class methods as stored procedures in a traditional relational database.) For example, you can use an Apex class method to implement a complex business operation that modifies related records in more than one object, all within the context of an ACID transaction. Using Apex classes, you can build a custom API for your apps by exposing class methods as Apex Web services (RESTful or SOAP).

An Apex database trigger is an Apex code block you associate with an object that automatically fires (executes) before or after an app inserts or modifies a record in the object. For example, the following simple trigger prevents the deletion of a master Invoice record when there are related child records in the Line Item object. Triggers let you program objects so they automatically react to state changes in data.


To handle complex long-running processes, consider building and asynchronously executing batch Apex. For example, batch Apex is perfect for when you want to build an archiving solution that runs on a nightly basis, looking for records past a certain date and adding them to an archive. Or you can use batch Apex to execute a data cleansing operation that operates in the background to scan an object and reassign specific records based on custom criteria. Batch Apex is easy to use: just code the class with your logic, schedule a method to execute or execute it directly, then monitor its progress as it runs in the background.

An Apex callout lets you tightly integrate your Apex with an external service by making a call to an external Web service or sending an HTTP request from an Apex script and then receiving the response. Apex callouts provide integration capabilities with Web services that use SOAP and WSDL, or HTTP services (RESTful services).

[ More Information about Apex ]

Native Apps and UIs

A powerful thing about is that it automatically creates user interface (UI) elements as you build your data model. Building native apps is almost too easy. On, a native app is a collection of components such as tabs, reports, dashboards, and pages that address a specific organizational need. Such UI components are easy to build with a point-and-click approach – no coding required!

Qs3 tabs.png

[ More Information about point-and-click app building ]

Native apps automatically have the same look and feel of standard platform apps (Sales Cloud, Service Cloud, etc.). When you want to customize a native app to look entirely unique, you can use the platform’s UI technology, Visualforce, a Web-based framework that lets you quickly develop sophisticated, custom UIs for desktop and mobile apps. Using native Visualforce markup and standard Web development technologies such as HTML5, CSS, JavaScript, and jQuery, you can rapidly build rich UIs for any app.


[ More Information about Visualforce ]

Integrations and APIs

In many scenarios, you might want to integrate external apps with your org, such as native mobile apps, apps hosted on other cloud platforms, or apps hosted in an on-premise data center. But how do you code an app to work with Earlier, you learned how you could create your own API with Apex Web services. Now you’ll explore several standard APIs that make open and flexible enough to meet the needs of any application development scenario.

RESTful and SOAP Data APIs

The ubiquitous adoption of the World Wide Web has triggered a tremendous shift to apps that rely on fundamental Web-related technologies such as HTTP and JSON. Along with this shift, Web apps are increasingly using lightweight RESTful APIs for interaction with the persistence layer.

To create, read, update, and delete (CRUD) data records in your org, apps can rely on’s REST API. Each resource in the REST API is a named URI that apps can use with an HTTP method (HEAD, GET, POST, PATCH, or DELETE).


[ More Information about the REST API ]

If your apps prefer SOAP to access data, also has a SOAP API. After downloading a WSDL that describes your org, apps can use the API to CRUD records in your org. To make using the API even easier, there are several language-specific toolkits that provide clients for the API in a particular language, which lets your developers use familiar technology and patterns to quickly access services available in Toolkits are available for many popular languages, including Java, JavaScript, Ruby, PHP, and more.

[ More Information about the SOAP API ]

Bulk API

For bulk processing sizable amounts of data,’s RESTful Bulk API lets you query, insert, update, upsert, or delete a large number of records asynchronously. You first send a number of batches to, which processes the batches in the background. As is processing batches, you can track progress by checking the status of the job. All operations use HTTP GET or POST methods to send and receive XML or CSV data.

[ More Information about the Bulk API ]

Streaming API makes it easy for apps to expose a near-real-time stream of data in a secure and scalable way with its streaming API. The API supports a publish/subscribe model in which you create one or more named topics, each associated with an SOQL query. Apps can subscribe to one or more topics, using the Bayeux protocol. As relevant data changes, the platform reevaluates the query and, when a change occurs that alters the results of the query, the platform publishes a notification to subscribed apps.

[ More Information about the Streaming API ]

Social API

See “Social Apps” on the following page for information about Salesforce Chatter and’s related social API.

Query Languages

Apps can use the Salesforce Object Query Language (SOQL) to construct simple but powerful database queries. Similar to the SELECT command in the Structured Query Language (SQL), SOQL lets you specify the source object, a list of fields to retrieve, and conditions for selecting rows in the source object. For example, the following SOQL query returns the value of the Id and Name field for all Account records with a Name equal to the string 'Alex':

SELECT Id, Name FROM Account WHERE Name = 'Alex' also includes a full-text, multilingual search engine that automatically indexes all text-related fields. Apps can leverage this pre-integrated search engine using the Salesforce Object Search Language (SOSL) to perform text searches. SOSL lets you search text, email, and phone fields for multiple objects simultaneously. For example, the following SOSL statement searches for records in the Lead and Contact objects that contain the string 'Joe Smith' in the name field and returns the name and phone number field from each record found:

FIND {"Joe Smith"} IN Name Fields RETURNING lead(name, phone), contact(name, phone)

[ More Information about SOQL and SOSL ]


Once you’ve got your schema along with an app’s user interface and business logic in place to manage data, how do you lock things down so that only the right users see the right data at the right time? The good news is that you don’t have to implement any complex code in your app because of’s ingrained security model. In this section, you’ll get a quick preview of powerful features you can use to quickly and easily build secure apps.

Users and User Authentication

Administrators can create and edit platform users for their organization, and grant permissions that users require to perform their job function. supports several user authentication options.

  • The default approach is the use of a username and password that the platform manages.
  • Single sign-on options include federated authentication via Security Assertion Markup Language (SAML), delegated authentication, and external authentication providers (Facebook, Janrain, etc.).
  • Salesforce Identity provides Identity and Access Management (IAM) for Web and mobile applications through the simplicity, transparency, and trust of the platform. Users sign in once into Salesforce Identity and gain one click access to configured applications.
  • OAuth (Open Authorization) is an open protocol to allow secure API user authorization in a simple and standardized way for desktop, Web, and mobile apps. implements the OAuth 2.0 standard, so users can authorize apps to access org resources (via the REST and SOAP Web service APIs) on their behalf without revealing their passwords or other credentials to those apps. Apps authenticate REST calls using standard OAuth 2.0 access tokens, and can receive data in both XML and JSON formats.


A profile is a collection of functional permissions and settings that control what users can do. You create and customize profiles to meet various types of application user requirements, and then assign each user to the appropriate profile. Profiles control the following types of access:

  • System-level access, including time- and IP-based login restrictions as well as permissions that apply to different functions within an organization, such as the ability to manage users
  • Object-level access, including CRUD permissions for each object in the database
  • Field-level access, including the ability to read or edit fields
  • Access to invoke Apex classes and custom logic

Record Sharing

Row-level security is easy to implement with because inherent in the system’s design is the notion of record-based access controls and record ownership. determines a user’s access to a specific record considering the user’s CRUD access (from the user’s profile), the object’s organization-wide default record sharing model (public or private), and the user’s sharing access (which defaults to full when the user owns the record).

To facilitate the sharing of private records with non-owners (standard users only), you can use one or more features, including roles, groups, declarative owner-based and criteria-based sharing rules, and programmatic sharing rules.

  • Users with the same role all live at a level of an organizational hierarchy in terms of access privilege requirements. Role hierarchies make it easy to automatically provide record access from lower to higher levels in a hierarchy (for example, a manager can access records that people in his/her group own).
  • A group is a collection of users who all require access to a common set of records. Create a group, add users or other groups to the group, and then share records with the group so everyone can access them.
  • You can easily declare sharing rules that determine with whom to share records based on record ownership or criteria based on field values in records. As the following figure demonstrates, let’s say you use a custom object for job applications, with a custom picklist field named “Department.” You can create a criteria-based sharing rule that shares all job applications in which the Department field is set to “IT” with all IT managers in your organization.
  • For unique situations when you need to share specific records with a user or a group, developers can build Apex managed sharing rules that programmatically share records in custom objects.


[ More Information about security ]

Social Apps includes Salesforce Chatter, which lets your developers embed social networking functionality into an application with minimal effort. Chatter-enabled apps let end users collaborate privately and securely by “following” each other, data records, and groups, and by sharing files and status updates. See what someone is up to. Follow the feed for a data record and get notifications when someone updates the record. These are just a few examples of the power of Chatter.


Internally, includes several core system objects that power Chatter. To associate them with your app objects, your apps simply leverage’s Chatter REST-based API to access feeds and social data such as users, groups, followers, and files. Rather than building and maintaining all this complex logic yourself in your applications, simply use Chatter when you want to integrate social functions into any of your applications.

[ More Information about Chatter REST API ]

Mobile Apps

The Salesforce Touch Platform is the next-generation platform that powers Salesforce's mobile applications and enables enterprises to build their own iPad, iPhone, and Android applications. The Salesforce Touch Platform is designed for a mobile world with applications built using modern, agile development practices. It leverages the power of the Salesforce Platform and its proven security, reliability, and scale for enterprise applications.

The Salesforce Touch Platform contains three core components:

  • for Touch
  • Mobile Container
  • Identity for Touch for Touch is a new layer of service in the Salesforce Platform focused on developing and administering enterprise mobile applications.

  • REST APIs provide access to enterprise data and services, leveraging standard Web protocols. Developers can quickly expose their business data as REST APIs and provide a single place to enforce access, security, common policy, and enforcement across all device types.
  • The Chatter REST API enables developers to quickly transform their applications with social networks and collaboration features. It provides access to the feed, as well as the social graph of user connections.
  • Connected Apps enables administrators to enforce their enterprise security policy on mobile applications in a world without perimeter security.
  • Geolocation provides location-based information to enhance your online business processes with geospatial data. The entire platform is location-ready, allowing spatial query functionality, such as radius-based searching.

Mobile Container (Salesforce Mobile SDK)

Developers can use the Mobile Container to build both native Objective-C iOS or Java Android Apps, or to provide a native container for HTML5-based hybrid apps. Wizards for iOS and tooling for Android make it easy to get started building native and hybrid apps.

The mobile container, part of the Salesforce Mobile SDK, includes:

  • Native device services that allow developers to easily add camera, location, and contacts into their application using a common set of APIs.
  • Secure offline storage that enables developers to build applications which continue to function with limited or no network connectivity.
  • Client OAuth support that frees developers from having to rebuild login pages and general authentication in their mobile applications.

Salesforce Identity

Salesforce Identity provides a single enterprise identity and sign-on service for connecting mobile devices with enterprise data and services, providing the following advantages:

  • Allows for single sign-on across applications and devices so users are not forced to create multiple usernames and passwords.
  • A trusted identity provider that you can leverage for any enterprise platform or application.
  • A cloud directory that enables enterprises to white-label identity services and use company-specific appearance and branding.
  • The ability to utilize consumer identity providers, such as Facebook for customer-facing applications, to quickly engage with customer social data.

[ More Information about the Salesforce Touch Platform ]

Web Sites is integrated with and lets you deliver web sites at the speed of social. Create once, publish anywhere — your own web sites, social channels like Facebook, where ever your brand lives.


For developers, provides you the tools to build, deploy, and scale stunning web sites with:

  • 24x7x365 availability
  • easy data consumption
  • customizable content management
  • transparent shared, secure, and scalable infrastructure
  • reusable templates and components

[ More Information about ]

Summary is a proven cloud application development platform that you can rely on to provide a management-free, scalable, and secure environment for any app. To begin the app development process, you self-provision a sandbox org and move changes to test and production orgs using change sets, all in a matter of minutes with just a few mouse clicks. It's easy to rapidly construct app schemas inside orgs using objects (tables) and server-side business logic, including declarative workflows and programmatic Apex stored procedures and database triggers. Once you’re ready to shift focus to app-side functionality, use the development language and platform of your choice, thanks to’s embracement of open, standards-based APIs (RESTful and SOAP) for managing both your schema’s data. Developing fast, secure apps that support social and mobile design requirements couldn’t be easier because of’s built-in features such as a full-text search engine for fast app navigation and record search, embedded system and data access controls for security, and the Chatter data model for social collaboration and data feeds for mobile apps. And don’t forget, it’s all backed by, the leader in cloud computing technology.

About the Author and CCE Technical Enablement

Steve Bobrowski is a member of Technical Enablement within the Salesforce Customer Centric Engineering group. The team’s mission is to help customers understand how to implement technically sound Salesforce solutions. Check out all of the resources that this team maintains on the Architect Core Resources page of Developer Force.