Platform Cache – Salesforce Winter ’16

This video post provides a technical overview of the Platform Cache feature added in the Winter ’16 release.


Custom Metadata Types – Salesforce Winter ’16

1 Create New Custom Metadata Type

This post provides a high-level overview of the Winter ’16 enhancements to the Custom Metadata Types platform capability.

Custom Metadata Types – The App Configuration Engine for Force.com

There are in my view two distinct ways to consider Custom Metadata Types (CMT); firstly as analogous to Custom Settings and secondly as an architecturally significant paradigm shift in regard to platform extensibility. In the former case CMT can be viewed as a straightforward, almost like-for-like replacement to List Custom Settings – with the added benefit that records can be deployed as metadata. There are of course considerable differences between the two, however conceptually this view is simplistic and approachable. In respect to the latter case, prior to CMT platform extensibility for Force.com could be viewed as a vertical model where new instances of pre-defined metadata types are created to deliver custom interactions. Custom Metadata Types enable a horizontal extensibility model where new type definitions can be introduced and instances created as metadata. The platform is no longer constrained to the pre-defined set of metadata types, developers have freedom to extend the model and deploy both the types and instances freely across environments. This horizontal extensibility model enables a host of new use cases such as bespoke development frameworks that abstract or extend the Force.com platform, an idea variously described as Platform-on-a-Platform or Custom Platform.

Custom Metadata Types were introduced as a beta release in Spring ’15, with the GA release in Summer ’15. The enhancements added to Winter ’16 appear to represent another milestone on the journey toward an increasingly capable platform extensibility model where custom types can be related to standard types, perhaps to override or extend platform behaviour. This is definitely a key area of the Force.com platform to pay attention to over subsequent releases.

Note, the native user interface for Custom Metadata Type administration shown in the following screenshots is a new Winter ’16 feature, previously Metadata API calls were required to define types and manage associated records.

Key Concepts

Metadata Type
As the screenshot below shows, Custom Metadata Types support Custom Fields and Page Layouts, all very consistent with the Custom Object and Custom Setting equivalents (although not layouts in the Custom Setting case). At this point it’s worth considering the fact that all standard metadata types are comprised of a collection of attributes, for example an ApexClass has Name, Body attributes in the same way a CustomField has Name, Label, DisplayType attributes. This is how Force.com platform metadata is structured. The difference between a CMT and a Custom Object or Setting isn’t the definition it’s the type of data stored; with a CMT we’re recording metadata. Taking a somewhat obscure example, we could invent a new proprietary platform language called Opex (;-)), define a CMT called OpexClass with a Body attribute etc., populate it with metadata records that represent a System namespace and ship some actual ApexClass instances to translate and run the Opex code. I’ll concede this isn’t a practical example, however the point I hope should be clear.

2 Custom Metadata Type

The protected component attribute applies to Managed Packages; meaning visibility of the CMT in a Subscriber org.

When defining a new CustomField for a Custom Metadata Type, there are limitations to the field types that can be specified and as-per Custom Settings there are no picklist or relationship fields (as yet anyway).

3 New Field

Field Manageability is a new concept in Winter ’16 to understand, again in relation to Managed Packages. In short this setting provides field-level editability control, selectable values being:

Locked after release : Field value is locked after deployment (includes the developer org).
Subscriber editable : As the name suggests; deployed (developer) updates will not override subscriber field value changes.
Upgradable : Locked in the subscriber org, developer can edit and deploy upgrades.

4 Custom Metadata Type with Fields

Metadata Record
A Metadata Record is really where Custom Metadata Types head off on their own path; a Metadata Record as the name implies represents an instance of the metadata type as a record that can be manipulated by the Metadata API, deployed via Change Set and packaged. The significance of which is obvious but incredibly powerful. It becomes possible, for example, to track Metadata Records using Source Code Control tools and to deploy metadata plus configuration via a single deployment transaction. No more, 2 stage deployments or clumsy post-install data loading.

5 New Metadata Record

As can be seen in the preceding screenshot it is possible to define a Protected Component setting at the Metadata Record level. This enables the type to be public but records to be selectively hidden in the subscriber org – a very flexible capability.

