Are you a Salesforce admin who spends hours moving complex relational data between environments, especially when working with products such as Salesforce CPQ configurations or Field Service records? If so, Prodly is the tool you’ve been waiting for! Say good-bye to hours of manual work using Excel spreadsheets, VLOOKUPs, and DataLoader to move related data records between your Salesforce environments.
AppOps Release by Prodly makes moving data between environments simple, quick, and above all else, accurate. Speaking from experience, Salesforce CPQ admins will know the perils of forgetting to move a Price Condition associated with a Price Rule, as just one example. It will wreak havoc in your Salesforce environment, causing rules to misfire and ultimately delay quotes getting to customers. Not good!
Prodly minimizes the risk of human error and reduces the time your admin has to spend maintaining data configurations, so that they can focus their efforts on other areas that move your Salesforce org forward.
This in-depth review will dive into Prodly’s features, ideal use cases, setup effort, and the potential impact that adding this app to your Salesforce stack could bring.
Features
UI and Navigation
As usual, I started by looking at the Prodly user interface and navigation. Prodly looks and feels like Salesforce Lightning, so there is no new interface to get up to speed with.
AppOps Release has a number of tabs. The most used ones will likely be Connections, Data Sets, Deployment Plans and Deployment Results. I will give you a tour of each.
Connections
The Connections tab is really important. This is where you will manage the connections between your source org (where are you getting Data from) and your target org (where are you sending your data to).
You should always have a Control org which is more than likely your Production environment. You can have multiple “Source” orgs as the “source” org will be selected from your list of connections when you deploy a data set or deployment plan. If you are using Prodly on multiple projects with multiple “source” environments, ensure you decide on a naming convention and utilize the Folders accordingly.
Prodly uses JWT OAuth 2.0 to connect access to your environment and in turn, retrieve data and move data records. These connections are persistent so you don’t need to worry about reestablishing connections after a sandbox refresh.
Having used Prodly extensively myself, my advice would be to keep your connections as clean as possible to avoid any unfortunate accidents, deploying from the wrong source to the wrong destination, or vice versa.
Where does Prodly live?
Prodly can be installed, or ‘live’, in any Salesforce environment, although it is recommended to be installed into a Production environment with development environments linked as Connections, and used to move data between any number of orgs. For Salesforce implementation partners working on multiple projects, this means AppOps Release can connect to many customer environments simply by adding the Connections. You can have “Customer A – Sandbox” connection and “Customer A – Production” connection and the same for “Customer B”.
You can utilize the Folders tab to organize Connections and Deployment Plans for different customers/projects.
Data Sets
Data sets are the lifeblood of Prodly. Without Data Sets, you would not be moving anything, anywhere.
Prodly comes with a number of Data Sets already set up for several common use cases including Salesforce CPQ and Service Cloud sandbox seeding, but you can create Data Sets for any object which exists in your organization.
From within the Data Set Editor, you can view a number of things such as the Element Details, Object Fields, Parent Relationships & Child Relationships, and various settings such as “Create Missing Fields” or “Sync Picklist Values”. I’ll talk about these two settings specifically in more detail later on. You can also select your “Upsert Method” such as “Virtual External ID” as pictured.
Keep in mind though, any edits you make to the pre-configured Data Sets will apply to all users using those Data Sets, so if you do want/need to make changes, my recommendation is to clone the data set and the corresponding deployment plan so as to leave the standard data sets and deployment plans intact.
You can also use the Diagram feature (pictured below) to visualize the relationships objects have to one another.
For example, in the Product Rule Data Set, we see the relationship between the Error Condition, Product Feature, Product Action, Summary Variables & the Configuration Rule record which link the Product Rule back to the Product to which they are related to.
As Summary Variables are a standalone object, neither Parent nor Child to the Product Rule object, being able to visualize the relationship schematics is important when creating Data Sets. You can use the Diagram feature when creating custom data sets to ensure you include the correct parent/child relationships and deploy in the correct order.
When creating custom Data Sets you can also use the “Simulate” functionality to reproduce what would happen if the Data Set is deployed to your target environment. This means you can check the Data Set is complete and will deploy seamlessly as a result.
Deployment Plans
Deployment Plans are a collection of Data Sets that are deployed in the relevant sequence for what is being deployed. You can see below the order in the CPQ deployment plan that comes pre-configured as part of the Prodly managed package.
For example, when deploying CPQ records, you cannot deploy Product Rules before you deploy Price Books and Products (n.b. see image below where Step 1 deploys the Price Book prior to Products with Options as without the Price Book existing, Price Book Entries cannot be created) as Product Rules are associated directly to Product records and therefore the deployment would fail when trying to relate the Product Rule to the non-existent Product.
Did that make your head spin as much as it did mine? Imagine having to manage this in Excel and keep it all straight.
Deployment Plans for Salesforce CPQ come pre-configured with the Prodly managed package and can be used without any further setup, if desired. This is such a handy feature and saves so much initial setup time.
You can see in the image the breakdown of the deployment plan. You can dig deeper into each item by clicking “View Item” and you will notice the steps have a corresponding data set. Some data sets are deployed in the same step (step 7). These are objects which are related to records that will have been deployed in steps 1-6 and therefore can be deployed in the same step.
If you are working with data outside of Salesforce CPQ, you will need to create the Deployment Plan from scratch once you’ve created your Data Sets.
Deployment Results
Deployment Results are the final tab I’ll touch on.
Deployment Results are key to understanding if your deployment was successful, or why it failed. Each Deployment Result record contains basic information such as the Source Connection, the Destination Connection, when the job started, finished, and the final result.
You can then dig deeper into the results of each element that was deployed as the overall result may have been “Success” but a few elements had minor issues that may or may not need to be addressed.
The Deployment Record Results section shows you the records’ source and destination and any potential errors for quick debugging.
Getting Granular
Prodly allows you to do very granular deployments of data. This means that if you just update a few Price Rules in your sandbox, you can deploy those items which have changed and nothing else.
This is extremely useful if you are working on a large scale CPQ project because you can move the items which have been tested, and leave any items still in development in your sandbox.
Simply write an SQL Where query and define the records you would like to deploy.
Create Missing Fields & Sync Picklist Values
Prodly can assist admins by creating any missing fields referenced in a related record that do not already exist in a destination org. For example, if a Price Condition references a custom field created by the CPQ admin in the sandbox to reference the customer’s classification and apply a discount accordingly, Prodly can create the custom field in the destination org as it’s deploying the Price Condition record.
The same can be done with picklist values between orgs. For example, when you created that Account Classification field on the quote to reference the customer’s Classification, you also had to update the Target Field picklist on the Price Condition object. Prodly will ensure the Target Field picklist in your destination org is in sync with the values in your sandbox.
However, there could be cases where you are unable to use this feature, such as if you use a complex DevOps deployment process for your metadata which has to be passed through various validations and committed to a code repository to ensure it is not overwritten in Production on the next deployment.
If your organization utilizes Change Sets, ANT Scripts, or the Forece.com IDE tool, you should be able to use this feature.
Prevent Duplicates
Prodly utilizes four methods to ensure duplicate records are not created when deploying records. The most popular method is using a Virtual External ID or VEID. Prodly assigns each record a virtual external ID and when deploying between environments, these virtual IDs are matched.
It is important to keep your sandbox environment in sync with your production environment to ensure the success of using VEID. Always start with a fresh sandbox, deploy from Production to your empty sandbox, and then deploy back to Production from your sandbox once you’ve made your changes. As discussed you can run the whole deployment plan or just a subset of data depending on the changes you made/want to deploy to Production.
There is also a checkbox on the Data Set Editor page which allows you to “Skip Duplicates” and Prodly will skip entering in a record where it thinks it will cause a duplicate.
Use Cases
I’ve hinted at a few use cases for Prodly. Salesforce CPQ is the major one! Prodly was founded to improve the process of moving Salesforce CPQ data between organizations.
As mentioned previously, Prodly can be used to move any data records between organizations, even Accounts & Contacts if you wish!
Due to Prodly’s almost infinite use cases, I’ve picked a few key ones.
Salesforce CPQ & Field Service
Salesforce CPQ & Field Service utilizes reference data as mentioned throughout this article. Although the focus has been heavily on CPQ as that’s what started Prodly’s journey, Field Service is another Salesforce product that can be deployed using Prodly.
Prodly provides deployment templates via the Prodly User Community which all customers have access to, just get in touch with your Prodly customer success manager.
Seed sandboxes, fast
All admins who have worked with relationship based data configurations in the past can tell you that not only is moving from your sandbox to Production a pain using Excel, VLOOKUPs, and DataLoader, but then, once you’ve done that and refreshed your sandbox, you have to do the whole process in reverse! Prodly cuts that time down to minutes as once your deployment has gone into Production, you can refresh your sandbox and reseed it with the click of a button.
Junction Object Data
Prodly isn’t only useful for CPQ, Field Service & other 3rd Party Applications. Perhaps you have developed a junction object which you use to maintain promotions associated with specific products.
You might look at the Account Geo, Classification & the Product as parameters to determine the level of discount. You might also take into account if the Primary Contact on the Quote is buying as part of a Campaign (which might result in a larger discount).
These Product Promotion records are related to Product & Campaign records which, of course, live in other objects. You can use Prodly (using a custom data set of course) to move these records between environments as setting up these relationships in a testing environment will be key to developing the mechanism which will be used to apply them (Flows, custom code, etc).
You can read more about creating a junction object to form many to many relationships here.
3rd Party Application Configuration
FinancialForce, Conga CLM, Conga CPQ (formerly known as Apttus CPQ), and various other 3rd Party applications from the Salesforce AppExchange which utilize Data Configuration can be migrated between Salesforce Environments using Prodly.
Impact
Time Saved
Adding Prodly to your toolkit can be a huge time-saver as mentioned throughout this article. It reduces a job that can take hours if done manually, to minutes if done using Prodly. Admins can spend more time improving the system’s processes instead of manually seeding sandboxes just to prepare them for even the smallest of changes.
Reduces Risk of Error
Any admin who has had the misfortune to do complex relational data-deployments using Excel & VLOOKUPs knows it can be stressful hoping all the relationships have been maintained correctly. It’s nearly impossible to know if 100% of the data has been maintained correctly until it’s uploaded into the Org where the relationships are visible. Whatsmore, if the data deployment is incorrect, those records must be deleted or modified manually and can cause downtime in the org for your users.
Prodly significantly reduces the risk to your org as the relationships are all maintained by the tool using one of the four upsert methods offered by the tool. In addition, using the SQL Query function, you can ensure only the records you want to be moved between environments are moved, and everything else which is still in development, is maintained in a sandbox only.
Setup
Prodly can be set up once installed in your Production environment, in as little as 15 minutes. As previously mentioned, the managed package comes with pre-configured Data Sets & Deployments Plans, all you have to set up are the connections!
Connections can be created in as little as 60 seconds and you can have as many connections as needed for your use cases. It’s a good idea to utilize the Folders features when setting up Prodly, especially if you will have a number of different users utilizing its features (e.g. one team/user managing CPQ, one team/user managing Field Service, etc.) or if you are a consultant and utilizing Prodly for your customer’s projects.
Once Connections have been set up, you can start deploying using the aforementioned pre-installed data sets/deployment plans, but you can also create your own if you so choose. My advice would be to start with the pre-installed options (provided they fit your needs) and then customize as needed!
Pricing
Prodly’s supports the overall health of your Salesforce instance and helps deliver applications faster and with less errors to the users admins support. Pricing starts at $12 USD per supported Salesforce user with volume discounts available.
Next Steps
You can check out Prodly by scheduling a 30-minute demo. This will give you an in-depth understanding of the product and how it can benefit your business. You can schedule a demo using this link.
Comments: