125857171 Salesforce Certification Prep Notes Docx



To associate a standard controller with a Visualforce page, use the standardController attribute on the tag and assign it the name of any Salesforce object that can be queried using the Force.com API.



Every standard controller includes a getter method that returns the record specified by the id query string parameter in the page URL. This method allows the associated page markup to reference fields on the context record by using {!object} syntax, where object is the lowercase name of the object associated with the controller. For example, a page that uses the Account standard controller can use {!account.name} to return the value of the name field on the account that is currently in context.



You can traverse up to five levels of child-to-parent relationships. For example, if using the Contact standard controller, you can use {!contact.Account.Owner.FirstName} (a three-level child-to-parent relationship) to return the name of the owner of the account record that is associated with the contact.



You can traverse one level of parent-to-child relationships. For example, if using the Account standard controller, you can use {!account.Contacts} to return an array of all contacts associated with the account that is currently in context.



If a user enters data on a Visualforce page that uses a standard controller, and that data causes a validation rule error, the error can be displayed on the Visualforce page. If the validation rule error location is a field associated with an component, the error displays there. If the validation rule error location is set to the top of the page, use the or component within the to display the error.



Any page associated with a standard controller automatically inherits the style that is used for standard Salesforce pages associated with the specified object. That is, the tab for the specified object appears selected, and the associated color of the tab is used to style all page elements.



You can override the styling of a page that uses a standard controller with the tabStyle attribute on the tag. For example, the following page uses the Account standard controller, but renders a page that highlights the Opportunities tab and uses the Opportunity tab's yellow coloring.



If a user has insufficient privileges to view an object, any Visualforce page that uses a controller to render that object will be inaccessible. To avoid this error, you should ensure that your Visualforce components will only render if a user has access to the object associated with the controller.



Using a standard list controller is very similar to using a standard controller. First you set the standardController attribute on the component, then you set the recordSetVar attribute on the same component.



As with queries in the Force.com API, you can use expression language syntax to retrieve data from related records. As with standard controllers, you can traverse up to five levels of child-to-parent relationships and one level of parent-to-child relationships.



When using a standard list controller, the returned records sort on the first column of data, as defined by the current view, even if that column is not rendered. When using an extension or custom list controller, you can control the sort method.



You can add pagination to a page using a list controller by utilizing the next and previous actions. By default, a list controller returns 20 records on the page. To control the number of records displayed on each page, use a controller extension to set the pageSize. When you use pagination, an exception is thrown when there are modified rows in the collection. This includes any new rows added to the collection through an extension action.



Page associated with the standard account controller and the component is populated by {!listviewoptions}, which evaluates to the list views the user can see. When the user chooses a value from the drop-down list, it is bound to the filterId property for the controller. When the filterId is changed, the records available to the page changes, so, when the is updated, that value is used to update the list of records available to the page.



Command buttons and links that are associated with save, quicksave, or edit actions in a list controller are not rendered if the user does not have the appropriate permissions. Likewise if no particular record is associated with a page, command buttons and links associated with the edit actions are not rendered.

 A custom controller is an Apex class that implements all of the logic for a page without leveraging a standard controller. Use custom controllers when you want your Visualforce page to run entirely in system mode, which does not enforce the permissions and fieldlevel security of the current user.  A controller extension is an Apex class that extends the functionality of a standard or custom controller. Use controller extensions when: o

You want to leverage the built-in functionality of a standard controller but override one or more actions, such as edit, view, save, or delete. o You want to add new actions. o You want to build a Visualforce page that respects user permissions. Although a controller extension class executes in system mode, if a controller extension extends a standard controller, the logic from the standard controller does not execute in system mode. Instead, it executes in user mode, in which permissions, field-level security, and sharing rules of the current user apply.  The custom controller is associated with the page because of the controller attribute of the component.  As with standard controllers and controller extensions, custom controller methods can be referenced with {! } notation in the associated page markup. In the example above, the getAccount method is referenced by the tag's value attribute, while the tag references the save method with its action attribute. public class MyController { private final Account account; public MyController() { account = [SELECT Id, Name, Site FROM Account WHERE Id = :ApexPages.currentPage().getParameters().get('id')]; } public Account getAccount() { return account; } public PageReference save() { update account; return null; } }

 A controller extension is any Apex class containing a constructor that takes a single argument of type ApexPages.StandardController or CustomControllerName, where CustomControllerName is the name of a custom controller you want to extend.

public class myControllerExtension {

private final Account acct; // The extension constructor initializes the private member variable acct by using the getRecord method from the standard controller. public myControllerExtension(ApexPages.StandardController stdController) { this.acct = (Account)stdController.getRecord(); } public String getGreeting() { return 'Hello ' + acct.name + ' (' + acct.id + ')'; } }  The extension is associated with the page using the extensions attribute of the component.  As with all controller methods, controller extension methods can be referenced with {! } notation in page markup. In the example above, the {!greeting} expression at the top of the page references the controller extension's getGreeting method.  Because this extension works in conjunction with the Account standard controller, the standard controller methods are also available. For example, the value attribute in the tag retrieves the name of the account using standard controller functionality. Likewise, the tag references the standard account save method with its action attribute.  Multiple controller extensions can be defined for a single page through a comma-separated list. This allows for overrides of methods with the same name. Overrides are defined by whichever methods are defined in the “leftmost” extension, or, the extension that is first in the comma-separated list.  A custom list controller is similar to a standard list controller. Custom list controllers can implement Apex logic that you define to show or act on a set of records.

public class opportunityList2Con { // ApexPages.StandardSetController must be instantiated for standard list controllers public ApexPages.StandardSetController setCon { get { if(setCon == null) { setCon = new ApexPages.StandardSetController(Database.getQueryLocator([SELECT Name, CloseDate FROM Opportunity])); } return setCon; } set;

}

// Initialize setCon and return a list of records

public List getOpportunities() {

return (List) setCon.getRecords(); } }  The list of sObjects returned by getRecords() is immutable. For example, you can’t call clear() on it. You can make changes to the sObjects contained in the list, but you can’t add items to or remove items from the list itself.  It’s a best practice for getter methods to be idempotent, that is, to not have side effects. For example, don’t increment a variable, write a log message, or add a new record to the database. Visualforce doesn’t define the order in which getter methods are called, or how many times they might be called in the course of processing a request. Design your getter methods to produce the same outcome, whether they are called once or multiple times for a single page request

 There is no guaranteed order in which Apex methods and variables are processed by a controller extension or custom controller. Therefore, do not allow controller and extension classes to rely on another method being run, call that method directly. This applies specifically to setting variables and accessing data from the database.  While a getter method is always required to access values from a controller, it’s not always necessary to include a setter method to pass values into a controller. If a Visualforce component is bound to an sObject that is stored in a controller, the sObject's fields are automatically set if changed by the user, as long as the sObject is saved or updated by a corresponding action method.  Setter methods pass user-specified values from page markup to a controller. Any setter methods in a controller are automatically executed before any action methods.  Permission for an Apex class is checked at the top level only. For example, if class A calls class B, and a user profile has access only to class A but not class B, the user can still execute the code in class A. Likewise, if a Visualforce page uses a custom component with an associated controller, security is only checked for the controller associated with the page. The controller associated with the custom component executes regardless of permissions.  Visualforce iteration components, such as and , are limited to a maximum of 1,000 items in the collection they iterate over.



Sometimes your Visualforce pages may need to work with or display larger sets of data, but not need to make modifications to that data; for example, if you are providing custom reporting and analytics. Visualforce offers developers a “read-only mode”, which relaxes the limit on the number of rows which can be queried in one request, and increases the limit on the number of collection items which can be iterated over within the page.



You can specify read-only mode either on individual components or methods, or for an entire page.



Visualforce controller methods with the @ReadOnly annotation automatically take advantage of read-only mode.



You can use multiple @ReadOnly methods in expressions on a given Visualforce page, in a variety of ways, such as: o o

In an component to, for example, display a summary statistic. In an component to load a data set for charting.

o

As the target of a remote JavaScript call.



Enabling read-only mode by using the @ReadOnly annotation must be done on the top level method call. If the top level method call is not a read-only method, the normal restrictions on maximum queried rows are enforced even if secondary methods are read-only.



Enabling read-only mode by using the @ReadOnly annotation allows you to use both read-only method calls and method calls which perform DML operations on a single Visualforce page. However, it doesn't increase the maximum number of items in a collection for iteration components. If you want to iterate over larger collections of results, you need to enable read-only mode for the entire page.



Normally, queries for a single Visualforce page request may not retrieve more than 50,000 rows. In read-only mode, this limit is relaxed to allow querying up to 1 million rows. In addition to querying many more rows, the readOnly attribute also increases the maximum number of items in a collection that can be iterated over using components such as , , and . This limit increased from 1,000 items to 10,000.



To enable read-only mode for an entire page, set the readOnly attribute on the component to true.



To enable read-only mode for an entire page, set the readOnly attribute on the component to true. While Visualforce pages that use read-only mode for the entire page can't use data manipulation language (DML) operations, they can call getter, setter, and action methods which affect form and other user interface elements on the page, make additional read-only queries, and so on.

Best Practices for Controller  Unless a class has a method defined as webService, custom extension and controller classes and methods are generally defined as public. If a class includes a web service method, it must be defined as global.  Use sets, maps, or lists when returning data from the database. This makes your code more efficient because the code makes fewer trips to the database.  The Apex governor limits for Visualforce controller extensions and custom controllers are the same as the limits for anonymous block or WSDL methods.  If you are building a custom controller or controller extension, be careful that you do not inadvertently expose sensitive data that would normally be hidden from users. Consider using the with sharing keywords on class definitions to enforce permissions. Also be careful using Web services, which are secured as top-level entry points by the profile, but execute in the system context once they are initiated.  Apex methods and variables are not instantiated in a guaranteed order.  You can't use data manipulation language (DML) operations in a “getxxx” method in a controller. For example, if your controller had a getName method, you could not use insert or update in the method to create an object.  You can't use data manipulation language (DML) operations in a constructor method in a controller.  You can't use the @future annotation in a “getxxx” or “setxxx” method in a controller, or in the constructor for a controller.  Primitive Apex data types such as String or Integer are passed by value to the component's controller.  Non-primitive Apex data types such as lists and sObjects are passed by reference to component's controller. This means that if component's controller changes the name of an account, the changes are available in page's controller.  Use the transient keyword to declare instance variables that can't be saved, and shouldn't be transmitted as part of the view state for a Visualforce page.

 You can also use the transient keyword in Apex classes that are serializable, namely in controllers, controller extensions, or classes that implement the Batchable or Schedulable interface. In addition, you can use transient in classes that define the types of fields declared in the serializable classes.  Declaring variables as transient reduces view state size. A common use case for the transient keyword is a field on a Visualforce page that is needed only for the duration of a page request, but should not be part of the page's view state and would use too many system resources to be recomputed many times during a request.  Some Apex objects are automatically considered transient, that is, their value does not get saved as part of the page's view state. These objects include the following: o o o o o o

PageReferences XmlStream classes Collections automatically marked as transient only if the type of object that they hold is automatically marked as transient, such as a collection of Savepoints Most of the objects generated by system methods, such as Schema.getGlobalDescribe. JSONParser class instances. Static variables also don't get transmitted through the view state.

 If your org uses person accounts o

When referencing an account record's name field with a custom controller using the component you must specify isPersonAccount in your query.

o

If you create a new account and set name, the record will be a business account. If you create a new account and set lastname, it will be a person account.

o

As a best practice, create a custom name formula field that will render properly for both person accounts and business accounts, then use that field instead of the standard field in your Visualforce pages.

o

If you plan on including your Visualforce page in a Force.com AppExchange package, in your controller or controller extension, you cannot explicitly reference fields that exist only in a person account.

 Mass Update - The list controller tracks two sets of records: a primary list containing all the records selected by the filter, and a secondary list containing those records the user selected. The secondary list is usually established on a standard listview page where the user can check boxes to select the records. To retrieve the prototype object in your custom controller, use the StandardSetController's getSelected method.

Order of Execution in a Visualforce Page A.

User initially requests a page, either by entering a URL or clicking a link or button. This initial page request is called the get request.

B.

The constructor methods on the associated custom controller or controller extension classes are called, instantiating the controller objects.

C.

If the page contains any custom components, they are created and the constructor methods on any associated custom controllers or controller extensions are executed. If attributes are set on the custom component using expressions, the expressions are evaluated after the constructors are evaluated.

D.

The page then executes any assignTo attributes on any custom components on the page.

E.

After the assignTo methods are executed, expressions are evaluated, the action attribute on the component is evaluated, and all other method calls, such as getting or setting a property value, are made.

F.

If the page contains an component, all of the information necessary to maintain the state of the database between page requests is saved as an encrypted view state. The view state is updated whenever the page is updated.

G.

The resulting HTML is sent to the browser. If there are any client-side technologies on the page, such as JavaScript, the browser executes them.

H.

As the user interacts with the page, the page contacts the controller objects as required executing action, getter, and setter methods.

I.

Once a new get request is made by the user, the view state and controller objects are deleted.

J.

If the user is redirected to a page that uses the same controller and the same or a proper subset of controller extensions, a postback request is made. When a postback request is made, the view state is maintained.

K.

A postback request is made when user interaction requires a page update, such as when a user clicks on a Save button and triggers a save action.

L.

During a postback request, the view state is decoded and used as the basis for updating the values on the page.

M.

A component with the immediate attribute set to true bypasses this phase of the request. In other words, the action executes, but no validation is performed on the inputs and no data changes on the page. By setting immediate to true, validation rules are skipped and the action associated with the button is executed immediately; thus the name.

N.

After the view state is decoded, expressions are evaluated and set methods on the controller and any controller extensions, including set methods in controllers defined for custom components, are executed.

O.

These method calls do not update the data unless all methods are executed successfully. For example, if one of the methods updates a property and the update is not valid due to validation rules or an incorrect data type, the data is not updated and the page redisplays with the appropriate error messages.

P.

The action that triggered the postback request is executed. If that action completes successfully, the data is updated. If the postback request returns the user to the same page, the view state is updated.

Q.

You can use the setRedirect attribute on a pageReference to control whether a postback or get request is executed. If setRedirect is set to true, a get request is executed. Setting it to false does not ignore the restriction that a postback request will be executed if and only if the target uses the same controller and a proper subset of extensions. If setRedirect is set to false, and the target does not meet those requirements, a get request will be made.

R.

Once the user is redirected to another page, the view state and controller objects are deleted.

Component ∫

Similar to the way you can encapsulate a piece of code in a method and then reuse that method several times in a program, you can encapsulate a common design pattern in a custom component and then reuse that component several times in one or more Visualforce pages. o For example, suppose you want to create a photo album using Visualforce pages. Each photo in the album has its own border color, and a text caption that displays beneath it. Rather than repeating the Visualforce markup required for displaying every photo in the album, you can define a custom component named singlePhoto that has attributes for image, border color, and caption, and then uses those attributes to display the image on the page. o Once defined, every Visualforce page in your organization can leverage the singlePhoto custom component in the same way as a page can leverage standard components such as or .

∫

Unlike page templates, which also enable developers to reuse markup, custom components provide more power and flexibility because:

o

o

∫

Custom components allow developers to define attributes that can be passed in to each component. The value of an attribute can then change the way the markup is displayed on the final page, and the controller-based logic that executes for that instance of the component. This behavior differs from that of templates, which do not have a way of passing information from the page that uses a template to the template's definition itself. Custom component descriptions are displayed in the application's component reference dialog alongside standard component descriptions. Template descriptions, on the other hand, can only be referenced through the Setup area of Salesforce because they are defined as pages.

Apart from standard Visualforce markup, the body of an tag can also specify the attributes that can be passed in to the custom component when it’s used in a Visualforce page. The values of such attributes can then be used directly in the component, or within the component’s controller, if applicable.

Static Resources 

Static resources allow you to upload content that you can reference in a Visualforce page, including archives (such as .zip and .jar files), images, stylesheets, JavaScript, and other files. Using a static resource is preferable to uploading a file to the Documents tab because: o o



You can package a collection of related files into a directory hierarchy and upload that hierarchy as a .zip or .jar archive. You can reference a static resource by name in page markup by using the $Resource global variable instead of hard coding document IDs.

In addition, using static resources to refer to JavaScript or cascading style sheets (CSS) is preferable to including the markup inline. Managing this kind of content using static resources allows you to have a consistent look and feel for all your pages and a shared set of JavaScript functionality.A single static resource can be up to 5 MB in size, and an organization can have up to 250 MB of static resources. o o o o

To reference a stand-alone file, use $Resource. as a merge field, where is the name you specified when you uploaded the resource. To reference a file in an archive, use the URLFOR function. Specify the static resource name that you provided when you uploaded the archive with the first parameter, and the path to the desired file within the archive with the second. You can use relative paths in files in static resource archives to refer to other content within the archive. Through a custom controller, you can dynamically refer to the contents of a static resource using the tag.

Templates  All templates defined using must have one or more child tags. An tag indicates to pages that import the template that a section needs a definition. 

Any Visualforce page that imports a template using must use to specify the content of each section of the template.



Use the tag when you want to duplicate the entire content of another page without making any changes. You can use this technique to reference existing markup that will be used the same way in several locations.



Defining Custom Components -- Similar to the way you can encapsulate a piece of code in a method and then reuse that method several times in a program, you can encapsulate a common design pattern in a custom component and then reuse that component several times in one or more Visualforce pages. Defining custom components is the most flexible templating method because they can contain any valid Visualforce tags and can be imported without restrictions into any Visualforce page. However custom components should not be used to define reusable Visualforce pages. If you want to reuse the content of an entire Visualforce page, choose one of the other two templating methods.



Defining Templates with -- If you want to define a base template that allows portions of the template to change with each implementation, use the component. This templating method is best for situations when you want to maintain an overall structure to a page, but need the content of individual pages to be different, such as a website for news articles

where different articles should appear with the same page layout. Through this technique, you can also define a template from a PageReference returned by a controller. 

Referencing an Existing Page with -- If you want the entire content of a Visualforce page inserted into another page, use the component. This templating method is best for situations when you want to replicate the same content in multiple areas, such as a feedback form that appears on every page of a website.

Dynamic Visualforce Consider using dynamic Visualforce components in the following scenarios: ۞ You can use dynamic Visualforce components inside complex control logic to assemble components in combinations that would be challenging or impossible to create using equivalent standard Visualforce. For example, with standard Visualforce components, you typically control the visibility of components using the rendered attribute with the global IF() formula function. By writing your control logic in Apex, you can choose to display components dynamically with a more natural mechanism. ۞ If you know that you’ll be iterating over objects with certain fields, but not specifically which objects, dynamic Visualforce components can “plug in” the object representation by using a generic sObject reference. ۞ Dynamic references are evaluated at runtime, after the SOQL query is run by the StandardController. If a field is only used via a dynamic reference, it won’t be automatically loaded. When that dynamic reference is later evaluated, it will resolve to data which is missing, the result of which is a SOQL error. You must provide some extra information to the controller, so that it knows what fields and related objects to load. You can add any number of additional fields to a StandardController query, by using the addFields() method on the page controller to pass in the list of additional fields to load. ۞ You can use dynamic bindings to display field sets on your Visualforce pages. A field set is a grouping of fields. For example, you could have a field set that contains fields describing a user's first name, middle name, last name, and business title. If the page is added to a managed package, administrators can add, remove, or reorder fields in a field set to modify the fields presented on the Visualforce page without modifying any code. ۞ Fields in a field set are automatically loaded when your Visualforce page uses a standard controller. When using a custom controller, you need to add the required fields to the SOQL query for the page. Apex provides two Schema objects that allow you to discover field sets and the fields they contain, Schema.FieldSet and Schema.FieldSetMember. ۞ Fields added to a field set can be in one of two categories: If a field is marked as Available for the Field Set, it exists in the field set, but the developer hasn’t presented it on the packaged Visualforce page. Administrators can display the field after the field set is deployed by moving it from the Available column to the In the Field Set column. If a field is marked as In the Field Set, the developer has rendered the field on the packaged Visualforce page by default. Administrators can remove the field from the page after the field set is deployed by removing it from the In the Field Set column. ۞ The order in which a developer lists displayed fields determines their order of appearance on a Visualforce page. ۞ As a package developer, keep the following best practices in mind: Subscribers with installed field sets can add fields that your page didn’t account for. There is no way to conditionally omit some fields from a field set iteration, so make sure that any field rendered through your field set works for all field types. We recommend that you add only non-essential fields to your field set. This ensures that even if a subscriber removes all fields in the field set, Visualforce pages that use that field set still function.

Visual Workflow

Allows administrators to build applications, known as flows, that step users through screens for collecting and updating data. For example, you can use Visual Workflow to script calls for a customer support center or to generate real-time quotes for a sales organization. The standard user interface for running a flow can't be customized. Visualforce is the core technology that gives developers a more powerful way of building applications and customizing the look and feel of applications. Visual Workflow can leverage this technology to customize the user interface when running flows. Restrict which users can run the flow by setting the page security for the Visualforce page that contains it. If the Visualforce page containing the flow is delivered externally to site or portal users, any of those users with access to the Visualforce page can run the embedded flow. If the Visualforce page containing the flow is delivered to users within your organization through a custom Web tab, link, or button, users must have access to the page. They must also have the “Run Flows” permission or have the Force.com Flow User field enabled on their user detail page. You can set the value of variables when starting a flow through the component. You can only set variables at the beginning of an interview. The tags are evaluated only once when the flow is started. You can only set variables that allow input access and get variables that allow output access. For each flow variable, input and output access is controlled by these fields: o o

Input/Output Type variable field in the Cloud Flow Designer isInput and isOutput fields on FlowVariable in the Metadata API

For a variable that doesn’t allow input or output access, attempts to set or get the variable are ignored, and compilation may fail for the Visualforce page, its component, or the Apex class. You can also leverage standard Visualforce controllers to set variables. You can use the getVariableValue method in the Flow.Interview class to enable a Visualforce controller to access the value of a flow variable. The variable may be in the flow embedded in the Visualforce page or in a separate flow that is called by a subflow element. The returned variable value comes from whichever flow the interview is currently running. If the specified variable can’t be found in that flow, the method returns null. By using the reRender attribute, the component re-renders the flow without refreshing the whole page.

What are the Capabilities and Limitations of the Mobile Application? 

Salesforce Mobile is a native client application with an embedded browser that can pass information between the client application and Visualforce pages. The embedded browser communicates with Salesforce using the device's internet connection; the native client application communicates with Salesforce asynchronously through the SOAP API. The embedded browser can execute JavaScript, but the native client application cannot.

The following list outlines the capabilities and limitations of the native client application: 

Available Objects o Administrators can mobilize accounts, assets, contacts, opportunities, leads, tasks, events, price books, products, cases, solutions, and custom objects. Custom links, s-controls, mashups, merge fields, and image fields cannot be mobilized. The following do not execute in the mobile client application but will run server-side after a record is saved and submitted to Salesforce: workflow rules, validation rules, formula fields, and Apex triggers.



Permissions, Record Types, and Page Layouts

o

User permissions, record types, and page layouts are inherited from Salesforce. Administrators can optionally change the properties of a mobilized object by further restricting permissions of mobile users or excluding unnecessary fields from mobile page layouts.



Related Lists o If administrators mobilize a related object—in other words, add a child data set to a parent data set—the object automatically becomes a related list on the mobile device.



Dashboards and Reports o Dashboards are available in the BlackBerry and iPhone client applications. Reports are available in the BlackBerry client application. Reports are sent to the device in Excel format and display in a basic table. The report viewer in the mobile application does not support sorting, summaries, subtotals, or grouping.



Custom List Views o BlackBerry users can create custom views in the mobile client application. BlackBerry and iPhone users can access custom views created by Salesforce administrators in the Mobile Administration Console. In the mobile application, custom views are limited to two columns.



