In this chapter, we will explore some key features of the Force.com platform that enables developers to build the application more rapidly, but also provides key features to end users of the application. Using these features in a balanced way is the key to ensuring that you and your users not only get the best out of the platform today, but continue to do so in the future as the platform evolves.
A key requirement for an enterprise application is the ability to customize and extend its functionality, as enterprise customers have varied and complex businesses. You should also keep in mind that, as your ecosystem grows, you should ensure that your partner relationships are empowered by the correct level of integration options and that they need to interface their solutions with yours; the platform also plays a key role here.
As we expand our FormulaForce package, we will explore the following to better understand some of the decision making around platform alignment:
- Packaging and upgradable components
- Custom field features
- Security features
- Platform APIs
- Localization and translation
- Building customizable user interfaces
- E-mail customization with e-mail templates
- Workflow and flow
- Social features and mobile
The time taken to install your application and get it prepared for live usage by your customers is a critical phase in your customer relationship. They are obviously keen to get their hands on your new and improved releases as quickly as possible. Careful planning and awareness of which of the components you are using are packable and upgradeable are important to monitor the effort involved at this stage.
When exploring the various platform features available to you, it is important to check whether the related component type can be packaged or not. For a full list of components that can be packaged, search for the Available Components section in ISVforce Guide, referenced in the previous chapter.
https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/
Tip
If a component type relating to a feature you wish to use cannot be packaged, it does not necessarily mean it is of no use to you or your users, as it may well be something you can promote through your consulting team for your end user admins to take advantage of after installation. Though that keep in mind, how often you recommend this, especially if it starts to become a required post-installation task, will increase the time it takes for your users to go live on your application.
Another aspect to consider is whether the component type is upgradeable, that is, if you define and include one release of your package, then modify it in a subsequent release, it will be updated in the subscriber (customer) organization. The table in the Available Components section in ISVforce Guide will also give you the latest information on this. Some component types that are not upgradeable are as follows:
- Layouts
- E-mail templates
- Reports
- List view
These features are key to your application design and are covered in more detail later in this chapter. It is also important that end users can customize these; hence, Salesforce allows them to be edited. Unfortunately, this means they are not upgradable, that is, in the case of Layouts for example, any new fields you add to your Custom Objects do not appear by default after an upgrade is available for your users. However, new installations of your package will receive the latest versions of these components in your package.
This also applies to some attributes of components that are flagged as upgradeable in the table referenced previously, but have certain attributes that are then not upgradeable. Refer to the Editing Components and Attributes After Installation section in ISVforce Guide for the latest details on this. Some common attributes that are packable but not upgradable, and hence, end user modifiable are as follows:
- Custom field: Picklist values
- Validation Rule: Active
- Custom Object: Action overrides
Tip
The active status of the Validation Rule is quite a surprising one; while the user cannot modify your packaged Validation Rule, they can disable it. For most purposes, this means that this platform feature becomes a post-install optional activity left to the end user where they should wish to implement rules unique to them. For validations you wish to implement in Apex, you can utilize a protected Custom Setting to control activation if desired (such settings are only visible to your support teams via subscriber support).
Probably the most surprising of the non-upgradable attributes of the custom field is the list of picklist values. These are completely modifiable by end users; they can be added, modified, or deleted. This means that you need to be very careful about how you reference these in your Apex code, and consequently, you provide guidelines to your end users about editing and applying changes post upgrade.
Also, remember that the platform treats picklist fields mostly as if they were text fields; as such, you can query and even update a picklist field with any value you like. Also, keep in mind that you can upgrade customer data (if you change or delete a picklist value) through an Apex post-install script.
An alternative to defining picklists at the field level is Global Picklists. Available under the Setup menu, they allow you to define and package picklists independent of fields and thus can be shared across multiple fields.
There are two significant differences to picklists defined this way.
If you require picklists on your fields to be customized or don't have any issues with them being modified, then you can define picklists at the field level. Otherwise Global Picklists are the more natural and safest default to use in cases where your data model requires fields with fixed values, even if there is no reuse between fields. Keep in mind users can still modify the labels of global picklist entries through Salesforce Translation Workbench regardless of the route you choose.
Salesforce as ever is great at providing APIs; the Metadata API is no exception, as it provides a pretty broad coverage of most things that can be done under the Setup menu. This means that it is feasible to consider the development of upgrade tools to assist in upgrading components, such as layouts or picklist values. Such tools will have to handle the logic of merging and confirming the changes with the user of, for example, providing a means to merge new fields into layouts, which the user selects from a UI prompt.
Currently, the Metadata API is not directly accessible from Apex (though I remain hopeful that it will be accessible in the future). However, it can be invoked via an Apex HTTP callout, as it is available as a SOAP API.
The Apex Metadata API library has provided an Apex wrapper at https://github.com/financialforcedev/apex-mdapi to make it easier to use. The following Apex code shows the library being used to programmatically update a layout to add a new custom button. This code can be used as part of a tool you provide with your application or separately by your consultants. For more information, you can refer to the README file in the GitHub repository.
// Read the layout
MetadataService.Layout layout =
(MetadataService.Layout) service.readMetadata(
'Layout', new String'' " 'Test__c-Test Layout' ").getRecords()'0';
// Add a button to the layout
layout.customButtons.add('anewbutton'),
// Update the layout
List<MetadataService.SaveResult> result =
service.updateMetadata( new MetadataService.Metadata'' " layout ");Tip
It is feasible to consider invoking this logic from a package post-install script. However, Salesforce currently requires that you define a remote site in order to authorize the callout, even to their own servers. As the end point differs for this API, based on the subscriber orgs Salesforce instance, it is hard to predefine and thus preinstall this configuration as part of your package. As such, unless you are confident that the remote site has been set up before an upgrade, it might be best to guide the user to a Visualforce page (perhaps through an e-mail from the post-install script), where you can prompt the user.