0

We are developing a managed package and I would like to know how can I load/create large amount of data in customer org after package is successfully installed. I understand there is a Post Install Script that I can use, but I would like to know the best strategy to achieve this. We have approx. 10,000 records that we would like to load/create in the org after installation of the application is successful.

3

There are different strategies that you can leverage and it entirely depends how well the adopted approach fits your need. These are some approaches that we have used before along with the considerations for their usage.

Approach 1 - Using Post Install Scripts

Salesforce provides the InstallHandler interface which can be implemented to execute automation or Apex scripts before the package installation is complete. It can be leveraged by implementing the onInstall() method of the InstallHandler interface.

global class CustomPostInstallClass implements InstallHandler {

    global void onInstall(InstallContext context){

        if(context.previousVersion() == null) {

          //Execute context specific logic when a fresh install
        }
        else{
          if(context.previousVersion().compareTo(new Version(1,0)) == 0) {
            //Execute context specific logic on specific version upgrades 
          }
        }

        if(context.isUpgrade()) {
          //Execute context specific logic if this a Package Upgrade due to a new release version of the Managed Package
        }

        if(context.isPush()) {
          //Execute context specific logic if this a forceed Push to the customer org
        }
    }
}

Usage Considerations

  • Post Install scripts provide installation context variables that help determine and differentiate a fresh installation versus a package upgrade versus adding package version specific branching logic. This is useful in your case since you may only want to load records during a fresh installation and refrain from creating them during an upgrade or when patches are pushed over to client orgs.
  • Since this script executes before the package installation completes, you can check for pre-requisites that your managed package requires for e.g. certain Salesforce features that need to be enabled on the org for the package to work as expected. If those are not met, you have the flexibility to abort the installation process by raising a custom Exception. This avoids installation nightmares and enforces that the setup adheres to the pre-requisite mandates. If you intend to enforce the record creation before the package is used then this is the option for you.
  • A deterrent that the post install approach brings, is the increased installation time while the 10K records are being created. Moreover, you could run into DML Exceptions while loading these records which could abort the installation process and lead to a poor installation experience.

Approach 2 - Using a Product Setup Page

Another approach to reduce installation times and improve the installation experience is introducing a Product Setup Page and the User explicitly initiating the setup through a user interaction. The records to load can be stored as a Json String in a file within the Static Resource of the managed package and can be read when the setup is initiated.

Usage Considerations

  • This approach requires an additional screen to be implemented and business logic to mandate the setup page which means that additional development effort. If you do not mandate this screen to show up first within the product, chances are your user could miss out on record creation leading to installation woes and poor installation experience.
  • Since the InstallContext variables are unavailable the check to determine a fresh install versus a package upgrade versus a package version specific check will need to be done via custom code.
  • Couple of advantages that this approach brings is reduced installation times since the record creation process is decoupled. This also makes the package installation independent of the record load thus reducing installation failure points.
  • In situations where you need to upgrade the records, you could provide your package users with a new Static Resource (provided it is packaged as UnProtected ) giving the package provider an added flexibility and avoiding the overhead of going through a repeated installation effort for the customer.

Approach 3 - Using a Installation Batch or Scheduler

This approach leverages using a Post Install script except that the records to be read from a Json file stored within the package's statis resource and created via a scheduled Batch Apex Job to improve the installation experience.

Based on my experience, I would recommend going for Approach 2 or 1 as explained above.

  • Wendy I am glad I could help! – Jigar Shah Aug 5 '18 at 8:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.