Update: DriveWealth used to offer access to its open, “front office” API’s for free. Since then, they’ve pivoted to a B2B2C model and work only with regulated counterparties. Because of that change code, APIs and links mentioned in this blog do not work anymore. The architectural approach is still valid and can be applied to another API integration.

This is the third and final part of the our blog series where we will cover some of the best practices for writing code that extends Financial Services Cloud and adheres to Salesforce’s security recommendations. We will also review some of the packaging nuances when building on top of Financial Services Cloud.

Before diving in here, you may want a refresher on parts 1 and 2 of this series.

Let’s start with the development best practices.

Writing secure code

While building managed packages it is important to implement secure coding practices to ensure that your package passes the Salesforce security review . Salesforce has published an Enterprise Security API library (ESAPI) to provide a convenient and easy mechanism to inject security best practices into your programmatic constructs . The source code published for the Drivewealth project referenced in the second part of this blog series makes use of this library extensively.

Just to refresh your memory, here is the sequence diagram that explains the high-level flow of the project.

The getDWAccount method of the DriveWealth.cls instantiates a util class and accesses the static methods to check for access control for the respective objects and fields within the object before returning the Account information.

This Util Class returns the SFDCAccessController object from the ESAPI library.

The SFDCAccessController class also includes other methods (e.g. isAuthorizedToView) that enforce CRUD and FLS checks, which you can invoke from your package.

Also note that the queries in the DataQuery class, which consolidates the queries used in the project, uses static text with variable substitution, thereby minimizing vulnerability to a SOQL Injection attack.

This is only a sampling of the secure coding guidelines that Salesforce’s Security Review team will be looking for as they review your application. The coverage of the entire set of guidelines is outside the scope of this article.

Deploying the project using Salesforce DX

You can use Salesforce DX to deploy the sample project in this blog series to a scratch org or any other development org. The project’s Github readme files provides instructions and videos to use SalesforceDX with this project. This includes a one click deployment of the project to any of your Financial Services Cloud developer orgs that you choose.

Packaging and upgrades

Financial Services Cloud is a managed package that is built on top of Sales and Service Cloud. When you are creating your packages you are creating extensions for the Financial Services managed package. The packaging technology for your extensions to Financial Services Cloud follow the same methodology as you would with any of your managed packages.

Of course, there are still some nuances that AppExchange partners need to consider when building extensions of Financial Services Cloud.

  • Financial Services Cloud is not available in prerelease orgs that partners usually use for testing in advance of a Salesforce update. Make sure that you have sandboxes as a part of the release upgrade cycle which will give you access to an environment for regression testing of your app with the new version of Financial Services Cloud.
  • Financial Services Cloud is a managed package and has custom triggers that execute “with sharing”. Be mindful of the impact that your application’s DML might have in transaction contexts. For example, if your package contains code that is expected to execute “without sharing,” the DML in your package could invoke the Financial Services Cloud triggers. These triggers will respect the sharing rules of the running user and might roll back your transaction if the user does not have access to the records.

Person Accounts in Financial Services Cloud

As of Spring ’18, Financial Services Cloud supports Person Accounts. The Financial Services Cloud team encourages all partners and customers to support Person Accounts.

Enabling Person Accounts and referencing the specific fields creates a dependency in your managed package. Make sure that you build your application to work in Financial Services Cloud orgs with and without Person Accounts enabled. Refer to this blog which provides more insight into creating applications that support Person Accounts in Financial Services Cloud.

Financial Services customer trial org

Customers can now get access to a free 30-day preconfigured Financial Services org which comes seeded with sample data. Refer to the Free Trial page for details. Partners can also use the trial Enterprise Edition org. These orgs expire in 30 days

Conclusion

This three-part series provided you an overview of Financial Services Cloud and some insight into the best practices for building secure applications on Financial Services Cloud. Financial Services Cloud is one of the fastest growing products in the Salesforce ecosystem and partners can build new applications or port their horizontal or vertical applications on this industry cloud.

Resources

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS