Extending Process Builder and Visualflow

The Process Builder or Visualflow tools allow users to create customized processes and wizard-like user experiences. Both tools offer a large selection of actions they can perform based on criteria defined by the user.

Available actions can be extended by packages installed in the org. This provides another way in which you can expose your functionality for building customized scenarios. This approach does not require the user to write any code.

The following code creates an Invocable Method, which is a global class and a single method with some specific annotations. These annotations are recognized by the tools to present a dynamic configuration UI to allow the user to pass information to and from the method you annotate:

global with sharing class UpdateStandingsAction {
    
   global class UpdateStandingsParameters {
      @InvocableVariable(
         Label='Season Id'
         Description='Season to update the standings for'
         Required=True)
      global Id seasonId;
      @InvocableVariable(
         Label='Issue News Letter'Description='Send the newsletter out to the teams and drivers'
         Required=False)
      global Boolean issueNewsLetter;
        
      private SeasonService.UpdateStandings makeUpdateStandings(){
          SeasonService.UpdateStandings updateStandings = new SeasonService.UpdateStandings();
          updateStandings.seasonId = this.seasonId;
          updateStandings.issueNewsLetter = this.issueNewsLetter;
          return updateStandings;
      }
   }    

   @InvocableMethod(
      Label='Update the leaderboard of the season' 
      Description='Updates the standings and optionally sends the newsletter.')
   global static void updateStandings(List<UpdateStandingsParameters> parameters) {
      // Marshall parameters into service parameters
      List<SeasonService.UpdateStandings> updateStandings = new List<SeasonService.UpdateStandings>();
      for(UpdateStandingsParameters parameter : parameters) {
         updateStandings.add(parameter.makeUpdateStandings());
      }
      // Call the service
      SeasonService.updateStandings(updateStandings);
   }
}

Tip

In order to isolate the parameters of this method from changes to the Service class methods, the UpdateStandings Apex class is used. This also allows the method to evolve in a different direction if needed.

The following shows how the preceding Invocable Method appears in Process Builder:

Extending Process Builder and Visualflow

This method could for example be used as part of the above subscriber defined Process Builder process when a race ends. While you could perform this in Apex Trigger, this might involve some additional conditions unique to the subscriber of your package. Thus this is a good use case for Process Builder and exposing the SeasonService.updateStandings method via an Invocable Method.

Note

Check the Apex Developers guide for more information on Invocable Methods and the preceding attributes. There are various restrictions around the types of parameters that can be passed, such as the parameters must be in list form. This fits well with the bulkfied requirements of the Service layer.

Versioning Invocable Methods

Neither Process Builder or VisualFlow record the package version that was used when an invocable method is referenced. Thus it is not possible to perform behavior versioning, the System.requestVersion returns the currently installed package version. The definition of the Invocable Method is controlled by the constraints relating to use of the global modifier as we have already discussed in this chapter. As a best practice avoid adding new required members (via @InvocableVariable) to your parameter classes.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.22.41.235