Moover Winter ‘18 Release Highlights

It’s been four months since the last major Moover release, but we think that once you’ve experienced the Winter ‘18 release you’ll agree that it was worth the wait. We’ve made something like 300 improvements, large and small, that impact every aspect of Moover. In this post, we’ll review some of the highlights. You can check out the entire list of features in the Moover Winter ‘18 Release Notes or our Winter ‘18 Release demo video. We will also post detailed Moover Winter ‘18 Release Notes to our Resources page.

Virtual External ID Manager simplifies upserts

External IDs are critical to preventing duplicates when performing repeated data migrations from one org to another. Until this release, Moover offered two basic Salesforce upsert options: formal external IDs or Moover’s Composite External ID feature. With this release, we are taking upsert duplicate prevention to the next level. Like CEID, Virtual External ID Manager allows you to move relational data without the time-consuming process of adding formal external ID fields to every object. VEID is even easier to use than CEID: just turn it on and it creates a virtual external ID for each record by storing the source record ID in a database associated with the Heroku-based Moover Service. Subsequent transfers of the same records will be detected and Moover will perform an update on the destination record, instead of creating a new record. That’s it. No more dupes.

The diagram below shows how VEID Manager controls inserts and updates for three successive deployments by storing the source record ID in a database in the Moover Heroku-based service.

Please note that VEIDs are not appropriate if there is existing “un-registered” data in a destination org. CEID would be a better solution for this scenario.

Updated CPQ templates

Moover’s CPQ data set templates take the work out of configuring Moover data sets for Salesforce CPQ. We now offer templates for Salesforce CPQ’s Winter ‘17, Summer ‘17, and Winter ‘18 release. The templates are available in two versions: with Composite External IDs or or the new Virtual External IDs. You can download them from GitHub or the Prodly Resources page. Enjoy!

Folders

We’ve heard you. If you have many data sets and related connections for different projects, keeping them organized can be kind of complicated. Until now. With Moover’s new Folders feature, you can organize data sets and connections in folders, even nest folders, for structured storage and easy sharing. Ahhh, that’s more like it!

Improved UI/UX

Okay, maybe we’re a bit OCD but we’ve felt the need to clarify the distinction between a data set, a data set’s “elements”, and the Salesforce objects referenced in data set elements. This should help you to visualize your data sets and improve the reporting experience.

We’ve also improved the Deployment Results page experience and added new data set element List and Diagram views to help you visualize the overall structure of your data sets. Let us know if you find this helpful!

Enhanced Record Selectors

Now you can select a specific number of records in your root object using Moover’s new Record Selection Limit field. Located below the SOQL query filter on the data set editor screen, this feature definitely speeds up identifying a small number of records for a deployment.

Relationship Directions

Okay, this is a clever little feature that you’re going to love. Now you can now specify the direction of relationships between parents and children. It may be a bit hard to wrap your head around, but sometimes you don’t want a data set to grab extra child records related to a child object’s parent. With this option, Moover only includes the child’s parent in the data set and not this parent’s other, extraneous children. Got it?

Enhanced Deployment Controls

We’ve added a number of features to give you more control over the deployment of your data sets. When we say Moover is purpose-built for relational data migration, this is what we mean!

• Delay on Insert – Deploys a specified record field with a temporary value, then deploys the actual value. (E.g., Contract records must be in a draft state to copy, so Moover sets the actual state after copying.)
• Deploy Last – Deploys a record without copying a specified field, then deploys the field at the very end. (E.g., CPQ custom conditions need to be deployed last.)
• Rerun – Initiates a second deployment of a deployment batch. Use this feature after you’ve corrected errors encountered during the initial deployment.
• Error Results Only – Saves space by not storing deployment results for the successfully deployed records.

Guard Rails

One of the areas that Moover users have asked us to improve is what we call “guard rails”. These are features that help to avoid failures before they happen. We’ve started to implement guard rails in this release and we plan to focus more effort here in future releases. Here are a few of the guard rails included in this release:

• Improved deployment error messages.
• Identification of partially processed records.
• The Fixed Value option is no longer available for parent fields for external IDs.
• Indicators on results showing what type of upsert or insert.
• Improved result status indicators.
• Restrict most fields on connection records to be read-only.
• Data set name is now a required field.
• No longer able to deploy data sets containing known errors.
• No longer able to move to a child or parent object data set element containing known errors.
• Limited the number of maximum allowable characters for the query filter.
• Handling larger schemas (objects, records, fields, relationships).
• Decreasing deployment execution time (we’ve optimized the
• Moover deployment algorithm and record processing from a batch size perspective).
• Handling larger number of records per object per hour.
• Reducing memory usage (HEAP size) to increase deployment speed.

Performance improvements

We made a number of tweaks that improve Moover’s performance. From now on, you’ll still have time to kick off your deployment and go get a cup of coffee, but not dinner. For instance, we improved:

• Handling larger schemas (objects, records, fields, relationships).
• Decreasing deployment execution time (we’ve optimized the Moover deployment algorithm and record processing from a batch size perspective).
• Handling larger number of records per object per hour.
• Reducing memory usage (HEAP size) to increase deployment speed.