Salesforce.com was initially created as a Sales Force Automation (SFA) / Customer Relationship Management (CRM) application in the cloud but has evolved over the years into a modern platform for all types of enterprise applications. Now the Salesforce name is a legacy artifact of that past. This is like the name Frigidaire which is still the name for a company that now produces much more than Frigidaires (i.e. Refrigerators). The Salesforce1 Platform still provides the SFA & CRM applications but is also a foundation for building modern systems.
Pricing & Additions
The Salesforce1 Platform comes in many editions and packages, like the Sales Cloud edition for CRM and the Platform edition for anything. The edition you choose will enable different features and provide a different foundation to start with. Check out the full list of editions to see the pricing and features for each option. The Developer Edition provides a free platform for developers.
Now lets go through the many different components of the Salesforce1 Platform from the 30,000 foot perspective.
Metadata-Driven Data Model
At the core the Salesforce1 Platform is a cloud database. That database is customized and configured via metadata. The metadata that defines the data model can be modified via XML definitions and via a point-and-click UI. The metadata for a tenant environment, known as an ‘organization’, or ‘org’, is versionable, packageable, and testable. An object or table is called an SObject and provides a bunch of out-of-the-box features:
Custom Fields
Validation Logic
Field-level Security
Relationships & Pick-Lists
Derived Values
All SObjects automatically provide:
SOAP & REST APIs
Basic CRUD-ish UIs
Mobile CRUD-ish UIs via the Salesforce1 mobile app
Indexed Search
Fields on SObjects can be any of the following types:
Auto Number
Formula
Roll-Up Summary
Lookup Relationship
Master-Detail Relationship
Checkbox
Currency
Date & Date/Time
Email
Geolocation
Number & Percent
Phone
Picklist & Picklist Multi-Select
Text, Text Area, Encrypted Text
URL
New organizations on the platform come with a number of out-of-the-box SObjects which differ depending on which edition of the platform you are using. For instance, new organizations using the Sales Cloud edition come with SObjects including Contact, Lead, and Opportunity.
Built into the Salesforce data model are essential security features like change auditing and field-level security.
Managed Runtime for Programmatic Customizations & Extensions
A system on the Salesforce1 Platform can be built entirely using the Metadata-driven Data Model. But there are use cases when programmatic logic is needed for things like custom UIs, triggers, and scheduled jobs. The programming languages used to write programmatic logic on the platform are:
Visualforce – Server-side templating language for custom UIs that run inside of your Salesforce system
Apex – Programmable logic for triggers, Visualforce controllers, & scheduled jobs
SOQL – Domain Specific Language (DSL) for database queries
Visualforce uses a JSP-like syntax for creating custom HTML pages that are rendered inside of Salesforce.com and can also be rendered in the Salesforce1 mobile app. Pages in Visualforce use the traditional server-side MVC architecture where the Visualforce page is the View, an Apex class is the controller, and the model is SObjects. Visualforce pages can include any JavaScript and can use JavaScript Remoting and/or RESTful JSON services. Here is a simple Visualforce page:
Apex has a Java-like syntax and runs on Salesforce in a managed, sandboxed, and secure runtime. There is both an Eclipse plugin and a web-based Developer Console for writing Apex. Apex triggers attach to SObject events like update, create, and delete. Batch jobs and scheduled jobs are also written in Apex. Here is a simple Apex trigger:
SOQL queries can be run in the Developer Console and can also be easily embedded in Apex, for instance:
Apex includes a JPA/Hibernate-like database access syntax called DML. This makes it easy to create, update, and delete SObjects in Apex. For example:
Like SObject metadata, all of the programmatic code in Salesforce is versioned, packageable, and testable. Unit testing and code coverage are built into the Apex runtime and 75% code coverage is required in order to deploy code into a production Salesforce system. This code coverage requirement helps maintain stability across major platform upgrades because Salesforce uses customer tests to detect regressions and breakages.
Instead of writing Apex many approval processes and business rules can be created declaratively usingWorkflow. Just like SObject metadata, Workflows can be created with a point-and-click web interface, the Visual Workflow editor. Under the covers all workflows are just metadata which can be versioned and packaged like all of the other platform extensions and customizations.
The Salesforce.com UIs, Salesforce1 Mobile App, Apex runtime and Workflow systems are for back-office, employee-facing interactions. For customer-facing interfaces that interact with data on Salesforce, the Heroku service (part of the Salesforce1 Platform) enables developers to easily create, deploy, and scale custom web apps, mobile apps, and web / REST services. Heroku apps can be written in any language (Java, Ruby, Node.js, etc) and are deployed on a fully managed system that provides the infrastructure developers would normally have to assemble and manage on their own. For instance, services like load balancing, failover, centralized logging, continuous delivery pipelines, and instant scalability are provided out-of-the-box on Heroku.
Integration and ETL
The Salesforce1 Platform provides a variety of ways to integrate with other systems and perform data migrations & synchronization. The major interfaces for these types of data integrations are:
Heroku Connect - A standard, high-performance SQL interface to the data on Salesforce.
SOAP APIs - Schema-rich web services.
REST APIs - Simple JSON web services.
Streaming APIs - Event-driven messaging service.
Data Import & Export - Numerous tools, wizards, and web services provide easy access to import and export Salesforce data.
Email Notifications – Apex and Workflow can be used to send email notifications from Salesforce.
Mobile Notifications - Mobile notifications are built into the Salesforce1 mobile app and custom notifications are also supported.
OAuth 2.0 – The Salesforce web services use OAuth 2.0 to handle authenticating users so that integrated applications can make API requests on their behalf.
SAML - Enterprise Single Sign-On.
Mobile SDKs - Native, Hybrid, and HTML5 SDKs for custom mobile apps.
Integration Platform Vendors – Many integration platform vendors like Informatica, Boomi, Cast Iron, andMuleSoft have out-of-the-box support for integrating with Salesforce.
Massive Ecosystem
There is a massive galaxy of services, apps, frameworks, and libraries around the Salesforce1 Platform. Here are some of those:
AppExchange - Marketplace of third-party apps that run on the Salesforce1 Platform
Data.com - Global Contact Service
Exact Target - Marketing Cloud
Open Source Frameworks, SDKs, Libraries, and Samples - github.com/forcedotcom &github.com/developerforce
The Platform You Can Trust
Because the Salesforce1 Platform is your foundation for business-critical data and apps, the foundation of Salesforce must be Trust. In large enterprise systems there are many aspects to Trust, like transparency of system uptime & responsiveness, multi-tier security, and privacy & certifications.
Get Started
Ready to dive in? The best way to dip your toes in the water and starting building something on the Salesforce1 Platform is by going through the Salesforce Developer Workshop. It won’t cost you anything except time and will help you to understand many of these components by using them. Let me know how it goes!