Visualforce Tabs and Web Tabs o iPhone and BlackBerry users can access Visualforce tabs and web tabs in the mobile client application if the tabs have been mobilized by a Salesforce administrator. Although the native client application lets users access data offline, Visualforce tabs and web tabs require a connection to the wireless network because the tabs are launched in an embedded browser.

When Should Visualforce Mobile Be Used? The majority of popular consumer and enterprise mobile applications are client-side applications that require installation and periodically connect to a server to send and receive data. There are two main reasons why mobile client applications are so prevalent over mobile on-demand applications: ∫

Connection

Mobile devices do not maintain a constant network connection. With a client application, users can work offline and still have uninterrupted access to their data. ∫

Speed

Wireless data networks are still very slow. Client applications are highly responsive. 

Visualforce Mobile provides a way to build custom interfaces and business logic for mobile devices, but developers should only turn to Visualforce Mobile when their needs cannot be met using the capabilities of the native client application.

There are situations, however, where the native client application cannot satisfy a customer's requirements. Use Visualforce Mobile to:     

Mobilize a standard Salesforce object that the client application does not support. Integrate with another Web API, such as Google Maps. Reproduce Salesforce functionality that is not available in the client application, such as responding to approval requests or sending emails using an email template. Integrate with a peripheral device, such as Bluetooth or embedded GPS. Override the action of the standard buttons on record detail pages. When possible, write Apex triggers instead of overriding buttons with Visualforce

Follow these general best practices when building Visualforce Mobile pages for iPhone and BlackBerry:



Controllers

Standard controllers let you reproduce the data, styling, and actions of standard object pages. Salesforce Mobile has support for custom objects and many common standard objects, and it's unlikely that you would use a standard controller to replace native functionality in the mobile application with a Visualforce page. Additionally, the layout and styling of a standard object page are usually too complex for the mobile browser. When developing for the mobile application, you may often write custom controllers for your pages. Controllers run server-side, not in the embedded browser. Controllers with highly complex business logic may cause the page to load more slowly. 

Header and Sidebar

Phones have small screens, and there's often not enough space to display the user's row of tabs and the sidebar. Additionally, it would take a long time to load these components over a wireless network. Consider suppressing the header and sidebar in your Visualforce Mobile pages with the following attribute definition: 

PAGE STYLES

The standard Salesforce stylesheets (CSS files) are too massive for the mobile browser. Not only will the Salesforce stylesheets cause the page to load very slowly, but the stylesheets do not display properly in the BlackBerry browser. Suppress the standard stylesheets in your Visualforce Mobile pages with the following attribute definition: The best approach to adding a stylesheet to your page is to include a section just below the component. To reuse styles between pages, create a separate Visualforce page that defines your styles. Then, use the tag to incorporate the styles page. For example, suppose you define a page called myStyles: YOU WOULD INCLUDE THESE STYLES INTO ANOTHER PAGE LIKE THE FOLLOWING:

It is possible to save a mobile-optimized stylesheet as a static resource, and then reference it in your page. However, the stylesheet is paired with the Visualforce markup on the client-side to render the page, so you increase the page load time by adding a stylesheet as a static resource.

To mobilize your Visualforce page, you have to add the Visualforce tab to a mobile configuration. Mobile configurations are sets of parameters that determine the data Salesforce transmits to users' mobile devices, and which users receive that data on their mobile devices. Organizations can create multiple mobile configurations to simultaneously suit the needs of different types of mobile users. For example, one mobile configuration might send leads and opportunities to the sales division, while another mobile configuration sends cases to customer support representatives. The next step in setting up your mobile configuration is determining which objects and records automatically synchronize to the mobile device.

JavaScript Remoting 

You can include JavaScript libraries in your Visualforce pages to take advantage of functionality provided by these libraries. The best way to include JavaScript libraries is by creating a static resource, and then including the library by adding an component to your page.



If you are using a JavaScript library in a Visualforce page, and that library defines $ as a special character, you'll need to modify your JavaScript to override this usage. For example, if you are using jQuery, you can override the definition of $ by using the JQUERY.NOCONFLICT() function.



Use JavaScript remoting in Visualforce to call methods in Apex controllers from JavaScript. Create pages with complex, dynamic behavior that isn’t possible with the standard Visualforce AJAX components.



JavaScript remoting has three parts: ☼ ☼ ☼

The remote method invocation you add to the Visualforce page, written in JavaScript. The remote method definition in your Apex controller class. This method definition is written in Apex, but there are few differences from normal action methods. The response handler callback function you add to or include in your Visualforce page, written in JavaScript.



The remote method call executes synchronously, but it doesn’t wait for the response to return. When the response returns, the callback function handles it asynchronously.



To make it easier to work with namespaces, especially for pages that make remoting calls to methods provided in packages, you can use the $RemoteAction global to automatically resolve the correct namespace, if any, for your remote action.



If $RemoteAction finds matching @RemoteAction methods in multiple namespaces, it returns the first matching method and logs a warning to the JavaScript console. If a matching controller or action is not found, the call silently fails and an error is logged to the JavaScript console.



Methods used for JavaScript remoting must be uniquely identified by name and number of parameters; overloading isn’t possible.



The response of the remote call has a maximum size of 15 MB. The response of the remote call must return within 30 seconds, after which the call will time out.



The component also lets you call controller action methods through JavaScript. Here are some differences between the two: ☼ The tag:

☼

 lets you specify rerender targets  submits the form  does not require you to write any JavaScript JavaScript remoting:  lets you pass parameters  provides a callback  requires you to write some JavaScript

In general, is easier to use and requires less code, while JavaScript remoting offers more flexibility.

BEST PRACTICES  Performance Visualforce was designed to provide developers with the ability to match the functionality, behavior, and performance of standard Salesforce pages. If your users experience delays, unexpected behavior, or other issues specifically around Visualforce, there are several actions you can take to not only improve their experience, but to also make for improved coding. 

Determine whether Visualforce is the problem by ensuring that: The problems aren’t confined to a single user’s computer by testing expected Visualforce functionality on other machines as well as using different browsers. Slow load times aren’t the result of a network issue by checking the load time of other Salesforce pages. If they’re also slow, it could be the result of bandwidth or latency issues to Salesforce. To check on the status of the Salesforce servers, visit trust.salesforce.com. You should also check the status of your network connections and ensure they’re functioning properly. You’re following general Web design best practices, such as the minification of JavaScript and CSS, optimizing images for the Web, and avoiding iframes whenever possible.



Use the Developer Console to step through the request and determine which items in the request used the most system resources. The following is a list of commonly encountered Visualforce performance issues and their possible solutions: View State Size -- The view state size of your Visualforce pages must be under 135KB. By reducing your view state size, your pages can load quicker and stall less often. You can monitor view state performance through the View State tab in the development mode footer and take the following actions:  Use the transient keyword in your Apex controllers for variables that aren’t essential for maintaining state and aren’t necessary during page refreshes.  If you notice that a large percentage of your view state comes from objects used in controllers or controller extensions, consider refining your SOQL calls to return only data that's relevant to the Visualforce page.  If your view state is affected by a large component tree, try reducing the number of components your page depends on. Load Times -- Large page sizes directly affects load times. To improve Visualforce page load times:  Cache any data that is frequently accessed, such as icon graphics  Avoid SOQL queries in your Apex controller getter methods  Reduce the number of records displayed on a page by: ☼ Limiting the data coming back from SOQL calls in your Apex controllers. For example, using AND statements in your WHERE clause, or removing null results ☼ Taking advantage of pagination with a list controller to present fewer records per page ☼ “Lazy load” Apex objects to reduce request times Consider moving any JavaScript outside of the tag and placing it into a tag right before your closing tag. The tag places JavaScript right before the closing element; thus, Visualforce attempts to load the JavaScript before any other content on the page. However, you should only move JavaScript to the bottom of the page if you’re certain it doesn’t have any adverse effects to your page. For example, JavaScript code snippets requiring document.write or event handlers should remain in the element.

In all cases Visualforce pages must be under 15 MB.

Multiple Concurrent Requests -- Concurrent requests are long running tasks that could block other pending tasks. To reduce these delays:  Action methods used by should be lightweight. It’s a best practice to avoid performing DML, external service calls, and other resource-intensive operations in action methods called by an . Carefully consider the effect of your action method being called repeatedly by an at the interval you specify, especially if it’s used on a page that will be widely distributed, or open continuously.  Increase the time interval for calling Apex from your Visualforce page. For example, when using the component, you could adjust the interval attribute to 30 seconds instead of 15.  Move non-essential logic to an asynchronous code block using Ajax. Queries and Security  By using the with sharing keyword when creating your Apex controllers, you have the possibility of improving your SOQL queries by only viewing a data set for a single user. Preventing Field Values from Dropping off the Page  If your page contains many fields, including large text area fields, and has master-detail relationships with other entities, it may not display all data due to limits on the size of data returned to Visualforce pages and batch limits. The page displays this warning: “You requested too many fields to display. Consider removing some to prevent field values from being dropped from the display.” To prevent field values from being dropped from the page, remove some fields to reduce the amount of data returned. Alternatively, you can write your own controller extensions to query child records to be displayed in the related lists. BEST PRACTICES  Iterating with Component IDs ɸ

To refer to a Visualforce component in JavaScript or another Web-enabled language you must specify a value for the id attribute for that component. A DOM id is constructed from a combination of the id attribute of the component, and the id attributes of all components that contain the element. This ensures every element has a unique DOM id.

ɸ

The $Component global variable simplifies references and reduces some of the dependency on the overall page structure. For example, to access a data table with id="tableID" contained in a page block with id="blockID", use the following expression: $Component.blockID.tableID.

ɸ

You don't need to specify an ID for a component you want to access if it is an ancestor or sibling to the $Component variable in the Visualforce component hierarchy. The system dynamically assigns IDs to the outer components and automatically determines the hierarchy for you. For example, suppose you want to access a data table component that is contained in an tag. You only need to specify the ID for the tag. This way, if the page hierarchy ever changes (for example, if an tag is wrapped around the table), you do not have to change your code.

ɸ

Some components, such as tables and lists, support iteration over a collection of records. After you assign an ID for these types of components, the system assigns a unique “compound ID” to each iteration of the component based on the initial ID.

BEST PRACTICES  Static Resource ɸ

You can use the action attribute on a component to redirect from a Visualforce page to a static resource. This functionality allows you to add rich, custom help to your Visualforce pages.

ɸ

For better performance when rendering Visualforce pages as PDFs, reference static image and stylesheet resources through the $Resource global variable.

BEST PRACTICES  Others ɸ

Typically, you want a controller or controller extension to respect a user's organization-wide defaults, role hierarchy, and sharing rules. You can do that by using the with sharing keywords in the class definition.

ɸ

If a controller extension extends a standard controller, the logic from the standard controller does not execute in system mode. Instead, it executes in user mode, in which the permissions, field-level security, and sharing rules of the current user apply.

ɸ

Do not depend on a setter method being evaluated before a constructor.

ɸ

A facet consists of content in an area of a Visualforce component that provides contextual information about the data that is presented in the component. For example, supports facets for the header, footer, and caption of a table, while only supports facets for the header and footer of the column.

Charting ɸ

Visualforce charting gives you an easy way to create customized business charts, based on data sets you create directly from SOQL queries, or by building the data set in your own Apex code. By combining and configuring individual data series, you can compose charts that display your data in ways meaningful to your organization.

ɸ

Visualforce charts are rendered client-side using JavaScript. This allows charts to be animated and visually exciting, and chart data can load and reload asynchronously, which can make the page feel more responsive.

ɸ

Limitations o o o o o

Visualforce charts only render in browsers which support scalable vector graphics (SVG). Visualforce charting uses JavaScript to draw the charts. Visualforce charts won’t display in pages rendered as PDFs. Email clients do not usually support JavaScript execution in messages. Don’t use Visualforce charting in email messages or email templates. Visualforce charting sends errors and messages to the JavaScript console. Keep a JavaScript debugging tool, such as Firebug, active during development. Dynamic (Apex-generated) charting components are not supported at this time.

ɸ

