Version 9.0 Platform Release Notes

See also: Version 9.0 Doc Notes for documentation changes. All Release Notes ISV Release Notes

For Users

Mobile Access to Reports, Dashboards, and Calendars

Reports--including those that produce charts--can now be displayed in your mobile device, as well as Calendars and Dashboards.

Improved App Center Experience

When you go to the App Center, you now see only those applications you are allowed to launch. And the [Manage] button is no longer present--because modification of application properties is now a design-time activity.

Learn more: App Center

Different Roles in Different Applications

Roles are now application-specific, so you can be a power user in one application, and be a minimal user in another. It's no longer an all-or-nothing choice.

Inline Editing has been Deprecated

Most users won't notice that this functionality has been removed, but some will. The idea was to allow rows in a view to be edited inline. While a great idea, it turned out that significant technical hurdles stood in the way of a consistent implementation. So this functionality has been removed until we can bring it to you in a way that works consistently from release to release.

For Designers

Allow Site Users to Login using Google or Facebook

Adding the appropriate tags to your Site allows users to register and login using their Google or Facebook identity.

Learn more: Site Login and Registration Tags

Compound Print Templates

Using Compound Print Templates, it is now possible to generate a single document that is a combination of multiple templates. Use that feature to print all relevant documents with a single click, or to divide a complex template into multiple pages, to make the parts easier to manage.

Improved Designer Perspective

When you click the Designer tab, you'll find a collection of options that is both simpler and more comprehensive. It's simpler, because options are no longer nested--everything you work with is now one click away. It's more comprehensive, because all of the application properties can be modified, as well as the application components

Learn more: Application Design

Application-specific Objects

When modifying an application, you'll no longer see objects from all other applications running on the platform. Instead, you'll only see the ones you care about--the objects that are part of the current application.

New Resource Sharing Option

To make application objects available to other applications running on the platform, you'll use the new Resource Sharing capability.

Application-specific Roles

New Roles belong solely to the current application, rather than to the tenancy as a whole. (This change applies only to new roles, and new applications. Existing roles have been made part of all installed applications, so that everything continues to work as it did before.)

Changes to Role Definitions

Previously, global permissions, administrative permissions, and individual-object permissions were all specified as part of a Role. Now, global permissions and administrative permissions are specified in an Access Profile.

• For existing applications, Access Profiles have been created that match the permissions previously given to users, and users have been automatically assigned those profiles, so users will see no change.
• New applications have two initial profiles, Regular User and Administrator ::* Existing Access Profiles can be modified, and new ones created.
• Permissions pertaining to individual objects continue to be defined in the Role

Note:

The privileges granted in Access Profiles and Roles are additive. If either the Access Profile or the Role grants permission to perform some operation on an object, then the user has that permission.

Learn more: Roles, Access Profiles

Role-based Forms Assignment

For each object, role-based assignments can now be used to specify which Forms are used for online access and for mobile access.

Learn more: Assign a Form

Note:

With this increased functionality, Custom Assignment Criteria for Forms is deprecated. Applications that use that functionality continue to operate as they did before, but it is no longer possible to assign Forms based on the data in arbitrary fields.

Process Change when Creating an Application

When creating a new application, Application Access needs to specified, to determine who can access the application and what roles they can assume while using it. Administrative privileges are needed for that operation.

And when defining a Form for use in the application, you'll Assign the Form to associate it with one or more Roles.

Learn more: HowTo:Use the Application Wizard to Build a Simple Order Processing System

Owner ID can be Specified when Adding a Record

It is now possible to include the owner_id field in a Form layout, specify a default value, and allow the user to override that value when creating a new record by looking up a different User.

Learn more: Default Value for fields

Owner can be Specified for Records added from Web Forms

When an external Web Form is used to create or update a record, a Data Policy can be used to specify the record owner, using the Change Record Owner action.

Learn more: Add Actions to a Data Policy

A Multi Object Lookup can Target All Objects

Previously, it was necessary to select each object that could be the target of a Lookup. It is now possible to specify "All Objects". With this functionality, if a new object is added later, it automatically becomes eligible as a multi-object Lookup target.

Learn more: Multi Object Lookup

Lookup Fields can Target the Team Object

A Lookup field can now target the Team object, as well as Users, Documents, and custom Objects.

Vertical Tabbed and Accordion Layouts are No Longer Available

Forms that have been configured with these layouts continue to work, but it is no longer possible to choose them when creating a new Form.

For Administrators

Global Resources Options moved to Administration Settings

The global resources that used to be available only in the Designer panel are now available in the Settings panel--so you only have to go one place to do everything you need to do.

Learn more: Global Resources

New Application Access Controls

The new Application Access configuration lets you determine which applications a user (or user group) can run, and which role(s) they can play in that application. So new users no longer have access to all applications, unless permission is granted. (Existing users are initially granted access to all applications, to prevent interruption of expected services. Administrators can modify those permissions as needed.)

Permission-Management Simplified with Access Profiles

Permissions just got easier to manage. There is now a single set of selections to specify global permission to view, create, update, or delete records, and a single click to allow all administrative permissions. (Alternatively, each of the administrative permissions can be selected individually.)

Those permissions are stored in a named Access Profile. You can then reference the Access Profile in a role, so you don't have to keep recreating the same set of permissions for multiple roles, or for multiple users. (To ensure that things work as they did before, the permissions defined for existing users are stored as access profiles, and attached to their roles. Administrators can modify those Access Profiles, as needed.)

Learn more: Access Profiles

Changes to Initial Platform User

Because Access Profiles specify administrative permissions, the initial platform user is assigned the System Administrator access profile. Previously, the initial user was assigned a role with that name. But role-based permissions are now application-specific, while the privileges granted in the Access Profile persist across applications.

Roles are Now Defined by the Application Designer

Now that each application has its own roles, they are defined by the application designer, rather than the administrator. So instead of being accessed in the Settings panel (Settings > Administration), they are listed in the Designer panel (Designer > Roles).

Learn more: Roles

Process Change when Adding a User

In the past, when creating a user you assigned their primary team and chose a role that applied to that user across all applications.

Now, when you create a user you select an Access Profile and assign a primary team. You then go to the Application Access page to specify the applications they can access & roles they can assume in those applications.

Learn more: Add a User

For Developers

User API Changes

In the User object, role_id field has been removed, and the accessProfileId field has been added. In addition, the custom_security_question and security_answer fields are provided.

Learn more: REST user Resource

Role API Changes

Global and administrative permissions are now specified in Access Profiles, rather than in Roles. Inconsequence:

• The REST Role resource no longer contains globally_manage_permission, web_tabs_access_permission, or administrative permissions sections.
• The Role object still contains permissions for self-owned records and team-owned records, but they are no longer wrapped in an individually_manage_permission tag.
• In the Java API, the RoleBean no longer contains an AdministrativePermissionsBean, or a method to access it.

Learn more: REST role Resource, Java [RoleBean]

New Access Profile APIs

The new Access Profile object specifies global and administrative permissions. Using the Java APIs, it is accessed like any other object (objectId = ACCESSPROFILE).

Learn more: REST accessProfile Resource

New Application Access APIs

The Application Access object specifies users who can access an application, and the roles they can assume. Using the Java APIs, it is accessed like any other object (objectId = APPLICATION_ACCESS).

Developers who previously used the REST user_team resource to manage use Roles will now do so using the applicationAccess resource.

Learn more: REST applicationAccess Resource

Field Metadata Changes

For Lookup fields, the REST field Resource contains a new parameter, includeAllObjects. It identifies lookup fields that are allowed to target any object.

Learn more: REST Multi Object Lookup example