6 Metadata Records

Key Benefits

As mentioned in the introduction the Custom Metadata Type platform feature is still emerging, in my view at least, the most interesting aspects are potentially yet to be revealed, however there are definitely some key benefits to highlight with the Winter ’16 release.

For Enterprise : Manual steps within an otherwise automated Application Lifecycle Management process can cause compliance issues and release management inefficiency. Custom Metadata Types enable application configurations to be deployed as part of a seamless, one-step deployment process thereby removing manual friction. Configuration management tools can also track and version control the application definition and its configuration state.

For Partners : A long time issue for ISVs has been the deployment of application configuration data as part of the managed package installation process. Post install scripts provide one option, but creating data via Apex script doesn’t scale well or deliver the required fine-grained control over subscriber org configurability and upgradeability. Custom Metadata Types address both issues.

The screenshot below shows both a Custom Metadata Type and Metadata Records added to a Managed Package definition.

7 Packageable

Note, the benefits stated above are those practical benefits of the capability in relation to its generic capability, the actual benefit for many developers will be the flex

Implementation Considerations

Audit trail : Changes to both Custom Metadata Types and Metadata Record are visible via the Setup Audit Trail, this is new to the Winter ’16 release.

8 Audit Trail

Metadata Record Access : Metadata Records can be accessed via SOQL query only, there is no direct Apex support. Note the __mdt suffix.

Widget__mdt[] widgets = 
 [select QualifiedApiName, Height__c, Width__c from Widget__mdt];

Metadata Record Modification : Custom Metadata Types do not support DML operations via Apex, the Metadata API must be used. For use cases where configuration data needs to be created via code, CMT may not be an effective approach.

Relationship Fields : At some stage (Spring ’16 perhaps) in the future evolution of Custom Metadata Types I would expect support for relationships to be provided. This I believe is where the feature will really take-off.

Apex Testing : Currently Metadata Records are visible in Apex unit tests (without SeeAllData=true), it’s likely that simulated test data will be supported in a future release to enable testing under different configurations.

Permissions : The permissions model for Custom Metadata Types is limited, the Metadata Records are either visible or not at the org-level. A finer-grained permission model, perhaps just at the record level would be an obvious progression.

References

https://developer.salesforce.com/blogs/engineering/2015/08/custom-metadata-types-winter-16.html

https://help.salesforce.com/HTViewHelpDoc?id=custommetadatatypes_overview.htm

http://releasenotes.docs.salesforce.com/en-us/winter16/release-notes/rn_forcecom_development_custom_metadata.htm

Salesforce Winter ’16 Platform Highlights

With September upon us and Dreamforce 2015 on the near horizon it’s time to dispel thoughts of sunshine and holidays and get focused on the upcoming Winter release. Whilst it’s undoubtedly depressing to be reading the word Winter in early September, there’s plenty in the new release to raise the spirits. It’s also clear that with significant platform changes emerging, i.e. Lighting Experience, this is an important time to be on the front-foot in terms of keeping personal platform expertise up-to-date. For Salesforce professionals or engaged users, the Winter ’16 release presents a great opportunity to reset your knowledge of the platform.

Pre-release sign-up appears to be offline at present, however existing pre-release orgs should be updated and available to explore. A preview set of release notes can be downloaded from here. The rollout window for production instances is between the 25th September and the 17th October, specific instance dates are stated on the trust.salesforce.com site.

winter release

This post briefly outlines selected highlights related to the Force.com platform (in no order of significance).

– features are GA if not indicated otherwise

Lightning Experience
As the marketing literature states; a new, modern, intelligent user experience – or, in other words the new Salesforce.

Lighting Experience Record Detail Page

With Winter ’16 we’re entering a new transitional era for the platform with features migrating from the Salesforce Classic UI (Aloha) across to Salesforce Lightning Experience presumably over the course of a series of releases. This journey starts with a focused Sales Cloud offering. The updated user interface looks like a significant advancement, however many users will need to navigate both interfaces which may degrade the overall user experience. It should be noted that access to the Lighting Experience desktop experience is permission based (profile or permission set) and therefore user access can be selective. The new experience is more than a cosmetic update, a number of object-specific features (e.g. Account Insights, Opportunity Workspace) are introduced that increase the functional richness provided and deliver a more focused view than the generic interaction patterns applied in the Aloha interface.