Instead of feeding data directly into the chart, you can provide the component with the name of a JavaScript function that provides the data. The actual JavaScript function is defined in or linked from your Visualforce page. This function has the opportunity to manipulate the results before passing it to , or to perform other user interface or page updates.

ɸ

You can use Visualforce charting with non-Salesforce data sources by building a JavaScript array, in your own JavaScript code in your page, and providing the name of that array to .

α

In order to publish your app and manage your app licenses, you'll need an organization designed specifically for that purpose. Have an ISV CRM Edition provisioned. Think of this as your “business org” as it will be used to publish and manage the sales and distribution of your app.

α

Your business organization may go by many names. At times it may be referred to as your AppExchange Publishing Organization (APO), your License Management Organization (LMO), or your CRM ISV Edition. It is all of those things at the same time, so it's easiest to just think of it as your “business org.”

α

The License Management App (LMA) helps you manage the sales, licensing, and support of your app. To install the LMA, you will need to file a case in the Partner Portal. Once your case is resolved, install the LMA into your business organization.

α

ISV Partner Program o The Partner Program gives you access to the Partner Portal, where you can create organizations, log cases, and find general information about the partner program. Partner Developer Edition o Also known as your dev org, this is where you develop your application and eventually package it up for distribution. EE Test Organization o Also know as your test org, this is where you'll install and test your app, just as a customer will. CRM ISV Organization o Also known as your business org, this organization is used for publishing, licensing, and managing your application from a business perspective. To help manage your license, you installed the License Management App (LMA) into your business organization.

α α α

α

An app is a container for tabs that appear next to each other. When you create an app, it's available in the app picker in the upper right hand corner of the screen.

α

A package is a container for things you upload to the AppExchange. Usually a package contains an app your customers can install in their org, but you can also upload packages that extend existing apps.

α

When you create a package, the framework automatically detects dependent components and adds them to the package.

α

Within the underlying code, your namespace is prepended to all components that are packaged from your dev org. This allows your package and its contents to be distinguished from those of other developers, and ensures your exclusive control of all packaged components.

α

For new features you start by modifying your app, package it, upload a beta, test the beta, and then upload a managed-released version.

α

Major releases increment the version to the next whole number, from 1.0 to 2.0, for example, and minor releases to the first dot from 1.0 to 1.1. There are no hard rules for what constitutes a major or minor release. That's up to you.

α

For bug fixes, the process is slightly different. You start by creating a patch org, a special environment which has limited functionality and can only be used to develop a patch for a specific package. After you upload the patch, you have the option of pushing the patch to your customers, so they get your bug fixes the next time they log in.

α

Minor releases increment the version number to the second decimal, from 1.0 to 1.0.1, for example.

α

Major or minor releases must be installed by customers (pulled). However, you can push patch releases directly to customer orgs. This feature is only available to registered ISVforce/OEM partners.

α

Unmanaged packages -- Unmanaged packages are typically used to distribute open-source projects or application templates to provide developers with the basic building blocks for an application. Once the components are installed from an unmanaged package, the

components can be edited in the organization they are installed in. The developer who created and uploaded the unmanaged package has no control over the installed components, and can't change or upgrade them. α

Managed packages -- Managed packages are typically used by salesforce.com partners to distribute and sell applications to customers. These packages must be created from a Developer Edition organization. Using the AppExchange and the License Management Application (LMA), developers can sell and manage user-based licenses to the app. Managed packages are also fully upgradeable. To ensure seamless upgrades, certain destructive changes, like removing objects or fields, can not be performed.

α

Managed packages also offer the following benefits: o Intellectual property protection for Apex o Built-in versioning support for API accessible components o The ability to branch and patch a previous version o The ability to seamlessly push patch updates to subscribers o Unique naming of all components to ensure conflict-free installs

α

Components -- A component is one constituent part of a package. It defines an item, such as a custom object or a custom field. You can combine components in a package to produce powerful features or applications. In an unmanaged package, components are not upgradeable. In a managed package, some components can be upgraded while others can’t.

α

Attributes -- An attribute is a field on a component, such as the name of an email template or the Allow Reports checkbox on a custom object. On a non-upgradeable component in either an unmanaged or managed package, attributes are editable by both the developer (the one who created the package) and the subscriber (the one who installed the package). On an upgradeable component in a managed package, some attributes can be edited by the developer, some can be edited by the subscriber, and some are locked, meaning they can’t be edited by either the developer or subscriber.

α

Unmanaged: The package has not been converted into a managed package or the component has not been added to a managed package. Note that a component that is “Managed - Beta” can become “Unmanaged” if it is removed from a managed package. All packages are unmanaged unless otherwise indicated by one of the managed icons below.

α

Managed – Beta: The package or component was created in the current Salesforce organization and is managed, but it is not released because of one of these reasons: o It has not been uploaded. o It has been uploaded with Managed - Beta option selected. This option prevents it from being published, publicly available on AppExchange. The developer can still edit any component but the installer may not be able to depending on which components were packaged.

α

Managed - Released: The package or component was created in the current Salesforce organization and is managed. It is also uploaded with the Managed - Released option selected, indicating that it can be published on AppExchange and is publicly available. Note that once you have moved a package to this state, some properties of the components are no longer editable for both the developer and installer.

α

Patch: If you need to provide a minor upgrade to a managed package, consider creating a patch instead of a new major release. A patchenables a developer to change the functionality of existing components in a managed package, while ensuring that subscribers experience no visible changes to the package.

α

Managed – Installed: The package or component was installed from another Salesforce organization but is managed.

α

Not all components can be packaged for distribution. If you create an app that uses components that aren't packageable, your subscribers will have to create and configure those components after they install your app. If ease of installation is an important concern for your subscribers, keep the packageable components in mind as you develop.

α

Protectable: Developers can mark certain components as protected. Protected components can’t be linked to or referenced by components created in a subscriber organization. A developer can delete a protected component in a future release without worrying about failing installations. However, once a component is marked as unprotected and is released globally, the developer can’t delete it.

When the subscriber upgrades to a version of the package where the component is deleted, the component is removed from the subscriber's organization. α

IP Protection - Certain components automatically include intellectual property protection, such as obfuscating Apex code. The only exceptions are Apex methods declared as global, meaning that the method signatures can be viewed by the subscriber. The information in the components you package and publish might be visible to users on AppExchange. Use caution when adding your code to a custom s-control, formula, Visualforce page, or any other component that you cannot hide in your app.

α

Analytic Snapshot - Developers of managed packages must consider the implications of introducing analytic snapshots that reference reports released in a previous version of the package. If the subscriber deleted the report or moved the report to a personal folder, the analytic snapshot referencing the report will not be installed. Also, if the subscriber has modified the report, that report might return results impacting the information displayed by the analytic snapshot. As a best practice, release an analytic snapshot and the related reports in the same version.

α

Apex Classes or Triggers - Any Apex that is included as part of a package must have at least 75% cumulative test coverage. Each trigger must also have some test coverage. When you upload your package to AppExchange, all tests are run to ensure that they run without errors. In addition, tests with the@isTest(OnInstall=true) annotation run when the package is installed in the installer's organization. You can specify which tests should run during package install by annotating them with @isTest(OnInstall=true). This subset of tests must pass for the package install to succeed.

α

Keep the following considerations in mind when including Apex in your package: o If you are exposing any methods as Web services, include detailed documentation so that subscribers can write external code that calls your Web service. o If an Apex class references a custom label, and that label has translations, you must explicitly package the desired individual languages in order for those translations to be included in the package. o If you reference a custom object's sharing object (such as MyCustomObject__share) in Apex, this adds a sharing model dependency to your package. You must set the organization-wide sharing default access level for the custom object to Private in order for other organizations to install your package successfully. o The code contained in an Apex class or trigger that is part of a managed package is automatically obfuscated and cannot be viewed in an installing organization. The only exceptions are methods declared as global, meaning that the method signatures can be viewed in an installing organization. o You can use the deprecated annotation in Apex to identify global methods, classes, exceptions, enums, interfaces, and variables that can no longer be referenced in subsequent releases of the managed package in which they reside. This is useful when you are refactoring code in managed packages as the requirements evolve. After you upload another package version as Managed - Released, new subscribers that install the latest package version cannot see the deprecated elements, while the elements continue to function for existing subscribers and API integrations. o Apex code that refers to Data Categories can't be uploaded.

α

Apex Sharing Reasons - Apex sharing reasons can be added directly to a package, but are only available for custom objects.

α

Custom Fields o Picklist field values for custom fields can be added, edited, or deleted by subscribers. A developer should carefully consider this when explicitly referencing a picklist value in code. Picklist values can be added or deleted by the developer. During a package upgrade, no new picklist values are installed into the subscriber’s organization for existing fields. Any picklist values deleted by the developer are still available in the subscriber’s organization. o Developers can add required and universally required custom fields to managed packages as long as they have default values. o Auto-number type fields and required fields cannot be added after the object is uploaded in a managed-released package.

α

Custom Labels - If a label is translated, the language must be explicitly included in the package in order for the translations to be included in the package.

α

Custom Report Types - A developer can edit a custom report type in a managed package after it is released, and add new fields. Subscribers automatically receive these changes when they install a new version of the managed package. However, developers can’t remove objects or fields from the report type once the package is released.

α

Custom Tabs - The Tab Style for a custom tab must be unique within your app. However, it does not need to be unique within the organization where it is installed.

α

Customer Portal and Partner Portal - Packages referring to Customer Portal or partner portal fields are supported. The subscriber installing the package must have the respective portal enabled to install the package.

α

Dashboard Components - Developers of managed packages must consider the implications of introducing dashboard components that reference reports released in a previous version of the package. If the subscriber deleted the report or moved the report to a personal folder, the dashboard component referencing the report is dropped during install. Also, if the subscriber has modified the report, that report may return results impacting what information is displayed by the dashboard component. As a best practice, the developer should release a dashboard and the related reports in the same version.

α

Divisions - • When divisions are enabled on a custom object in a package, the subscribing organization must have the divisions feature enabled to install the package.

α

Folders o

o o

Components that Salesforce stores in folders, such as documents, cannot be added to packages when stored in personal and unfiled folders. Put documents, reports, and other components that Salesforce stores in folders in one of your publicly accessible folders. Components such as documents, email templates, reports, or dashboards are stored in new folders in the installer’s organization using the publisher’s folder names. Give these folders names that indicate they are part of the package. If a new report, dashboard, document, or email template is installed during an upgrade, and the folder containing the component was deleted by the subscriber, the folder is re-created. Any components in the folder that were previously deleted are not restored.

α

Multi Currency o If an object’s currency field in a report is included as a column and the subscriber’s organization is not enabled for multiple currencies, that column is dropped during install. o If a subscriber installs a custom report type that includes an object’s currency field as a column, that column is dropped if the organization is not enabled for multiple currencies.

α

Permission Sets - You can include permission sets as components in a package, with the following permissions and access settings: o Custom object permissions o Custom field permissions o Apex class access o Visualforce page access

α

Person Accounts - Packages referring to fields related to person accounts on the Account object—for example, Is Person Account, First Name, Last Name, or Title—cannot be uploaded.

α

Record Types – o If record types are included in the package, the subscriber’s organization must support record types to install the package. o If an object’s record type field is included as a column in a report, and the subscriber’s organization is not using record types on the object or does not support record types, then the column is dropped during install. o If you install a custom report type that includes an object’s record type field as a column, that column is dropped if the organization does not support record types or the object does not have any record types defined.

α

Reports - If a report includes elements that cannot be packaged, those elements will be dropped or downgraded, or the package upload will fail. For example: o Hierarchy drill-downs are dropped from activity and opportunities reports. o Filters on unpackageable fields are automatically dropped (for example, in filters on standard object record types). o Package upload fails if a report includes filter logic on an unpackageable field (for example, in filters on standard object record types). o Lookup values on the Select Campaign field of standard campaign reports are dropped.

α

