To associate a standard controller with a Visualforce page, use the standardController attribute on the <apex:page> tag and assign it

the name of any Salesforce object that can be queried using the Force.com API.

<apex:page standardController="MyCustomObject__c">

</apex:page>

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 <apex:inputField> component, the

error displays there. If the validation rule error location is set to the top of the page, use the <apex:pageMessages> or <apex:messages>

component within the <apex:page> 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 <apex:page> 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

<apex:page> 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 <apex:selectlist> 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 <apex:datalist> 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 field-

level 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 <apex:page> 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 <apex:inputField> tag's value attribute,

while the <apex:commandButton> 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 <apex:page> 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 <apex:inputField> tag retrieves the name of the account using standard controller functionality.

Likewise, the <apex:commandButton> 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<Opportunity> getOpportunities() {

return (List<Opportunity>) 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 <apex:pageBlockTable> and <apex:repeat>, 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 In an <apex:outputText> component to, for example, display a summary statistic.

o In an <apex:chart> 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 <apex:dataTable>, <apex:dataList>, and

<apex:repeat>. 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 <apex:page> component to true.

To enable read-only mode for an entire page, set the readOnly attribute on the <apex:page> 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 PageReferences

o XmlStream classes

o 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

o Most of the objects generated by system methods, such as Schema.getGlobalDescribe.

o JSONParser class instances.

o 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 <apex:inputField> 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 <apex:page> component is evaluated,

and all other method calls, such as getting or setting a property value, are made.

F. If the page contains an <apex:form> 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 <apex:dataTable> or <apex:relatedList>.

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

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.

o 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 <apex:component> 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 You can package a collection of related files into a directory hierarchy and upload that hierarchy as a .zip or .jar archive.

o 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 To reference a stand-alone file, use $Resource.<resource_name> as a merge field, where <resource_name> is the name you

specified when you uploaded the resource.

o 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.

o You can use relative paths in files in static resource archives to refer to other content within the archive.

o Through a custom controller, you can dynamically refer to the contents of a static resource using the <apex:variable> tag.

Templates

All templates defined using <apex:composition> must have one or more child <apex:insert> tags. An <apex:insert> tag indicates to pages

that import the template that a section needs a definition.

Any Visualforce page that imports a template using <apex:composition> must use <apex:define> to specify the content of each

<apex:insert> section of the template.

Use the <apex:include> 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 <apex:composition> -- If you want to define a base template that allows portions of the template to change

with each implementation, use the <apex:composition> 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 <apex:include> -- If you want the entire content of a Visualforce page inserted into another page, use

the <apex:include> 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 <apex:param> component. You can only set variables at the

beginning of an interview. The <apex:param> 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 Input/Output Type variable field in the Cloud Flow Designer

o 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 <apex:page> 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 <flow:interview/> component re-renders the flow without refreshing the whole page.

What are the Capabil it ies 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:

<APEX:PAGE SHOWHEADER="FALSE">

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:

<APEX:PAGE STANDARDSTYLESHEETS="FALSE">

The best approach to adding a stylesheet to your page is to include a <style> section just below the <apex:page> component.

<APEX:PAGE STANDARDSTYLESHEETS="FALSE">

<STYLE TYPE="TEXT/CSS">

<!-- THE STYLES --></STYLE>

</APEX:PAGE>

To reuse styles between pages, create a separate Visualforce page that defines your styles. Then, use the <apex:include> tag to incorporate

the styles page. For example, suppose you define a page called myStyles:

<APEX:PAGE>

<STYLE TYPE="TEXT/CSS">

<!-- THE STYLES --></STYLE>

</APEX:PAGE>YOU WOULD INCLUDE THESE STYLES INTO ANOTHER PAGE LIKE THE FOLLOWING:

<APEX:PAGE STANDARDSTYLESHEETS="FALSE"/>

<APEX:INCLUDE PAGENAME="MYSTYLES" />

</APEX:PAGE>

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 <APEX:INCLUDESCRIPT>

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 <apex:actionFunction> component also lets you call controller action methods through JavaScript. Here are some differences

between the two:

☼ The <apex:actionFunction> 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, <apex:actionFunction> 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 <apex:includeScript> tag and placing it into a <script> tag right before your

closing <apex:page> tag. The <apex:includeScript> tag places JavaScript right before the closing <head> 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 <head> 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 <apex:actionPoller> 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 <apex:actionPoller>.

Carefully consider the effect of your action method being called repeatedly by an <apex:actionPoller> 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

<apex:actionPoller> 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 <apex:pageBlock> tag. You only need to specify

the ID for the <apex:dataTable> tag. This way, if the page hierarchy ever changes (for example, if an <apex:detail> 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 <apex:page> 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,<apex:dataTable> supports facets for the header, footer, and caption of a table, while <apex:column>

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 Visualforce charts only render in browsers which support scalable vector graphics (SVG).

o Visualforce charting uses JavaScript to draw the charts. Visualforce charts won’t display in pages rendered as PDFs.

o Email clients do not usually support JavaScript execution in messages. Don’t use Visualforce charting in email messages or

email templates.

o Visualforce charting sends errors and messages to the JavaScript console. Keep a JavaScript debugging tool, such as Firebug,

active during development.

o Dynamic (Apex-generated) charting components are not supported at this time.

ɸ Instead of feeding data directly into the chart, you can provide the <apex:chart> 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 <apex:chart>, 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 <apex:chart>.

α 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 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.

o 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.

o 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 time-

based 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 Group Professional Developer Sites NO NO YES Permission Sets NO

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

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

YES

Field Level Security NO NO YES Custom Profiles NO NO YES

Record Types NO NO YES Assets NO ADD COST YES XXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX Sharing Rules NO YES YES Custom Report Types NO YES YES Solution NO YES YES Product NO YES YES Ideas NO YES YES Forecast NO YES YES Contracts NO YES YES Campaigns NO YES YES Workflow | Approvals NO ADD COST XXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX Apex Code 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 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.

YES

API ALLOWED ALLOWED 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) YES, WITH CLIENT ID WEB SERVICE (REST) YES, WITH REMOTE WHITELISTING

ONLY FOR APP AND NOT FOR FULL EDITION

WEB SERVICE METHOD (SOAP) NO WEB SERVICE METHOD (REST) YES, WITH CLIENT ID METADATA NO BULK NO DATA LOADER NO CHATTER 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 multi-

function 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:

<img src=http://www.yourwebpage.com/yourapplication/createuser?email=attacker@attacker.com&type=admin..... height=1 width=1 />

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 <apex:inputField> or <apex:outputField>

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. Prefix currency amounts with a currency code, for example, Annual Revenue greater than USD 50000000.

b. 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.

c. 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.

d. 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 Upload a file in Chatter and store it there privately until you're ready to share it.

o Share the file with coworkers and groups to collaborate and get feedback.

o 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 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.

Salesforce Platform 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.

Each license provides additional storage for Enterprise and Unlimited Edition users. Force.com - One App 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.

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

Knowledge Only User 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 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 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

Guest User 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.

Site.com Only 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 User Licenses

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.

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.

Overage Customer Portal Manager Custom

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 license 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).

Service Cloud Portal High Volume Customer Portal

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

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

Partner Portal User Licenses 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 Static resources must be 50 KB or smaller in size.

o Static resources must be style sheets (CSS), image files, or JavaScript files.

o You can't use Apex controllers for these pages.

o 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 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.

o Designers have the same access as publishers except they can’t manage domains or publish a site.

o 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.