Migrating Routers

On This Page

Available in Version 4.9 and up

Kubaru’s Router Migration feature makes it easy to transfer your router configurations from one Salesforce org to another. This is especially useful when you’re configuring Kubaru in a sandbox for testing before deploying to production.

Exporting Routers

Follow these steps to export your routers:

  1. Log into the Salesforce org that has the routers you want to export.
  2. Navigate to the Kubaru Routers tab of the Kubaru Console.
  3. Click on the Router Migration tab.
  4. Under Action select Export.
  5. Select each router you would like to export.
  6. Uncheck the Include Related Object Settings checkbox if you don’t want to include related object settings in the export. This refers to the object settings found in the Settings tab of the console.
  7. Click the Export Routers button. A JSON file will be downloaded to your computer.

Importing Routers

Follow these steps to import the JSON file you exported previously:

  1. Log into the Salesforce org you’d like to import your routers to.
  2. Navigate to the Kubaru Routers tab of the Kubaru Console.
  3. Click into the Router Migration tab.
  4. Leave Action set to Import.
  5. Under Import File, click the Choose File button.
  6. A popup will open where you can select your JSON file.
  7. Choose whether you would like to Allow Partial Success. If checked, routers that have one or more related records that could not be created for any reason will be kept, along with any successful related records. For example, perhaps a member could not be created because the referenced user is not found in the target environment. Such routers will have an import result status of “Partial Success”. If unchecked, such routers will not import and will have a status of “Failed”. Note that even when this setting is checked, if any filters fail on import and are associated with custom filter logic, the router will fail to import.
  8. Click the Import Routers button. A CSV file containing the results of the import will download to your computer. If the import is taking a long time you may receive a message stating that the results will be emailed to you once the process is complete.

The results file will provide an operation, result, and any errors for each router included in the import file.

  • Operation: This simply states whether a router was being updated or created new. This is determined automatically based on whether a router with this name already exists in the target environment, in which case it will show “Update”. Otherwise, it will say “Create”.
  • Result: This will either read as “Success”, “Partial Success”, or “Failed”. Success indicates that the router and all its child records (connected queues, members, filters, and field updates) processed successfully. Partial success indicates that one or more child records failed to import, but the successful items were kept. And Failed indicates that no changes were made to the target environment for that router.
  • Dependency Errors: This will capture any errors based on invalid dependencies from the import file. Examples include but are not limited to router fields that reference an object, field, or user/queue that was not found*, connected queues or members that reference a user or queue that was not found, filters that reference a field that was not found, associated schedules that are not found, etc.
  • DML Errors: Will show any errors encountered while attempting to insert or update the router and/or any related records.

Things to keep in mind

  • Router migration is not supported when using a Firefox browser while in Lightning Experience.
  • Both the source and target Salesforce environments must be on the same version of Kubaru installed before you can migrate router configurations. The version will be displayed in the info banner at the top of the Router Migration subtab of the Kubaru Routers tab in the Kubaru Console.
  • If a router with the same name already exists, the router settings will be updated. However, related records (e.g. connected queues, filters, members, etc.) will not be updated.
  • If a router does not exist, it will be created along with any related records.
  • Imported routers will always be created as Inactive and will need to activated afterward.
  • If a router or its related object settings fail during the import process, the total import result will be “Failed”, and related components cannot attempt to be created. This is true whether using the Partial Success option or not.
  • Some related items are not automatically created by the import process. This includes Distribution SchedulesMember Schedules, and Holiday Schedules. However, the import will attempt to identify and associate such schedules in the target environment based on a name match. So if you first create them manually with the same name as those in the source environment, they will be associated properly by the import.
  • Queues will attempt to be matched first by ID, then by name if an ID match could not be found. Users will first attempt to match by ID, then name, then username, then email.
  • If a field is blank in the exported JSON file, it will not override the value in the destination org. Instead these fields will remain the same as they were before the import.
Was this article helpful?

On This Page