o Reports are dropped from packages if they have been moved to a private folder or to the Unfiled Public Reports folder. o When a package is installed into an organization that does not have Chart Analytics 2.0 o Unsupported chart types, such as donut and funnel, are dropped. Translation Workbench o If you have enabled the translation workbench and added a language to your package, any associated translated values are automatically packaged for the appropriate components in your package. Make sure that you have provided translations for all possible components. o An installer of your package can see which languages are supported on the package detail page. The installer does not need to enable anything for the packaged language translations to appear. The only reason installers may want to enable the translation workbench is to change translations for unmanaged components after installation, override custom label translations in a managed package, or to translate into additional languages.

α

Workflow o Salesforce prevents you from uploading workflow alerts that have a public group, partner user, or role recipient. Change the recipient to a user before uploading your app. During installation, Salesforce replaces that user with the user installing the app, and the installer can customize it as necessary. o Salesforce prevents you from uploading workflow field updates that change an Owner field to a queue. Change the updated field value to a user before uploading your app. During installation, Salesforce replaces that user with the user installing the app, and the installer can customize it as necessary. o Salesforce prevents you from uploading workflow rules, field updates, and outbound messages that reference a record type on a standard or managed-installed object. o Salesforce prevents you from uploading workflow tasks that are assigned to a role. Change the Assigned To field to a user before uploading your app. During installation, Salesforce replaces that user with the user installing the app, and the installer can customize it as necessary. o You can package workflow rules and all associated workflow actions, such as alerts and field updates. However, any timebased triggers are not included in the package. Notify your installers to set up any time-based triggers that are essential to your app. o References to a specific user in workflow actions, such as the email recipient of a workflow email alert, are replaced by the user installing the package. Workflow actions referencing roles, public groups, account team, opportunity team, or case team roles may not be uploaded. o References to an organization-wide address, such as the From email address of a workflow email alert, are reset to Current User during installation. o On install, all workflow rules newly created in the installed or upgraded package, have the same activation status as in the uploaded package.

α

Validation Rules - For custom objects that are packaged, any associated validation rules are implicitly packaged as well.

Ҧ

EE/UE have the most robust functionality. ɸ They support Force.com platform licenses in addition to Salesforce CRM licenses. ɸ If your app doesn’t require Salesforce CRM features (such as Leads, Opportunities, Cases, etc.), Force.com platform licenses provide you with the most flexibility in deploying your app to users who might not normally be Salesforce users. Your app is still subject to the edition limits and packaging rules.

Ҧ

GE/PE don't contain all of the functionality that you can build in a Developer Edition (DE). ɸ Force.com platform licenses cannot be provisioned in GE/PE organizations. This means that only existing Salesforce CRM users can use your app. There are some features that aren't available in GE/PE. Feature Sites Permission Sets

Field Level Security Custom Profiles

Group NO NO Permission sets can be installed in GE/PE orgs but not updated. NO NO

Professional NO NO Permission sets can be installed in GE/PE orgs but not updated. NO NO

Developer YES YES

YES YES

Record Types Assets XXXXXXXXXXXXXXXXXXXXXX Sharing Rules Custom Report Types Solution Product Ideas Forecast Contracts Campaigns Workflow | Approvals XXXXXXXXXXXXXXXXXXXXXX Apex Code

API

NO NO XXXXXXXXXXXXXXXXXXXXXX NO NO NO NO NO NO NO NO NO XXXXXXXXXXXXXXXXXXXXXX ALLOWED Apex developed as part of an ISV app and included in a managed package can run in GE/PE, even though those editions do not support Apex by default. ALLOWED

NO ADD COST XXXXXXXXXXXXXXXXXXXXXX YES YES YES YES YES YES YES YES ADD COST XXXXXXXXXXXXXXXXXXXXXX ALLOWED Apex developed as part of an ISV app and included in a managed package can run in GE/PE, even though those editions do not support Apex by default. ALLOWED

YES YES XXXXXXXXXXXXXXXXXXXXXX YES YES YES YES YES YES YES YES XXXXXXXXXXXXXXXXXXXXXX YES

YES

Ҧ

For partners who are enrolled in the ISV Program, any managed package publicly posted on the AppExchange no longer counts against the apps/objects/tabs limits for your Salesforce Edition.

Ҧ

Both GE and PE do not support custom profiles or field level security. As a result, field level security is also handled by the page layout for each object. Therefore, when a customer installs your app they will not be able to define which profiles have access to what and you will need to ensure that your design works for the Standard User Profile.

Ҧ

For partners who are enrolled in the ISV Program, any managed package publicly posted on the AppExchange no longer counts against the apps/objects/tabs limits for your Salesforce Edition. This effectively means that ISV partners no longer have to worry about package installation failures because of apps/objects/tabs limits being exceeded. This feature is automatically enabled after your app passes the security review.

Ҧ

Important considerations for using Apex in GE/PE. ɸ GE/PE customers can’t create or modify Apex in your app; they can only run the existing Apex. ɸ Your Apex code should not depend on features and functionality that exist only in DE, EE, or UE, or your app will fail to install. ɸ Make sure to use REST if you plan to expose an Apex method as a Web service. Apex classes that have been exposed as a SOAP Web service can’t be invoked from an external web app in GE/PE. ɸ Using Apex to make Web service callouts is allowed in GE/PE. For instance, if you’re planning to make a Web service callout to an external Web service, as long as the managed package is authorized, these classes will function in GE/PE.

Ҧ

API access is not normally supported in GE/PE organizations. However, once your app passes the security review, you’re eligible to use some APIs for building composite applications. ɸ REST based Web services can be enabled by Remote Access consumer whitelisting ɸ SOAP based Web services can be enabled using an API token called a Client ID, which needs to be appended to your SOAP headers in integration calls. This special key enables your app to successfully make calls to GE/PE even if the customer does not have API access ɸ Currently, only the standard SOAP and REST APIs are supported for GE and PE apps. You can also request that a Remote Access app be whitelisted to use the REST API in GE or PE organizations. ɸ Other APIs such as the Metadata API, Bulk API, and Apex Methods exposed using the SOAP Web service remain unavailable.

API

ACCESS

WEB SERVICE (SOAP) WEB SERVICE (REST)

YES, WITH CLIENT ID YES, WITH REMOTE WHITELISTING ONLY FOR APP AND NOT FOR FULL EDITION

WEB SERVICE METHOD (SOAP) WEB SERVICE METHOD (REST) METADATA BULK DATA LOADER CHATTER

NO YES, WITH CLIENT ID NO NO NO YES

Ҧ