Lightning Experience – Visualforce Support – Beta
Visualforce support in Salesforce Lighting Experience will be GA in the Spring ’16 release, for Winter ’16 this is desginated a beta status. Support in this context means rendering with the Aloha look and feel, pages will not inherit a Lighting Experience visual style via the container, instead Visualforce pages will need to be redeveloped using Lightning Components and the Lightning Design System to reflect the new visual style. Where investments have been made in Visualforce (ISVs for example) the lack of migration path could represent a significant amount of work. The Lightning Design System (LDS) provides the CSS and design guidelines necessary to develop user interface components that are consistent with the Lightning Experience visual design.

Platform Cache
A new Force.com platform cache has been added that supports both org-level and session-level data caching. The cache can be accessed from Apex via the Cache namespace and provides obvious performance and reliability benefits. A Session cache has been required for Visualforce for some time to help reduce viewstate pressure, the Org cache will remove the need for Custom Setting based solutions for shared/global data. Available cache space can be distributed across partitions to provide control over application-level usage.

Platform Cache Setup Page

Apex Debugger
An extension to the Eclipse based Force.com IDE that provides support for breakpoints. This is a major advancement for Apex development. Step Over, Step Into, Run To… all the usual breakpoint related features are supported. At long last Apex has some degree of basic parity with other languages where this capability is taken for granted. The release notes mention that for some customers the Apex Debugger may incur additional costs, the detail of which is yet to be seen.

Process Builder – Query Bucketing
The Lighting Process Builder is a powerful new platform automation feature – unfortunately to date Processes have not been bulk-safe and have a tendency to throw platform limit exceptions during bulk record operations; typically Soql query limit exceptions. The mitigation for which has been to suppress the batch size to a safe point – a reasonable but not entirely satisfactory resolution. With the Winter ’16 release Soql queries within a transaction are bucketed, meaning combined, to reduce the overall number of queries executed. In principle, this practice enables the limit to be avoided and the transaction to complete. This feels like a temporary resolution to the problem while a more significant re-engineering takes place, I understand that the issues here are not trivial.

Writeable External Objects
An obvious next step for Lighting Connect – the ability to write back to External Objects. Previously External Objects have provided read-only views on the external datasets. The new write support covers OData and custom Apex adapters but not the Salesforce adapter. Record modifications via the UI occur synchronously, while Apex invoked changes are applied via an asynchronous queue.

Extensible Community Templates
Winter ’16 Community Builder templates are now extensible meaning additional Salesforce functionality, content and navigation paths can be configured extending the available features beyond the constraints of the predefined templates. This additional level of configuration takes place directly within the Community Builder, removing the need to use Site.com Studio. Winter ’16 template pages are compatible with Lightning technology meaning Lighting components can be used. This topic is huge but suffice to say the new streamlined development workflow and ability to extend the pre-defined templates to new use cases both represent a significant step forward for Community Templates.

Broadcast Groups – Pilot
Chatter Groups, whether public, private or unlisted can now be configured to allow only the group owner or manager to create posts. Anyone who’s used Chatter groups extensively will recognise the requirement to support one-way, focused communication and to avoid off-topic posts. I can think of a few Salesforce partner community groups that will be implementing this feature asap.

Chatter Questions – Similar Questions and Articles
Chatter Questions now supports the display of Similar Questions and Knowledge Articles inline while typing the question text. An obvious extension, to a highly useful feature, that should reduce the level of duplicate questions and increase the consistency in answers provided, particularly where deflection occurs via knowledge base article.

Restricted Picklists – Pilot
A new “Strictly enforce picklist values” attribute for picklist fields can be used to prevent input of values outside of the defined list via the data APIs. This new feature should be highly beneficial to anyone loading data and avoids the historic silent-error problem where picklist data mismatches go unnoticed.

More Rollup Summary Fields
The new limit is 25 per-object, replacing the old limit of 10. RSF are a great platform feature; incredibly powerful, intuitive for the end-user and quick to implement.