Supporting Multiple Editions using an Extension Package ɸ This approach uses a base managed package that contains core app functionality. The base package only contains features supported in GE/PE. You then use a second managed package, or extension package, that extends and enhances the base package. The extension package adds additional features supported in EE/UE. For example, you have a warehouse application that tracks inventory and an extension to this app includes workflow (which isn't available in Group). Your Group and Professional Edition customers can install the base warehouse application, while your other customers install the base package and then the extension package with workflow components. ɸ Since your extension package depends on your base package, it’s important to spend time designing your app and the interfaces between the packages. For example, if the extension package needs to call an Apex class in the base package, you must make sure the desired Apex class is made global. ɸ It’s also important to consider the entire application lifecycle. For example, If you want to add new features, they should be included in the appropriate package. Updates to the base package should not break the extension package.

Ҧ

Supporting Multiple Editions using Dynamic Apex ɸ Using dynamic Apex, dynamic SOQL, and dynamic DML, it’s possible to create one managed package for all editions you plan to support without having to use extension packages. Your app behavior can change dynamically based on the features available in your customer's edition. This is useful when designing an app with the intent to support multiple editions. ɸ Make sure that Apex, workflows, etc. in your package do not contain any strongly-typed reference to a feature that isn't supported by GE/PE. This can include adding a custom field on an unsupported standard object, such as Campaigns, or making an Apex reference to features like multi-currency or territory management. When you reference a feature in your package not supported by GE/PE, this package dependency will cause the installation to fail.

Ҧ

Scenario 1: You want to build an app that uses record types and workflow ɸ Since record types and workflow are both features not found in GE or PE, you will need to decide if you want to support GE/PE. Assuming you do, you can build a base managed package that does not include record types and workflow. After uploading this managed package in a released state, you can install it into another DE organization to start building the extension. Your extension can add record types and workflow that will be installed and leveraged by your EE and UE customers.

Ҧ

The objects, field settings, and field settings history of Chatter are packageable. However, an object's field is only tracked if the object itself is tracked.

Ҧ

When developing applications that use Chatter, it's important to be aware that some organizations might not have Chatter enabled. ɸ By default, when you upload Chatter applications, the package is only available to organizations that have Chatter enabled. You can change this behavior and allow organizations to install the package even if they don't have Chatter. ɸ You must use a managed package. Unmanaged packages that include Chatter functionality can only be installed in organizations that have Chatter enabled. ɸ DML operations and SOSL, and SOQL calls will throw a runtime exception if the subscriber organization does not have Chatter enabled. You must catch and handle any Apex exceptions that are thrown as a result of the missing Chatter feature. ɸ When you upload the package, deselect the Chatter required checkbox (this is automatically selected if you have an Apex reference to Chatter). ɸ If the Chatter required checkbox can't be deselected, then some component in the package has a special requirement for Chatter. This can happen, for example, if you package a custom report type that relies on Chatter. If the Chatter-required checkbox can't be disabled, then the package can only be installed in organizations that have Chatter enabled.

 Use permission sets in addition to packaged profiles so your subscribers can easily add new permissions for existing app users. o If users need access to apps, tabs, page layouts, and record types, don't use permission sets as the sole permission-granting model for your app. Assigned apps and tab settings are available in the permission set user interface, but they aren’t included in permission set package components. o Create packaged permission sets that grant access to the custom components in a package, but not standard Salesforce components.



Provisioning External Services - If your app links to an external service, users who install the app must be signed up to use the service. Provide access in one of two ways: o Access by all active users in an organization with no real need to identify an individual o Access on a per user basis where identification of the individual is important



The Salesforce service provides two globally unique IDs to support these options. The user ID identifies an individual and is unique across all organizations. User IDs are never reused. Likewise, the organization ID uniquely identifies the organization.  Avoid using email addresses, company names, and Salesforce usernames when providing access to an external service. Usernames can change over time and email addresses and company names can be duplicated. 



If you are providing access to an external service, we recommend the following:



Use Single Sign-On (SSO) techniques to identify new users when they use your service.



For each point of entry to your app, such as a custom link or web tab, include the user ID in the parameter string. Have your service examine the user ID to verify that the user ID belongs to a known user. Include a session ID in the parameter string so that your service can read back through the Force.com API and validate that this user has an active session and is authenticated.



Offer the external service for any known users. For new users, display an alternative page to collect the required information.



Do not store passwords for individual users. Besides the obvious security risks, many organizations reset passwords on a regular basis, which requires the user to update the password on your system as well. We recommend designing your external service to use the user ID and session ID to authenticate and identify users.

Force.com (native & mash-ups) - Applications where primary data, logic, and user interface is built entirely on the Force.com platform. The application can call out to approved 3rd party web-services, such as Amazon, Google, Facebook, etc.  Usage of high-risk function.  Potential vulnerabilities, such as cross-sites cripting and SOQL injection



Client (on premise) - Applications that run outside the Salesforce environment, typically running on a desktop or mobile device. These applications treat the Force.com platform as a data source, using the development model of whatever tool and platform they are designed for. Classic examples of this kind of app include the iPhone app and Microsoft Outlook connectors.  Application development and architecture  Integration with Salesforce



Composite (hosted) - Applications that run in a third-party hosted environment and integrate with Salesforce, leveraging the Force.com Web-services API. Application data, logic and user interface can be stored outside of Force.com.  Application development and architecture  Integration with Salesforce  Network security  Hands-on Web app assessment

Network Security Guidelines

The following are minimum network security requirements. You may want to consider solutions that go beyond the minimum, and you may be able to find solutions that integrate some of these requirements together. Don’t rule out multifunction devices unless the unit cannot maintain the desired level of performance. 

 





Stateful Packet Inspection Firewall - There are a large number of vendors who can satisfy this requirement. A dedicated firewall is recommended; however, a virtual firewall is acceptable when salesforce.com passwords or other critical data are not stored in your application. Web/Application Servers - Web and application servers should be on a DMZ separated by a second firewall layer (logical or physical) from the database server. Network IDS/IPS - Network IDS/IPS (Intrusion Detection System/Intrusion Protection System) is required if Salesforce login credentials or critical data is being stored in external servers. Many firewall vendors integrate IDS/IPS into their multi-function firewall. Virtual IDS is acceptable. Log Management - Automated log aggregation and alerting for all network devices and systems. Manual review on a weekly basis is acceptable; however, it is not scalable, error prone, and is very time consuming (costly). Database and Application logging should be enabled as well (for forensic purposes); however, salesforce.com does not require automated alerting or manual reviews of those logs. Log retention for at least 6 months to facilitate forensic investigations Wireless Network - Corporate implementations should include modern access control (e.g. WPA2 Enterprise) with strong encryption protocols. Do not implement wireless networks in collocation facilities.

Host and Platform Security Guidelines The guidance for system security should include no significant surprises. Salesforce.com is interested in making sure you are taking appropriate levels of care in securing systems and most will consider this obvious, common sense. System Configuration Standard - As noted below, salesforce.com expects partners to have a system configuration standard. This standard should include appropriate host hardening. Operating system manufacturers usually provide guidance around host hardening (such as the Windows Server 2003 Security Guide). Disable unnecessary services Remove/rename default accounts and change default passwords Encrypt all passwords Implement a robust organizational password policy:

Remote Access - Remote access of systems in both remote and corporate environments must be secure. VPN tunnels or dedicated links should be used to remotely access any supported environment. SSHv2, IPSEC VPN, and SSL VPN are examples of mechanisms that would be appropriate. Persistent tunnels or dedicated links should have ACLs implemented to help ensure that only authorized users have access to secure remote computing infrastructure. Patch Management Process - A documented and well followed patch management process is essential. Administrators should subscribe to one or more vulnerability email lists and review recommendations at least weekly. Administrators also will review security recommendations from OS

vendors and rollout recommended and critical patches after appropriate levels of testing and evaluation. For smaller implementations, a manual process for patch management is reasonable. As the size of the implementation grows, an automated solution could become important. Anti-Virus - All Windows servers will have an anti-virus solution implemented with automated updates of virus definitions. This should be a centrally administered solution, especially in larger implementations. Antivirus should also be considered for non-Windows platforms, especially if files will be exchanged with Windows systems. Optional - Consideration should be given to going beyond just the minimums noted above. A Host IDS solution could provide additional coverage and potentially compensate for other control weaknesses in your environment. Tools that lock configurations and/or alert on configuration changes could be useful for ensuring adherence to your Change Control policy. Encrypted file systems or databases could improve confidentiality. And an enterprise password vault could mitigate the risk of using shared passwords (especially shared passwords for privileged users).

Application Development Security Guidelines Developing a secure application is critical for services connected to salesforce.com. To do this, there are a number of important items your organization should consider. Software Development Lifecycle Management -- Adherence to relevant policies is critical. Comply with your software development and change control policies. Also, ensure that your policies include appropriate code reviews, testing, and a strict methodology for rolling code to production, including appropriate segregation of duties that ensures that application development personnel do not have privileged access to the production environment. Salesforce.com login Credentials -- As a general rule, do not store login credentials outside of the salesforce.com service. Instead, re-use the session ID in the resulting API calls. In addition, never pass credentials in the URL directly. If the integration requires storage of salesforce.com admin login credentials, typically for performing batch calls and other asynchronous operations, the best practice is to request the customer to create a profile that can only login from the IP address of the server doing the synchronization. You must instruct your customers to provide a distinct API user and assign this user to that profile (additional cost may apply). Password Encryption - Passwords should be encrypted using a modern symmetric encryption algorithm such as AES, 3DES, Blowfish which uses a key strength greater than 128 bits or an asymmetric encryption algorithm such as RSA which uses a key strength of 1024 bits. Use secure locations to store the key such as Java Keystore, which requires a password supplied by a user to be opened. Other suitable locations include Windows registry as long as there are ACLs (Access Control Lists) in place on the relevant registry key. Encryption keys should be changed on a periodic basis and should not be reused across different environments such as testing, QA and production. The keys should be known or accessible by a restricted number of people and the keys should be stored in such a way as to prevent unauthorized access to the key material. If the keys are backed up, then all backup media should be stored in secure location. If you persist customer data outside of the salesforce.com service (either through synchronization or by storing the user’s password), disclose this information to the customer and state this clearly in the terms of use and privacy policy for your application. Since passwords can be set to expire at variable intervals, you must handle invalid password exceptions in a manner that does not interfere with the standard use of salesforce.com. Obfuscate the password and do not store it outside of salesforce.com. Draw the users’ attention to the fact that they should look for the salesforce.com URL and other distinguishing features to avoid getting phished. Note: Salesforce employs a lockout mechanism after a number of failed login attempts, so care should be taken not to retry failed login credentials. Avoid Dynamic SQL - If you choose to use Dynamic SQL anyway, please communicate that to the person performing the security review and be prepared with a detailed rationale for doing so and your methodology for minimizing the risk to customer data. Input Validation - Perform validation on all input fields. Successful attacks on applications frequently are the result of unforeseen input being accepted by the system and then leaving it up to the application or database server to figure out how to deal with it. Perform security by design

and ensure that your application is protected from common application vulnerabilities such as SQL injection, cross-site scripting, buffer overflow etc.

Input Validation - Perform validation on all input fields. Successful attacks on applications frequently are the result of unforeseen input being accepted by the system and then leaving it up to the application or database server to figure out how to deal with it. Perform security by design and ensure that your application is protected from common application vulnerabilities such as SQL injection, cross-site scripting, buffer overflow etc. Logging in via the API - If you use a Custom Link (or S-Control) to invoke an external operation and the external system requires API access to the Salesforce.com platform, ensure that you pass the serverUrl and current session ID as query parameters (implemented as a merge field) to obviate the need for the login call. If you exercise the login() call, be sure to call the single logon server (https://www.salesforce.com) and not any of the service instances directly. There should be only one login per session and salesforce.com will return a session ID to you upon successful login. The session length is based on the organization setting (between 30 minutes and 8 hours). The session expires a set time after it is created and it is not an idle timeout. SSL (HTTPS) - Always use HTTPS (SSL v3 and newer versions) as the transport for communication with the Web service. If the solution renders data in the salesforce.com UI (Custom Link or S-Control), SSL-enable the site using a valid certificate so as to avoid the browser warning of crossing mixed security zones. (Internet circuits, routers, switches, firewalls, load balancers, SSL accelerators, host systems, storage), and/or a disaster recovery plan should be in place. Formula expressions can be function calls or include information about platform objects, a user's environment, system environment, and the request environment. An important feature of these expressions is that data is not escaped during rendering. Since expressions are rendered on the server, it is not possible to escape rendered data on the client using JavaScript or other client-side technology. This can lead to potentially dangerous situations if the formula expression references non-system data (that is potentially hostile or editable data) and the expression itself is not wrapped in a function to escape the output during rendering. The standard mechanism to do server-side escaping is through the use of the SUBSTITUTE() formula tag. Depending on the placement of the tag and usage of the data, both the characters needing escaping, as well as their escaped counterparts, can vary. Cross-Site Request Forgery (CSRF) - Cross-Site Request Forgery (CSRF) flaws are less of a programming mistake as they are a lack of a defense. The easiest way to describe CSRF is to provide a very simple example. An attacker has a Web page at www.attacker.com. This could be any Web page, including one that provides valuable services or information that drives traffic to that site. Somewhere on the attacker's page is an HTML tag that looks like this: In other words, the attacker's page contains a URL that performs an action on your website. If the user is still logged into your Web page when they visit the attacker's Web page, the URL is retrieved and the actions performed. This attack succeeds because the user is still authenticated to your Web page. This is a very simple example and the attacker can get more creative by using scripts to generate the callback request or even use CSRF attacks against your AJAX methods. Within the Force.com platform, salesforce.com has implemented an anti-CSRF token to prevent this attack. Every page includes a random string of characters as a hidden form field. Upon the next page load, the application checks the validity of this string of characters and does not execute the command unless the value matches the expected value. This feature protects you when using all of the standard controllers and methods.

Multi Currency 1.

Once enabled, Multi-Currency can’t be disabled for your organization.

2.

Work with your salesforce.com representative to determine the best time for Multi-Currency enablement. The enablement process temporarily locks your organization, preventing any integration processing and user logins. The lockout duration depends on the data space used by your organization. This table shows the lockout durations and recommended times for enablement.

3.

Upon enablement, all existing records are stamped with a default currency code that you provide in your enablement request. For example, if your organization contains records using USD and EUR, you need to switch them all to the same default currency prior to enablement. Support for this type of conversion is also available as a salesforce.com paid implementation service.

4.

Objects that support multiple currencies include Opportunities, Opportunity Products, Opportunity Product Schedules, Campaign Opportunities, and reports related to these objects and fields. By default, page layouts for these objects have multiple-currency compatible fields, which allow you to specify the currency for the record. Typically, these fields are available only when creating a new record or editing an existing record. The selected currency is used for the primary amount field.

5.

After enablement, the primary currency displays as usual followed by the secondary currency amount in parentheses. The primary currency is typically the default corporate currency, unless it’s overridden at the record level. The secondary currency amount shown in parentheses is always the user’s personal default currency, calculated based on the conversion rate settings defined in your organization.

6.

In reports, the primary currency reflects either the default corporate currency or the currency selected for the record. The secondary currency reflects the personal default currency of the user running the report, or the currency specified in the report criteria.

7.

Dated exchange rates are used for opportunities, opportunity products, opportunity product schedules, campaign opportunity fields, and reports related to these objects and fields. Dated exchange rates are not used in forecasting, currency fields in other objects, or currency fields in other types of reports.

8.

Organizations with advanced currency management support roll-up summary fields between two advanced currency management objects. For example, roll-up summary fields are supported from an opportunity line object to its opportunity object, because both are advanced currency management enabled. However, if you enable advanced currency management, you cannot create roll-up summary fields that calculate currency on the opportunity object rolling up to the account object. All existing currency-related roll-up summary fields on the opportunity object are disabled and their values are no longer calculated. If your organization enables advanced currency management, you should delete any currency roll-up summary fields using opportunities and accounts or opportunities and custom objects.

9.

Campaign opportunity fields use dated exchange rates when calculating the amount in the campaign currency, but are not used when converting those amounts to the user currency.

10. Cross-object formulas always use the static conversion rate for currency conversion. 11. If advanced currency management is enabled, you can't bind Visualforce pages that use or components to currency fields that support advanced currency management. 12. By default, your quota amounts display in your personal currency. You can change the currency of your quota to any of your organization’s active currencies. When you change the currency, the corresponding forecast is also changed to the new currency. 13. When creating list views or custom reports, you can use the list view Search Criteria or filter logic in report builder to limit your data to items with specific currencies or amounts. For example, you may create a list view of all opportunities with amounts over 100,000 U.S. dollars. To do this, you need to follow these rules:

a. b. c.

d.

Prefix currency amounts with a currency code, for example, Annual Revenue greater than USD 50000000. Without the currency code, all amounts are assumed to be in the user's personal currency. For example, Annual Revenue greater than 50000000 means 50 million U.S. dollars, assuming the user's personal currency is U.S. dollars. All amounts are converted to the corporate currency for comparison. For example, Annual Revenue greater than USD 50000000 finds accounts with revenue greater than 50 million U.S. dollars. This would include an account with revenue of 114 million Australian dollars, which is the equivalent of 60 million U.S. dollars, assuming a conversion rate of 1.9. Use the Currency field to find items with a particular currency, for example, Opportunity Currency equal AUD finds opportunities with amounts in Australian dollars.

14. For personal imports, all amounts in new accounts and contacts are imported in your personal currency. When import updates amounts in existing records, the amounts in your file are converted from your personal currency to the currency of the account or contact. For example, your personal currency is U.S. dollars, and your import file has 100 as the annual revenue of an existing account with Account Currency of Finnish marks. The new Annual Revenue value of the account is 600 FIM, assuming a conversion rate of six Finnish marks to one dollar. 15. For accounts and contacts, you can use an active or inactive currency code. You must use an active currency code for leads. 16. The Currency ISO Code column applies to both the account and contact. You cannot specify different currencies for associated contacts and accounts. 17. During import, you cannot update the Currency field for existing accounts and contacts. 18. Creating new accounts, contacts, or leads: a. If you do not use the Currency ISO Code column or fail to map it, any amounts are imported in the corporate currency. For example, if the corporate currency is U.S. dollars, and the value in your file is 100, this is imported as 100 USD. b. If you enter an inactive currency, any amounts are converted to the corporate currency. For example, if your file has 100 AUD, this is imported as 50 USD, assuming the corporate currency is U.S. dollars and Australian dollars is an inactive currency with a conversion rate of 0.5. 19. Updating existing accounts and contacts: a. If the currency code in your import file does not match the existing currency of the record, any amounts will be converted to the currency of the record. For example, if the import file has 100 GBP and the record has a currency of FIM, the amount is imported as 950 FIM, assuming a conversion rate of 9.5. b. If you do not use the Currency ISO Code column or fail to map it, any amounts are interpreted as the corporate currency and then converted to the currency of the record. For example, if your file has 100 for a record that has a currency of FIM, this amount is interpreted as 100 USD and then converted to 650 FIM, assuming the corporate currency is U.S. dollars and Finnish marks has a conversion rate of 6.5. 20. If Advanced Currency Management is enabled, you can use dated exchange rates to map a conversion rate to a specific date range.

Language 1.

Salesforce.com offers three levels of language support: fully supported languages, end user languages, and platform-only languages. All languages are identified by a two-character language code (such as en) or a five-character locale code (such as en_AU).

2.

For end user languages, Salesforce provides translated labels for all standard objects and pages except Administration Setup and Help. End user languages are useful if you have a multilingual organization or partners who speak languages other than your company’s default language.

3.

Platform-only languages are used when you want to localize custom functionality (apps) that you’ve built on the Salesforce platform. When you choose a platform-only language, Salesforce provides translations for all of the custom objects and field labels in the chosen language.

4.

When you specify a platform-only language, labels for standard objects and fields fall back to English except: English (Australia), English (India), English (Malaysia), and English (Philippines) fall back to English (UK); French (Canada) falls back to French; Moldovan falls back to Romanian; and Portuguese (European) falls back to Portuguese (Brazil).

۞ Files – o o o

Upload a file in Chatter and store it there privately until you're ready to share it. Share the file with coworkers and groups to collaborate and get feedback. Attach files to posts in a Chatter feed on the Home tab, Chatter tab, a profile, a record, or a group.

۞ Salesforce CRM Content – o Create, clone, or modify a sales presentation and save it so only you can see it and work on it. o When you're ready, publish it so other users in your company have access to it. Create a content pack and send it to customers. ۞ Salesforce Knowledge – o Write, edit, publish, and archive articles using the Articles Management tab or find and view published articles using the Articles tab. o Customers and partners can access articles if Salesforce Knowledge is enabled in your Customer Portal, partner portal, Service Cloud Portal, or Force.com Sites. o Create a public knowledge base so website visitors can view articles. ۞ Documents – o Store Web resources, such as, logos, DOT files, and other Visualforce materials in folders without attaching them to records. ۞ Attachments – o Add a file to a specific record, like an event, marketing campaign, contact, or case by attaching it on the Attachments related list.

Implementation Tips  



 

  

To ensure quality of service, the total number of content-delivery views allowed within a 24-hour period is limited to 20,000. The amount of bandwidth allocated to content deliveries is limited to 1 GB within a 24-hour period. If a recipient tries to view a delivery when a rate limit has been exceeded, a notification displays that asks the viewer to try again later. Salesforce may be able to increase rate limits on an exception basis. For more information, contact your sales representative. When you create a content delivery, Salesforce copies the original file and creates a new version of that file specifically for online viewing. Note the following information concerning supported file types: ۞ Microsoft® Office 97 through Microsoft Office 2007 Word, Excel, and PowerPoint files are supported for online views. ۞ Adobe® PDF files are supported for online views, but copy-protected PDFs are not. ۞ JPG, BMP, GIF, and PNG are supported for online views. ۞ Any document over 25 MB is not supported for online views. You can create a content delivery with any file type, but if the file type is not supported for online viewing, your recipient can only download the document in its original file format. Always preview your content delivery before sending the URL to recipients. In some cases, formatting in the original file, such as colors and non-standard fonts, may not display properly in the online version. If you are not happy with the quality of the online version, the content delivery wizard gives you the option of making your content available for download in its original file format. Content deliveries require Adobe Flash version 9.0.115. If a recipient does not have Flash installed, a download option displays. Customer Portal and partner portal users cannot create content deliveries. Only the creator of a content delivery can delete the delivery record or edit details such as the expiration date.





Each time a content delivery's URL is clicked, Salesforce records the click as one view and distinguishes between internal and external views. An internal view is a view by a Salesforce user, for example, clicking the delivery URL on the delivery detail page or the View option on the Content Deliveries related list is an internal view. The Content Deliveries related list provides a count of all views for each delivery. Open the delivery details page to see information about a specific view. Note: For password-protected content deliveries, a view is recorded when the recipient clicks on the delivery URL regardless of whether he or she enters the password and views the delivery. To delete a Salesforce CRM Content file that is associated with a content delivery, first delete the content delivery. Salesforce CRM Content users can deliver content from shared libraries or a personal library.

Best Practices 

 

  



After creating a content delivery, always preview it before sending the URL to your recipients to ensure that the formatting in the original file displays properly in the online version. For example, colors and non-standard fonts may not display properly in the preview player. If you are not happy with the quality of the online version, click Previous and choose to make your content available in its original file format or as a PDF file only. Your recipients will be able to download the file, and you can track whether the file was downloaded on the delivery detail page. Animation and timings in PowerPoint files are not supported in the content delivery's online version. Hyperlinks in all file types are also unsupported. See the implementation tips for a complete list of supported file types. If you are a Salesforce CRM Content user and want recipients of your content delivery to always see the latest version of a file rather than the version available on the delivery-creation date, open the delivery detail page and click Edit. Select the Content Delivery Opens Latest Version checkbox. If you select Notify Me of First View or Download, you will receive an email when the content delivery is viewed for the first time. Enabling Salesforce CRM Content in Portals - Salesforce CRM Content is available in the Customer Portal and partner portal. Two levels of access to Salesforce CRM Content can be granted to portal users: Portal users without a Salesforce CRM Content feature license can download, rate, comment on, and subscribe to content if they have the “View Content on Portals” user permission. They cannot view potentially sensitive data such as usernames and download, version, and subscriber history. The content delivery feature is not available to portal users. Portal users with a Salesforce CRM Content feature license can access all Salesforce CRM Content features granted by their library permission(s), including contributing content, moving and sharing content among libraries, and deleting content. They can also view Salesforce CRM Content reports. The content delivery feature is not available to portal users.

License Salesforce

Salesforce Platform

  

Designed for users who require full access to standard CRM and Force.com AppExchange apps. Users with this user license are entitled to access any standard or custom app. Each license provides additional storage for Enterprise and Unlimited Edition users.



Designed for users who need access to custom apps but not to standard CRM functionality. Users with this user license are entitled to use custom apps developed in your organization or installed from Force.com AppExchange. In addition, they are entitled to use core platform functionality such as accounts, contacts, reports, dashboards, documents, and custom tabs. However, these users are not entitled to some user permissions and standard apps, including standard tabs and objects such as forecasts and opportunities. Users with this license can also use Connect Offline. Users with this license can only view dashboards if the running user also has the same license. Users with a Salesforce Platform user license can access all the custom apps in your organization.



 

Force.com - One App

  

Knowledge Only User



Each license provides an additional 1 MB of data storage and 1 MB of file storage, regardless of the Salesforce Edition.

 

Designed for users who only need access to the Salesforce Knowledge app. This license provides access to the following tabs: Articles, Article Management, Chatter, Chatter Files, Home, Profiles, Reports, custom objects, and custom tabs. The Knowledge Only User license includes a Knowledge Only profile that grants access to the Articles tab. To view and use the Article Management tab, a user must have the “Manage Articles” permission.

 Chatter Free

Each license provides additional storage for Enterprise and Unlimited Edition users. Designed for users who need access to one custom app but not to standard CRM functionality. Force.com One App users are entitled to the same rights as Salesforce Platform users, plus they have access to an unlimited number of custom tabs. However, they are limited to the use of one custom app, which is defined as up to 10 custom objects, and they are limited to read-only access to the Accounts and Contacts objects.

 

Designed for Unlimited, Enterprise, and Professional Edition users that don't have Salesforce licenses but need access to Chatter. These users can access standard Chatter people, profiles, groups, and files. They can't access any Salesforce objects or data.

Chatter Only



Guest User



Also known as Chatter Plus. Designed for Unlimited, Enterprise, and Professional Edition users that don’t have Salesforce licenses but need access to some Salesforce objects in addition to Chatter. These users can access standard Chatter people, profiles, groups, and files, plus they can: o View Salesforce accounts and contacts o Use Salesforce CRM Content, Ideas, and Answers o Modify up to ten custom objects Designed for public users who access your Site.com or Force.com sites. Site visitors have access to any information made available in an active public site. For each Guest User license, you can develop one site for your organization. o For Site.com, Developer, Enterprise, and Unlimited Editions each come with unlimited Guest User licenses. o For Force.com sites, Enterprise and Unlimited Editions each come with 25 Guest User licenses. Developer Edition comes with one Guest User license.



You can't purchase additional Guest User licenses for Force.com sites.



The Authenticated Website high-volume portal user license is specifically designed to be used with Force.com sites. Because it's designed for high volumes, it should be a cost-effective option to use with Force.com sites.



You can grant “Read” and “Create” permissions on all standard objects except products, price books, and ideas; and “Read,” “Create,” “Edit,” and “Delete” on all custom objects.



Designed for Unlimited and Enterprise Edition users who need access to Site.com but not to standard CRM functionality. Site.com Only users are entitled to the same rights as Force.com - One App users, plus they have access to the Content app. However, they don't have access to the Accounts and Contacts objects. Users have access to an unlimited number of custom tabs, but are limited to the use of one custom app, which is defined as up to 20 custom objects.



Each Site.com Only user also needs either a Site.com Contributor or Site.com Publisher feature license to access Site.com.



Customer Portal — Enterprise Administration users have the Customer Portal Manager Custom license. This license gives contacts unlimited logins to your Salesforce Customer Portal to manage customer support. You can associate users who have a Customer Portal Manager Custom license with the Customer Portal User profile or a profile cloned and customized from the Customer Portal User profile, which lets them view and edit data they directly own and view, create, and edit cases where they're listed in the Contact Name field. View custom objects and run reports depending on their permissions. Receive the “Portal Super User” and “Delegated Portal User Administrator” permissions. Access Salesforce CRM Content if they have a Salesforce CRM Content feature license or the appropriate permissions.

Site.com Only

Customer Portal — Enterprise Administration User Licenses

   



Overage Customer Portal Manager Custom Authenticated Website license

Service Cloud Portal High Volume Customer Portal

 

Can view and edit data they directly own or data owned by or shared with users below them in the Customer Portal role hierarchy; and they can view and edit cases where they are listed in the Contact Name field. o Can have data shared to them just like other Salesforce users. o Can access custom objects depending on profile settings. o Can access reports depending on profile settings. o Can access Salesforce CRM Content depending on feature license and profile settings. o Can receive the “Portal Super User” and “Delegated Portal User Administrator” permissions. The Overage Customer Portal Manager Custom license is the same as the Customer Portal Manager Custom license, except that users do not have unlimited logins. Authenticated website user is created to address the custom web application uses cases where you need to securely authenticate your website visitors but you don't need CRM functionality. Like e-commerce checkout or recruiting resume submission.



This new license has a new sharing mechanism so it scales up to millions of users. It only provides access to custom objects and read access to documents, and it's cheaper than the customer portal licenses.



It's derived from portal licenses so technically it's a new type of portal license so the same integration you might have done for your sites-portal integration would work for this as well (just use this new license on the portal setup). This license gives contacts unlimited logins to your Service Cloud Portal to access customer support information. Users with this license can access accounts, assets, cases, contacts, documents, ideas, and questions, custom objects depending on their permission settings.

 

  

Can’t share but can transfer records they own. Can’t transfer cases from non-high-volume portal users to them. Can’t include in: o Personal groups or public groups. o Sharing rules. o Account teams, opportunity teams, or case teams. o Salesforce CRM Content libraries.

Overage Authenticated Website Partner Portal User Licenses



Same as the Authenticated Website license, except that users do not have unlimited logins.



Partner Portal users have the Gold Partner user license. They can only access Salesforce using the partner portal.



Force.com Sites You can grant “Read” and “Create” permissions on all standard objects except products, price books, and ideas; and “Read,” “Create,” “Edit,” and “Delete” on all custom objects.



Create a branded, custom Web address, such as http://www.mycompanyideas.com, by registering through a domain name registrar. Create CNAME records to redirect your branded domain and subdomains to your Force.com domain without exposing the force.com name in the URL. It can take up to 48 hours for your Force.com domain to become available on the Internet. Custom Web addresses aren't supported for sandbox or Developer Edition organizations.



With workflow for sites, you can create workflow rules that trigger email alerts when certain site-related criteria are met. For example, create a rule that sends your site administrator an email alert when bandwidth usage reaches 80% of the daily bandwidth limit or when a site's status changes from the active state.



Restrict the IP address ranges from which you can access the site. Force.com sites ignore company-wide IP range restrictions in order to provide public access; however, you can restrict the IP range here. To set restrictions based on IP or login hours, HTTPS is required. You must use the secure URL associated with your Force.com domain to access your site. To enforce HTTPS on all Force.com sites pages and allow all IP addresses to access your site, create the following IP ranges: 0.0.0.0 to 255.255.255.255, :: to ::fffe:ffff:ffff, and ::1:0:0:0 to ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff. However, as this may degrade the performance of your site, don't enforce HTTPS unless it is absolutely required. Changing from HTTP to HTTPS doesn't affect logged in users until the next time they log in.





Force.com sites usage is governed by monthly and daily limits. Understanding these limits is important to the success of your sites. Salesforce.com provides tools to help you reduce bandwidth consumption and monitor site usage so that you can avoid exceeding these limits.



SSL is supported, but if org-wide security settings are enabled, and the site-level override is not enabled, branded domains revert to prefix.secure.force.com on customer login.



Force.com sites enforces two 24-hour rolling limits—bandwidth and service request time—which vary by organization type. Though the limits are high for active production organizations, your site could exceed the limit due to heavy traffic or pages that consume lots of bandwidth or processing time. “Rolling 24-hour period” refers to the 24 hours immediately preceding the current time.



Sites provide caching options that allow you to leverage the resources of our Content Delivery Network (CDN) partner to improve page load times and site performance, as well as help you avoid reaching bandwidth or service request time limits.

 

Sites allows you to set the cache duration for each of your site pages and optimize content delivery to your end users. Control the caching behavior for your site by setting the Boolean cache attribute and integer expires attribute on each Visualforce page. By default, pages that do not have the cache attribute set are cached for ten minutes (600 seconds).



To protect the integrity of sensitive information, SSL sessions and pages requested after authentication are not cached via the CDN. The CDN is only available for active production organizations. It is not available for sandbox or Developer Edition organizations.



The login and registration forms must be secure. Set the forceSSL attribute to true for these forms. However, salesforce.com recommends that you set forceSSL to false for forms accessed by users who have already been authenticated, such as portal users. Since the forceSSL attribute forces a redirect to a secure URL, authenticated users would encounter an error.



Limit Exceeded, Maintenance, Page Not Found, and designated Inactive Home pages aren't counted against page view and bandwidth limits. You can use static resources to brand these pages, but the following limitations apply: o o o o

Static resources must be 50 KB or smaller in size. Static resources must be style sheets (CSS), image files, or JavaScript files. You can't use Apex controllers for these pages. You can't perform SOQL or DML operations from these pages.

Site.com  Site.com is a Web content management system (CMS) that makes it easy to build dynamic, data-driven Web pages quickly, edit content in real time, and manage your websites.  The following examples illustrate a few ways to use Site.com: o Create an event site—Advertise upcoming events, such as grand openings, launches, or sales kick-offs on a public event site. o Promote new products—Launch new products into the market with a promotional website that helps drive sales. o Publish a support FAQ—Provide helpful information on a public website where customers can view solutions to their issues. o Create microsites and landing pages—Create temporary landing pages or targeted microsites for marketing campaigns. o Create a recruiting website—Post job openings to a public site and allow visitors to submit applications and resumes. o Publish a catalog of products—List all of your company's products on a public website, with model numbers and current prices pulled dynamically from your organization. o Post company press releases—Publish your company’s press releases and sort by publication date.  The features available in Site.com Studio vary for publishers, designers, and contributors.

o o o

Publishers have full access to Site.com Studio. Publishers can build and style websites, control the layout and functionality of pages and page elements, and add and edit content. Designers have the same access as publishers except they can’t manage domains or publish a site. Contributors can use Site.com Studio to edit site content only.

ɸ

A solution is a detailed description of a customer issue and the resolution of that issue. Solution managers, administrators, and users with the appropriate permissions can create, review, and categorize solutions. They can also publish solutions to the Self-Service portal and make solutions public.

ɸ

Master Solution - A solution created in any language supported by Salesforce. A master solution can have zero or more translations associated with it; it cannot be linked to another master solution.

ɸ

Translated Solution - A solution translated into another language supported by Salesforce and associated with exactly one master solution. A translated solution cannot have the same language as its master solution or any other translated solutions associated with that master solution. A translated solution cannot have other translated solutions associated with it.

Configuring Your Organization's Sharing Model 

Configure your organization's sharing model so that portal users can only access data associated with their accounts: o Set the organization-wide defaults in your organization's sharing model to Private on accounts, contacts, contracts, assets, and cases. This ensures that Customer Portal users can only view and edit data related to their accounts. o To maintain Public organization-wide default behavior for Salesforce users while ensuring that portal users can only view and edit data related to their accounts, you can create self-referencing sharing rules of “All Internal Users” to “All Internal Users.”



If you’ve set up a Force.com site, you can let users register for or log into your Customer Portal from your site. Force.com Sites enables you to create public websites and applications that are directly integrated with your Salesforce organization— without requiring users to log in with a username and password. You can publicly expose any information stored in your organization through a branded URL of your choice.



High-volume portal users (Service Cloud portal users) are limited-access portal users intended for organizations with many thousands to millions of portal users. Unlike other portal users, high-volume portal users don’t have roles, which eliminate performance issues associated with role hierarchy calculations. High-volume portal users include both the High Volume Customer Portal and Authenticated Website license types.



High-volume portal users: o Are contacts enabled to access a Customer Portal. o Are assigned to the High Volume Customer Portal or Authenticated Website license. o Only share the records they own with Salesforce users in the high-volume portal users sharing group.



High-volume portal users can access records if any of the following conditions are met: o They have “Update” access on the Account that they belong to. o They own the record. o They can access a record’s parent, and the organization-wide sharing setting for that record is Controlled by Parent. o The organization-wide sharing setting for the object is Public Read Only or Public Read/Write. o The record is the account or contact under which they are enabled. o Administrators can create sharing sets to grant high-volume portal users additional access to records.



Limitations o High-volume portal users can’t manually share records they own or have access to. o You can’t transfer cases from non-high-volume portal users to high-volume portal users. o High-volume portal users can’t own accounts. o You can’t add case teams to cases owned by high-volume portal users. o You can’t include high-volume portal users in: o Personal groups or public groups. o Sharing rules. o Account teams, opportunity teams, or case teams. o Salesforce CRM Content libraries.



These limitations also apply to records owned by high-volume portal users. o You can’t assign high-volume portal users to territories. 

Granting High-Volume Portal Users (Service Cloud Portal Users) Access to Records –  Select All records where the high-volume portal user’s account matches to give high-volume portal users access to all records associated with their accounts. For example, choosing this option for cases would give users access to all cases associated with their accounts.





Select Only records where the high-volume portal user’s contact matches to give high-volume portal users access only to the records that are associated with their contacts. For example, choosing this option for cases would give users access only to the cases that they filed, or cases that were filed on their behalf by a support representative.

Sharing Records Owned by High-Volume Portal Users (Service Cloud Portal Users) to Salesforce Users –  Because high-volume portal users are not in the role hierarchy while Salesforce users are, a share group allows you to specify the Salesforce users who can access records owned by high-volume portal users.

‡

When you enable a Customer Portal, the following profiles are automatically created if you purchased user licenses for them:  High Volume Customer Portal  Authenticated Website  Customer Portal User  Customer Portal Manager

‡

Customer Portal Role Hierarchy o When you enable a Customer Portal on an account, the system creates a role hierarchy for the account’s portal users. The portal roles are unique for each account and include the account’s name—or example, “Account A Customer User.” In your organization’s overall role hierarchy, this account-specific hierarchy is directly below the account owner. o The roles in a portal role hierarchy are fixed. You cannot customize them or add new ones. They are:  Executive—for contacts  Manager—for contacts  User—for contacts  Person Account—for person accounts

‡

Person accounts always have the Person Account role. Contacts with the High Volume Customer Portal or Authenticated Website license do not have a role. If access to contacts are set to private, high-volume portal users only have access to their own contact and those they are granted access to.

‡

Role hierarchies ensure that portal users from different accounts never see each other’s data. Even though high-volume portal users aren’t included in role hierarchies, they’re restricted from seeing records that aren’t associated with their account or contact, and they can only see objects to which they’ve been granted access. You can, however, create sharing rules so that users with the Customer Portal Manager license from different accounts can see each other’s data.

‡

Accounts with different portal types—Customer Portal and partner portal—have a separate role hierarchy for each portal. Role names include the portal type with which they are associated. For example, if Account A has both a Customer Portal and a partner portal, then roles for the Customer Portal are named “Account A Customer User” and roles for the partner portal are named “Account A Partner User.”

‡

If your organization uses sharing rules that share to Roles, Internal and Portal Subordinates, then update those sharing rules to share to Roles and Internal Subordinates instead. This is to help ensure that no records owned by a Salesforce user are accidentally shared with a portal user.

‡

The Roles and Internal Subordinates data set category allows you to create sharing rules that include all users in a specified role plus all of the users in roles below that role, excluding any Customer Portal and partner portal roles.

‡

Portal users can only log into Customer Portals assigned to their profile. To assign a profile to a Customer Portal, select the name of a portal from the Customer Portal Setup page, click Edit Profiles in the Assigned Profiles section, and select the Active checkbox next to the profile you want to assign to the portal.

‡

A portal user can access all the Customer Portals assigned to his or her profile with one username and password. You can view the number of active users associated with each profile assigned to a Customer Portal by creating a custom summary report and adding Profile to your report columns.

‡

The login URL of each Customer Portal you create contains a unique identifier, such as portalId=060D00000000Q1F. The unique identifier determines the specific portal a user can access. If a user accesses a login URL that does not contain a unique identifier, they are automatically directed to the login URL of the first Customer Portal you created. Note that portal users can only log into a Customer Portal via the portal's login page and not through the Salesforce login page.

‡

Salesforce CRM Content is available in the Customer Portal. Two levels of access to Salesforce CRM Content can be granted to Customer Portal users: o Portal users without a Salesforce CRM Content feature license can download, rate, comment on, and subscribe to content if they have the “View Content on Portals” user permission. They cannot view potentially sensitive data such as usernames and download, version, and subscriber history. The content delivery feature is not available to portal users. o

‡

Portal users with a Salesforce CRM Content feature license can access all Salesforce CRM Content features granted by their library permission(s), including contributing content, moving and sharing content among libraries, and deleting content. They can also view Salesforce CRM Content reports. The content delivery feature is not available to portal users.

You can use the Customer Portal to provide your customers with access to Salesforce Knowledge articles. Portal users can view and rate articles but cannot create or edit articles.